PostgreSQL 12.0 (upcoming) commit log

commit   : d97b714a219959a50f9e7b37ded674f5132f93f3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 11:15:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 11:15:28 -0400    

Formerly, lcons was about the same speed as lappend, but with the new  
List implementation, that's not so; with a long List, data movement  
imposes an O(N) cost on lcons and list_delete_first, but not lappend.  
  
Hence, invent list_delete_last with semantics parallel to  
list_delete_first (but O(1) cost), and change various places to use  
lappend and list_delete_last where this can be done without much  
violence to the code logic.  
  
There are quite a few places that construct result lists using lcons not  
lappend.  Some have semantic rationales for that; I added comments about  
it to a couple that didn't have them already.  In many such places though,  
I think the coding is that way only because back in the dark ages lcons  
was faster than lappend.  Hence, switch to lappend where this can be done  
without causing semantic changes.  
  
In ExecInitExprRec(), this results in aggregates and window functions that  
are in the same plan node being executed in a different order than before.  
Generally, the executions of such functions ought to be independent of  
each other, so this shouldn't result in visibly different query results.  
But if you push it, as one regression test case does, you can show that  
the order is different.  The new order seems saner; it's closer to  
the order of the functions in the query text.  And we never documented  
or promised anything about this, anyway.  
  
Also, in gistfinishsplit(), don't bother building a reverse-order list;  
it's easy now to iterate backwards through the original list.  
  
It'd be possible to go further towards removing uses of lcons and  
list_delete_first, but it'd require more extensive logic changes,  
and I'm not convinced it's worth it.  Most of the remaining uses  
deal with queues that probably never get long enough to be worth  
sweating over.  (Actually, I doubt that any of the changes in this  
patch will have measurable performance effects either.  But better  
to have good examples than bad ones in the code base.)  
  
Patch by me, thanks to David Rowley and Daniel Gustafsson for review.  
  
Discussion: https://postgr.es/m/21272.1563318411@sss.pgh.pa.us  

commit   : dfd0121dc73aab491bcaad2d2b7a2a749389add8    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 17 Jul 2019 12:14:08 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 17 Jul 2019 12:14:08 +1200    

Potential future SMGR implementations may not want to create  
tablespace directories when creating an SMGR relation.  Move that  
logic to mdcreate().  Move the initialization of md-specific  
data structures from smgropen() to a new callback mdopen().  
  
Author: Thomas Munro  
Reviewed-by: Shawn Debnath (as part of an earlier patch set)  
Discussion: https://postgr.es/m/CA%2BhUKG%2BOZqOiOuDm5tC5DyQZtJ3FH4%2BFSVMqtdC4P1atpJ%2Bqhg%40mail.gmail.com  

commit   : 3093eb2b83645a083a47ea62769ffd89e31f3664    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 18:17:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 18:17:47 -0400    

This should lappend the OIDs, not lcons them; the existing code produced  
a list in reversed order.  This is harmless for single-key FKs or FKs  
where all the key columns are of the same type, which probably explains  
how it went unnoticed.  But if those conditions are not met,  
ATAddForeignKeyConstraint would make the wrong decision about whether an  
existing FK needs to be revalidated.  I think it would almost always err  
in the safe direction by revalidating a constraint that didn't need it.  
You could imagine scenarios where the pfeqop check was fooled by  
swapping the types of two FK columns in one ALTER TABLE, but that case  
would probably be rejected by other tests, so it might be impossible to  
get to the worst-case scenario where an FK should be revalidated and  
isn't.  (And even then, it's likely to be fine, unless there are weird  
inconsistencies in the equality behavior of the replacement types.)  
However, this is a performance bug at least.  
  
Noted while poking around to see whether lcons calls could be converted  
to lappend.  
  
This bug is old, dating to commit cb3a7c2b9, so back-patch to all  
supported branches.  

commit   : c245776906b065fcd59831a25c3b24ad3ddcd849    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 13:12:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 13:12:24 -0400    

It seems worth getting rid of these functions because they require the  
caller to retain a ListCell pointer into a List that it's modifying,  
which is a dangerous practice with the new List implementation.  
(The only other List-modifying function that takes a ListCell pointer  
as input is list_delete_cell, which nowadays is preferentially used  
via the constrained API foreach_delete_current.)  
  
There was only one remaining caller of these functions after commit  
2f5b8eb5a, and that was some fairly ugly GEQO code that can be much  
more clearly expressed using a list-index variable and list_insert_nth.  
Hence, rewrite that code, and remove the functions.  
  
Discussion: https://postgr.es/m/26193.1563228600@sss.pgh.pa.us  

commit   : 2f5b8eb5a28b4e6de9d20cc7d2c6028c6c7a8aa8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 12:04:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 12:04:06 -0400    

heap.c and relcache.c contained nearly identical copies of logic  
to insert OIDs into an OID list while preserving the list's OID  
ordering (and rejecting duplicates, in one case but not the other).  
  
The comments argue that this is faster than qsort for small numbers  
of OIDs, which is at best unproven, and seems even less likely to be  
true now that lappend_cell_oid has to move data around.  In any case  
it's ugly and hard-to-follow code, and if we do have a lot of OIDs  
to consider, it's O(N^2).  
  
Hence, replace with simply lappend'ing OIDs to a List, then list_sort  
the completed List, then remove adjacent duplicates if necessary.  
This is demonstrably O(N log N) and it's much simpler for the  
callers.  It's possible that this would be somewhat inefficient  
if there were a very large number of duplicates, but that seems  
unlikely in the existing usage.  
  
This adds list_deduplicate_oid and list_oid_cmp infrastructure  
to list.c.  I didn't bother with equivalent functionality for  
integer or pointer Lists, but such could always be added later  
if we find a use for it.  
  
Discussion: https://postgr.es/m/26193.1563228600@sss.pgh.pa.us  

commit   : 569ed7f48312c70ed4a79daec1d7688fda4e74ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 11:51:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 11:51:44 -0400    

In the wake of commit 1cff1b95a, the obvious way to sort a List  
is to apply qsort() directly to the array of ListCells.  list_qsort  
was building an intermediate array of pointers-to-ListCells, which  
we no longer need, but getting rid of it forces an API change:  
the comparator functions need to do one less level of indirection.  
  
Since we're having to touch the callers anyway, let's do two additional  
changes: sort the given list in-place rather than making a copy (as  
none of the existing callers have any use for the copying behavior),  
and rename list_qsort to list_sort.  It was argued that the old name  
exposes more about the implementation than it should, which I find  
pretty questionable, but a better reason to rename it is to be sure  
we get the attention of any external callers about the need to fix  
their comparator functions.  
  
While we're at it, change four existing callers of qsort() to use  
list_sort instead; previously, they all had local reinventions  
of list_qsort, ie build-an-array-from-a-List-and-qsort-it.  
(There are some other places where changing to list_sort perhaps  
would be worthwhile, but they're less obviously wins.)  
  
Discussion: https://postgr.es/m/29361.1563220190@sss.pgh.pa.us  

commit   : 0896ae561b6c799d45cb61d8a3b18fbb442130a7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 16 Jul 2019 13:23:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 16 Jul 2019 13:23:53 +0900    

This is numbered take 7, and addresses a set of issues around:  
- Fixes for typos and incorrect reference names.  
- Removal of unneeded comments.  
- Removal of unreferenced functions and structures.  
- Fixes regarding variable name consistency.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/10bfd4ac-3e7c-40ab-2b2e-355ed15495e8@gmail.com  

commit   : 4c3d05d875dd173a81a995c6e14d69496b467eec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jul 2019 23:27:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jul 2019 23:27:13 -0400    

These memory context switches are useless in the wake of commit  
1cff1b95a.  Noted by Jesper Pedersen.  
  
Discussion: https://postgr.es/m/f078ce63-9e04-0f3e-d200-d7ee66279abe@redhat.com  

commit   : c6bce6ebb668c7da03d01244d34cac0335561103    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 15 Jul 2019 20:57:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 15 Jul 2019 20:57:24 -0400    

Reported-by: Ian Barwick  
  
Discussion: https://postgr.es/m/538950ec-b86a-1650-6078-beb7091c09c2@2ndquadrant.com  
  
Backpatch-through: 9.4  

commit   : 5823677acc567d7790cc68972de12f6718913d7d    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 16 Jul 2019 11:53:12 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 16 Jul 2019 11:53:12 +1200    

Author: Fabien Coelho  
Reviewed-by: Ibrar Ahmed  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1904081737390.5867%40lancre  

commit   : ce8f946764005e1bde5a538542205e55f81bb6cc    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 16 Jul 2019 11:31:44 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 16 Jul 2019 11:31:44 +1200    

Author: Fabien Coelho  
Reviewed-by: Ibrar Ahmed  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1904061810510.3678%40lancre  

commit   : bfdbac2ab3ef1a12a7de231552b128ed83ad00bb    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 15 Jul 2019 14:35:06 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 15 Jul 2019 14:35:06 -0700    

The logic just added by commit e3899ffd falls back on a 50:50 page split  
in the event of a new item that's just to the right of our provisional  
"many duplicates" split point.  Fix a comment that incorrectly claimed  
that the new item had to be just to the left of our provisional split  
point.  
  
Backpatch: 12-, just like commit e3899ffd.  

commit   : e3899ffd8beafdaaa037b503163a9f572e9fc729    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 15 Jul 2019 13:19:13 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 15 Jul 2019 13:19:13 -0700    

Specific ever-decreasing insertion patterns could cause successive  
unbalanced nbtree page splits.  Problem cases involve a large group of  
duplicates to the left, and ever-decreasing insertions to the right.  
  
To fix, detect the situation by considering the newitem offset before  
performing a split using nbtsplitloc.c's "many duplicates" strategy.  If  
the new item was inserted just to the right of our provisional "many  
duplicates" split point, infer ever-decreasing insertions and fall back  
on a 50:50 (space delta optimal) split.  This seems to barely affect  
cases that already had acceptable space utilization.  
  
An alternative fix also seems possible.  Instead of changing  
nbtsplitloc.c split choice logic, we could instead teach _bt_truncate()  
to generate a new value for new high keys by interpolating from the  
lastleft and firstright key values.  That would certainly be a more  
elegant fix, but it isn't suitable for backpatching.  
  
Discussion: https://postgr.es/m/CAH2-WznCNvhZpxa__GqAa1fgQ9uYdVc=_apArkW2nc-K3O7_NA@mail.gmail.com  
Backpatch: 12-, where the nbtree page split enhancements were introduced.  

commit   : 1cff1b95ab6ddae32faa3efe0d95a820dbfdc164    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jul 2019 13:41:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jul 2019 13:41:58 -0400    

Originally, Postgres Lists were a more or less exact reimplementation of  
Lisp lists, which consist of chains of separately-allocated cons cells,  
each having a value and a next-cell link.  We'd hacked that once before  
(commit d0b4399d8) to add a separate List header, but the data was still  
in cons cells.  That makes some operations -- notably list_nth() -- O(N),  
and it's bulky because of the next-cell pointers and per-cell palloc  
overhead, and it's very cache-unfriendly if the cons cells end up  
scattered around rather than being adjacent.  
  
In this rewrite, we still have List headers, but the data is in a  
resizable array of values, with no next-cell links.  Now we need at  
most two palloc's per List, and often only one, since we can allocate  
some values in the same palloc call as the List header.  (Of course,  
extending an existing List may require repalloc's to enlarge the array.  
But this involves just O(log N) allocations not O(N).)  
  
Of course this is not without downsides.  The key difficulty is that  
addition or deletion of a list entry may now cause other entries to  
move, which it did not before.  
  
For example, that breaks foreach() and sister macros, which historically  
used a pointer to the current cons-cell as loop state.  We can repair  
those macros transparently by making their actual loop state be an  
integer list index; the exposed "ListCell *" pointer is no longer state  
carried across loop iterations, but is just a derived value.  (In  
practice, modern compilers can optimize things back to having just one  
loop state value, at least for simple cases with inline loop bodies.)  
In principle, this is a semantics change for cases where the loop body  
inserts or deletes list entries ahead of the current loop index; but  
I found no such cases in the Postgres code.  
  
The change is not at all transparent for code that doesn't use foreach()  
but chases lists "by hand" using lnext().  The largest share of such  
code in the backend is in loops that were maintaining "prev" and "next"  
variables in addition to the current-cell pointer, in order to delete  
list cells efficiently using list_delete_cell().  However, we no longer  
need a previous-cell pointer to delete a list cell efficiently.  Keeping  
a next-cell pointer doesn't work, as explained above, but we can improve  
matters by changing such code to use a regular foreach() loop and then  
using the new macro foreach_delete_current() to delete the current cell.  
(This macro knows how to update the associated foreach loop's state so  
that no cells will be missed in the traversal.)  
  
There remains a nontrivial risk of code assuming that a ListCell *  
pointer will remain good over an operation that could now move the list  
contents.  To help catch such errors, list.c can be compiled with a new  
define symbol DEBUG_LIST_MEMORY_USAGE that forcibly moves list contents  
whenever that could possibly happen.  This makes list operations  
significantly more expensive so it's not normally turned on (though it  
is on by default if USE_VALGRIND is on).  
  
There are two notable API differences from the previous code:  
  
* lnext() now requires the List's header pointer in addition to the  
current cell's address.  
  
* list_delete_cell() no longer requires a previous-cell argument.  
  
These changes are somewhat unfortunate, but on the other hand code using  
either function needs inspection to see if it is assuming anything  
it shouldn't, so it's not all bad.  
  
Programmers should be aware of these significant performance changes:  
  
* list_nth() and related functions are now O(1); so there's no  
major access-speed difference between a list and an array.  
  
* Inserting or deleting a list element now takes time proportional to  
the distance to the end of the list, due to moving the array elements.  
(However, it typically *doesn't* require palloc or pfree, so except in  
long lists it's probably still faster than before.)  Notably, lcons()  
used to be about the same cost as lappend(), but that's no longer true  
if the list is long.  Code that uses lcons() and list_delete_first()  
to maintain a stack might usefully be rewritten to push and pop at the  
end of the list rather than the beginning.  
  
* There are now list_insert_nth...() and list_delete_nth...() functions  
that add or remove a list cell identified by index.  These have the  
data-movement penalty explained above, but there's no search penalty.  
  
* list_concat() and variants now copy the second list's data into  
storage belonging to the first list, so there is no longer any  
sharing of cells between the input lists.  The second argument is  
now declared "const List *" to reflect that it isn't changed.  
  
This patch just does the minimum needed to get the new implementation  
in place and fix bugs exposed by the regression tests.  As suggested  
by the foregoing, there's a fair amount of followup work remaining to  
do.  
  
Also, the ENABLE_LIST_COMPAT macros are finally removed in this  
commit.  Code using those should have been gone a dozen years ago.  
  
Patch by me; thanks to David Rowley, Jesper Pedersen, and others  
for review.  
  
Discussion: https://postgr.es/m/11587.1550975080@sss.pgh.pa.us  

commit   : 67b9b3ca328392f9afc4e66fe03564f5fc87feff    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 Jul 2019 17:03:46 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 Jul 2019 17:03:46 +1200    

In order to be able to work with FullTransactionId values during replay  
without increasing the size of the WAL, infer the epoch.  In general we  
can't do that safely, but during replay we can because we know that  
nextFullXid can't advance concurrently.  
  
Prevent frontend code from seeing this new function, due to the above  
restriction.  Perhaps in future it will be possible to extract the value  
entirely from independent WAL records, and then this restriction can be  
lifted.  
  
Author: Thomas Munro, based on earlier code from Andres Freund  
Discussion: https://postgr.es/m/CA%2BhUKG%2BmLmuDjMi6o1dxkKvGRL56Y2Rz%2BiXAcrZV03G9ZuFQ8Q%40mail.gmail.com  

commit   : 5925e5549890416bcf588334d9d0bc99f8ad6c7f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 14 Jul 2019 14:30:27 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 14 Jul 2019 14:30:27 +0200    

This adds a built-in function to generate UUIDs.  
  
PostgreSQL hasn't had a built-in function to generate a UUID yet,  
relying on external modules such as uuid-ossp and pgcrypto to provide  
one.  Now that we have a strong random number generator built-in, we  
can easily provide a version 4 (random) UUID generation function.  
  
This patch takes the existing function gen_random_uuid() from pgcrypto  
and makes it a built-in function.  The pgcrypto implementation now  
internally redirects to the built-in one.  
  
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>  
Discussion: https://www.postgresql.org/message-id/6a65610c-46fc-2323-6b78-e8086340a325@2ndquadrant.com  

commit   : 565f3390005318ea4c982b8d054d56e9fe5a6454    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 15:22:21 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 15:22:21 +0300    

6254c55f81, c085e1c1cb and 075f0a880f all change system catalog.  But  
catversion bump is missed in all of them.  So, do catversion bump now.  
  
Also, I need mention patch reviewer Fabien Coelho, who has been missed in  
commit messages of 6254c55f81, c085e1c1cb and 075f0a880f.  

commit   : 075f0a880fbf790f4a3dcac83e2d5125bcad9646    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 14:57:53 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 14:57:53 +0300    

Opclass support functions already can handle this operator, just catalog  
adjustment appears to be required.  
  
Discussion: https://postgr.es/m/f71ba19d-d989-63b6-f04a-abf02ad9345d%40postgrespro.ru  
Author: Nikita Glukhov  
Reviewed-by: Tom Lane, Alexander Korotkov  

commit   : c085e1c1cb4e29637552f5d250d45ad0cb83e5cf    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 14:56:18 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 14:56:18 +0300    

Index-based calculation of this operator is exact.  So, signature of  
gist_bbox_distance() function is changes so that caller is responsible for  
setting *recheck flag.  
  
Discussion: https://postgr.es/m/f71ba19d-d989-63b6-f04a-abf02ad9345d%40postgrespro.ru  
Author: Nikita Glukhov  
Reviewed-by: Tom Lane, Alexander Korotkov  

commit   : 6254c55f815623bb74e2cf27562437dc3b2aa2c8    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 14:55:01 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 14:55:01 +0300    

Some of <-> operators between geometric types have their commutators missed.  
This commit adds them.  The motivation is upcoming kNN support for some of those  
operators.  
  
Discussion: https://postgr.es/m/f71ba19d-d989-63b6-f04a-abf02ad9345d%40postgrespro.ru  
Author: Nikita Glukhov  
Reviewed-by: Tom Lane, Alexander Korotkov  

commit   : 6e74c64bcf61eab94091f6b17dfd0ab585b1a77e    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sun, 14 Jul 2019 12:07:40 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sun, 14 Jul 2019 12:07:40 +0100    

Performance of a SELECT FOR UPDATE may be quite distinct from the  
non-UPDATE version of the query, so treat all of the FOR UPDATE clause  
as being significant for distinguishing queries.  
  
Andrew Gierth and Vik Fearing, reviewed by Sergei Kornilov, Thomas  
Munro, Tom Lane  
  
Discussion: https://postgr.es/m/87h8e4hfwv.fsf@news-spur.riddles.org.uk  

commit   : 0369f4736665864edd7bf43736df190afa223c4c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 14 Jul 2019 14:19:54 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 14 Jul 2019 14:19:54 +1200    

We choose a random value for delta, not balance.  Back-patch to 9.6 where  
the mistake arrived.  
  
Author: Fabien Coelho  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1904081752210.5867@lancre  

commit   : 8a0cbb88524e8b6121597285b811640ee793b3e8    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 13 Jul 2019 13:34:22 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 13 Jul 2019 13:34:22 -0700    

Commit 578b229718e8f15fa779e20f086c4b6bb3776106 replaced it with a  
concurrent "nextval" test.  That version does not detect PostgreSQL's  
incompatibility with xlc 13.1.3, so bring back an OID-based test that  
does.  Back-patch to v12, where that commit first appeared.  
  
Discussion: https://postgr.es/m/20190707170035.GA1485546@rfd.leadboat.com  

commit   : 39aadc984221f57ce7dc11dd3c8c719e10198549    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 13 Jul 2019 16:51:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 13 Jul 2019 16:51:31 +0900    

In configure scripts, --with-ossp-uuid is obsolete is replaced by  
--with-uuid, and it needs to specify a path to its library builds when  
building with the MSVC scripts.  --with-perl needs also to specify a  
path.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20190712.121529.194600624.horikyota.ntt@gmail.com  

commit   : 170d11b8e7cb9df96a7ee0b8140d28536d55fe3e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 13 Jul 2019 14:43:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 13 Jul 2019 14:43:29 +0900    

This adds some missing markups, fixes a couple of incorrect ones and  
clarifies some documentation in various places.  
  
Author: Liudmila Mantrova  
Discussion: https://postgr.es/m/a068f947-7a51-5df1-b3fd-1a131ae5c044@postgrespro.ru  
Backpatch-through: 12  

commit   : 5b51bbfbd52a444a490247e66751d6a47d2ba7dd    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 13 Jul 2019 15:56:20 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 13 Jul 2019 15:56:20 +1200    

Previously it suggested an extra "=" after "SET x=".  
  
Reported-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/CA%2BhUKGLk%3D0yLDjfviONJLzcHEzygj%3Dx6VbGH43LnXbBUvQb52g%40mail.gmail.com  

commit   : 7bdc6556fb325582b02e9a6931c38f873a0c46a0    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 13 Jul 2019 15:51:52 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 13 Jul 2019 15:51:52 +1200    

Author: Thomas Munro  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/CA%2BhUKGLk%3D0yLDjfviONJLzcHEzygj%3Dx6VbGH43LnXbBUvQb52g%40mail.gmail.com  

commit   : b91dd9de5ea0839d0d248ebbe8cb926c3df52c7c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 13 Jul 2019 13:55:10 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 13 Jul 2019 13:55:10 +1200    

After a process decides not to wait for a condition variable, it can  
still consume a signal before it reaches ConditionVariableCancelSleep().  
In that case, pass the signal on to another waiter if possible, so that  
a signal doesn't go missing when there is another process ready to  
receive it.  
  
Author: Thomas Munro  
Reviewed-by: Shawn Debnath  
Discussion: https://postgr.es/m/CA%2BhUKGLQ_RW%2BXs8znDn36e-%2Bmq2--zrPemBqTQ8eKT-VO1OF4Q%40mail.gmail.com  

commit   : 1321509fa43293615c4e5fa5dc8eed5286f479b1    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 13 Jul 2019 13:40:36 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 13 Jul 2019 13:40:36 +1200    

Provide ConditionVariableTimedSleep(), like ConditionVariableSleep()  
but with a timeout argument.  
  
Author: Shawn Debnath  
Reviewed-by: Kyotaro Horiguchi, Thomas Munro  
Discussion: https://postgr.es/m/eeb06007ccfe46e399df6af18bfcd15a@EX13D05UWC002.ant.amazon.com  

commit   : b31fbe852c095a827caade2e0702f8a215053bea    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 13 Jul 2019 10:35:34 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 13 Jul 2019 10:35:34 +1200    

Provide a hint to users that they need to increase wal_level before  
subscriptions can work.  
  
Author: Lucas Viecelli, with some adjustments by Thomas Munro  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/CAPjy-57rn5Y9g4e5u--eSOP-7P4QrE9uOZmT2ZcUebF8qxsYhg%40mail.gmail.com  

commit   : d3751adcf14d3baacc9738ee9ce869dc1c31d7ad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jul 2019 16:24:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jul 2019 16:24:59 -0400    

Commit 3ca930fc3 modified get_actual_variable_range() to use a new  
"SnapshotNonVacuumable" snapshot type for selecting tuples that it  
would consider valid.  However, because that snapshot type can accept  
recently-dead tuples, this caused a bug when using a recently-created  
index: we might accept a recently-dead tuple that is an early member  
of a broken HOT chain and does not actually match the index entry.  
Then, the data extracted from the heap tuple would not necessarily be  
an endpoint value of the column; it could even be NULL, leading to  
get_actual_variable_range() itself reporting "found unexpected null  
value in index".  Even without an error, this could lead to poor  
plan choices due to an erroneous notion of the endpoint value.  
  
We can improve matters by changing the code to use the index-only  
scan technique (which didn't exist when get_actual_variable_range was  
originally written).  If any of the tuples in a HOT chain are live  
enough to satisfy SnapshotNonVacuumable, we take the data from the  
index entry, ignoring what is in the heap.  This fixes the problem  
without changing the live-vs-dead-tuple behavior from what was  
intended by commit 3ca930fc3.  
  
A side benefit is that for static tables we might not have to touch  
the heap at all (when the extremal value is in an all-visible page).  
In addition, we can save some overhead by not having to create a  
complete ExecutorState, and we don't need to run FormIndexDatum,  
avoiding more cycles as well as the possibility of failure for  
indexes on expressions.  (I'm not sure that this code would ever  
be used to determine the extreme value of an expression, in the  
current state of the planner; but it's definitely possible that  
lower-order columns of the selected index could be expressions.  
So one could construct perhaps-artificial examples in which the  
old code unexpectedly failed due to trying to compute an  
expression's value for a now-dead row.)  
  
Per report from Manuel Rigger.  Back-patch to v11 where commit  
3ca930fc3 came in.  
  
Discussion: https://postgr.es/m/CA+u7OA7W4NWEhCvftdV6_8bbm2vgypi5nuxfnSEJQqVKFSUoMg@mail.gmail.com  

commit   : cfde23493938b543d281c509527f0f5b16fca9ff    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 12 Jul 2019 19:12:38 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 12 Jul 2019 19:12:38 +1200    

match_clause_to_partition_key incorrectly would return  
PARTCLAUSE_UNSUPPORTED if a bool qual could not be matched to the current  
partition key.  This was a problem, as it causes the calling function to  
discard the qual and not try to match it to any other partition key.  If  
there was another partition key which did match this qual, then the qual  
would not be checked again and we could fail to prune some partitions.  
  
The worst this could do was to cause partitions not to be pruned when they  
could have been, so there was no danger of incorrect query results here.  
  
Fix this by changing match_boolean_partition_clause to have it return a  
PartClauseMatchStatus rather than a boolean value.  This allows it to  
communicate if the qual is unsupported or if it just does not match this  
particular partition key, previously these two cases were treated the  
same.  Now, if match_clause_to_partition_key is unable to match the qual  
to any other qual type then we can simply return the value from the  
match_boolean_partition_clause call so that the calling function properly  
treats the qual as either unmatched or unsupported.  
  
Reported-by: Rares Salcudean  
Reviewed-by: Amit Langote  
Backpatch-through: 11 where partition pruning was introduced  
Discussion: https://postgr.es/m/CAHp_FN2xwEznH6oyS0hNTuUUZKp5PvegcVv=Co6nBXJ+mC7Y5w@mail.gmail.com  

commit   : 0cea6eb5a5f2948c411706cabfde32ce61df0d7a    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 11 Jul 2019 18:18:15 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 11 Jul 2019 18:18:15 +0300    

Reported-by: Thom Brown  
Discussion: https://postgr.es/m/CAA-aLv4Tggy6Z3kaG9n%2B3SHwOVGN2Yj_MJXfdfwjH_jBNZzJNA%40mail.gmail.com  
Backpatch-through: 12  

commit   : b5810de3f4eb0e7b242d31db93a46957d56ea8b4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Jul 2019 14:32:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Jul 2019 14:32:28 -0400    

Previously, exec_simple_query always ran parse analysis, rewrite, and  
planning in MessageContext, allowing all the data generated thereby  
to persist until the end of processing of the whole query string.  
That's fine for single-command strings, but if a client sends many  
commands in a single simple-Query message, this strategy could result  
in annoying memory bloat, as complained of by Andreas Seltenreich.  
  
To fix, create a child context to do this work in, and reclaim it  
after each command.  But we only do so for parsetrees that are not  
last in their query string.  That avoids adding any memory management  
overhead for the typical case of a single-command string.  Memory  
allocated for the last parsetree would be freed immediately after  
finishing the command string anyway.  
  
Similarly, adjust extension.c's execute_sql_string() to reclaim memory  
after each command.  In that usage, multi-command strings are the norm,  
so it's a bit surprising that no one has yet complained of bloat ---  
especially since the bloat extended to whatever data ProcessUtility  
execution might leak.  
  
Amit Langote, reviewed by Julien Rouhaud  
  
Discussion: https://postgr.es/m/87ftp6l2qr.fsf@credativ.de  

commit   : 909a7b6b8ecd6bf87bb44cb014ed593e9789af11    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Jul 2019 14:24:36 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Jul 2019 14:24:36 -0400    

It is now always displayed in PG 12+.  
  
Discussion: https://postgr.es/m/b6ec6167-5dd5-6347-ac1d-1fd49382019f@2ndquadrant.com  
  
Author: Ian Barwick  
  
Backpatch-through: 12  

commit   : ec4eaab78b078b9326296236f184773590a92ca3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 10 Jul 2019 08:58:41 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 10 Jul 2019 08:58:41 -0400    

Per gripe from Phil Bayer.  
  
Authors: Amit Langote and others  
Discussion: https://postgr.es/m/156236160709.1192.4498528196556144085@wrigleys.postgresql.org  

commit   : fa19a08d71fbeefc39415d9c6c70128460d41f94    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Jul 2019 15:14:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 10 Jul 2019 15:14:54 +0900    

This can cause valgrind to complain, as the flag marking a buffer as a  
temporary copy was not getting initialized.  
  
While on it, fill in with zeros newly-created buffer pages.  This does  
not matter when loading a block from a temporary file, but it makes the  
push of an index tuple into a new buffer page safer.  
  
This has been introduced by 1d27dcf, so backpatch all the way down to  
9.4.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/15899-0d24fb273b3dd90c@postgresql.org  
Backpatch-through: 9.4  

commit   : 5a7d697a39365d9762afa8e618bcbdcf592966fa    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 10 Jul 2019 07:46:16 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 10 Jul 2019 07:46:16 +0300    

This commit contains assorted fixes for jsonpath documentation including:  
grammar fixes, incorrect examples fixes as well as wording improvements.  
  
Discussion: https://postgr.es/m/CAA-aLv4VVX%3Db9RK5hkfPXJczqaiTdqO04teW9i0wiQVhdKcqzw%40mail.gmail.com  
Author: Liudmila Mantrova  
Reviewed-by: Alexander Korotkov  
Reported-by: Thom Brown  

commit   : f7c830f1ab2645236ac2d6103fb3a88518bdc4fc    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 10 Jul 2019 16:03:04 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 10 Jul 2019 16:03:04 +1200    

86b85044e abstracted calls to heap functions in COPY FROM to support a  
generic table AM.  However, when performing a copy into a partitioned  
table, this commit neglected to call table_finish_bulk_insert for each  
partition.  Before 86b85044e, when we always called the heap functions,  
there was no need to call heapam_finish_bulk_insert for partitions since  
it only did any work when performing a copy without WAL.  For partitioned  
tables, this was unsupported anyway, so there was no issue.  With  
pluggable storage, we can't make any assumptions about what the table AM  
might want to do in its equivalent function, so we'd better ensure we  
always call table_finish_bulk_insert each partition that's received a row.  
  
For now, we make the table_finish_bulk_insert call whenever we evict a  
CopyMultiInsertBuffer out of the CopyMultiInsertInfo.  This does mean  
that it's possible that we call table_finish_bulk_insert multiple times  
per partition, which is not a problem other than being an inefficiency.  
Improving this requires a more invasive patch, so let's leave that for  
another day.  
  
This also changes things so that we no longer needlessly call  
table_finish_bulk_insert when performing a COPY FROM for a non-partitioned  
table when not using multi-inserts.  
  
Reported-by: Robert Haas  
Backpatch-through: 12  
Discussion: https://postgr.es/m/CA+TgmoYK=6BpxiJ0tN-p9wtH0BTAfbdxzHhwou0mdud4+BkYuQ@mail.gmail.com  

commit   : bd56cd75d2cee28c4acd1cd76af57664e622d21f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 10 Jul 2019 07:52:51 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 10 Jul 2019 07:52:51 +0530    

Reported-by: Ashwin Agrawal  
Author: Ashwin Agrawal  
Reviewed-by: Amit Kapila  
Backpatch-through: 12, where it was introduced  
Discussion: https://postgr.es/m/CALfoeisgdZhYDrJOukaBzvXfJOK2FQ0szVMK7dzmcy6w93iDUA@mail.gmail.com  

commit   : f5825853e3afdb4df4767d30cbfdd375b45d1f2a    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 10 Jul 2019 10:15:32 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 10 Jul 2019 10:15:32 +1200    

Otherwise the executor can't see trigger transition tables during  
EPQ evaluation.  Fixes bug #15900 and almost certainly also #15720.  
Back-patch to 10, where trigger transition tables landed.  
  
Author: Alex Aktsipetrov  
Reviewed-by: Thomas Munro, Tom Lane  
Discussion: https://postgr.es/m/15900-bc482754fe8d7415%40postgresql.org  
Discussion: https://postgr.es/m/15720-38c2b29e5d720187%40postgresql.org  

commit   : 2c84ea6cf994f5853de0f03600aa5df8156cf9f4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 9 Jul 2019 17:16:36 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 9 Jul 2019 17:16:36 -0400    

We were creating the cloned triggers with an empty list of arguments,  
losing the ones that had been specified by the user when creating the  
trigger in the partitioned table.  Repair.  
  
This was forgotten in commit 86f575948c77.  
  
Author: Patrick McHardy  
Reviewed-by: Tomas Vondra  
Discussion: https://postgr.es/m/20190709130027.amr2cavjvo7rdvac@access1.trash.net  
Discussion: https://postgr.es/m/15752-123bc90287986de4@postgresql.org  

commit   : e435c1e7d9d88264453c30f8d1969cb836a60509    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 9 Jul 2019 15:47:09 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 9 Jul 2019 15:47:09 +0200    

commit   : cba0fe024e35839688e3a3d256d1dcdf50baadaf    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 9 Jul 2019 18:11:01 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 9 Jul 2019 18:11:01 +1200    

Otherwise the regressplans.sh tests generate extremely slow nested  
loop joins.  Back-patch to 11 where the hash join tests came in.  
  
Reported-by: Michael Paquier  
Discussion: https://postgr.es/m/20190708055256.GB2709%40paquier.xyz  

commit   : 38c268dde0ae749a93acd750afd1aad9c8f01049    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 8 Jul 2019 23:04:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 8 Jul 2019 23:04:02 -0400    

Discussion: https://postgr.es/m/20190706202425.GA16933@telsasoft.com  
  
Author: Justin Pryzby  
  
Backpatch-through: 12  

commit   : ba0934251823145461b208d55d8c003576bbfd62    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 8 Jul 2019 19:39:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 8 Jul 2019 19:39:48 -0400    

Syntax is OpenSSL-specific, so only use it for OpenSSL.  
  
Discussion: https://postgr.es/m/8232E273-7B25-47F4-B0E7-3D4264106F82@yesql.se  
  
Author: Daniel Gustafsson  
  
Backpatch-through: head  

commit   : 481837783bee98795379153e7b60405f21fdb38b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 8 Jul 2019 19:31:16 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 8 Jul 2019 19:31:16 -0400    

Remove quote_all_identifiers from struct _dumpOptions.  
  
Discussion: https://postgr.es/m/d3d92ce9-78a4-8adb-0393-d3deeec29f7e@postgrespro.ru  
  
Author: Arthur Zakirov  
  
Backpatch-through: head  

commit   : 554106b1163853757b72ce14d7db5050c32bfa6a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 8 Jul 2019 14:51:53 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 8 Jul 2019 14:51:53 -0400    

Most block-based table AMs will need the exact same implementation of  
the relation_size callback as the heap, and if they use a standard  
page layout, they will likely need an implementation of the  
relation_estimate_size callback that is very similar to that of the  
heap.  Rearrange to facilitate code reuse.  
  
Patch by me, reviewed by Michael Paquier, Daniel Gustafsson, and  
Álvaro Herrera.  
  
Discussion: http://postgr.es/m/CA+TgmoZ6DBPnP1E-vRpQZUJQijJFD54F+SR_pxGiAAS-MyrigA@mail.gmail.com  

commit   : 482501d433b9f218d5a117571f1df9aebefe68bb    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Jul 2019 14:28:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Jul 2019 14:28:42 +0200    

Document that the data types of replicated tables do not need to  
match.  The documentation previously claimed that they had to match.  
  
Author: Robert Treat <rob@xzilla.net>  
Discussion: https://www.postgresql.org/message-id/flat/CAJSLCQ13==D8Ka2YLyctTm0Y+8MhGYcX_zj7fU0rqRzhcV++3w@mail.gmail.com  

commit   : 6b8548964bccd0f2e65c687d591b7345d5146bfa    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Jul 2019 13:15:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Jul 2019 13:15:09 +0900    

This addresses a couple of issues in the code:  
- Typos and inconsistencies in comments and function declarations.  
- Removal of unreferenced function declarations.  
- Removal of unnecessary compile flags.  
- A cleanup error in regressplans.sh.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/0c991fdf-2670-1997-c027-772a420c4604@gmail.com  

commit   : 7e9a4c5c3dca0d9637812d8991e96fc8f46800d9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 6 Jul 2019 23:18:46 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 6 Jul 2019 23:18:46 +0200    

Use  
  
    if (something() != 0)  
        error ...  
  
instead of just  
  
    if (something)  
        error ...  
  
The latter is not incorrect, but it's a bit confusing and not the  
common style.  
  
Discussion: https://www.postgresql.org/message-id/flat/5de61b6b-8be9-7771-0048-860328efe027%402ndquadrant.com  

commit   : d1a040543b49e0aad273e7766cd7e2fcf2b781fa    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 7 Jul 2019 09:58:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 7 Jul 2019 09:58:33 +0900    

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

commit   : fb30c9c1c5c36989d6b93906986358cb96936d64    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Jul 2019 11:25:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Jul 2019 11:25:37 -0400    

This code failed to account for the possibility that malloc() would  
change errno, resulting in wrong output for %m, not to mention the  
possibility of message truncation.  Such a change is obviously  
expected when malloc fails, but there's reason to fear that on some  
platforms even a successful malloc call can modify errno.  
  
Discussion: https://postgr.es/m/2576.1527382833@sss.pgh.pa.us  

commit   : b33283c36409aef7eddb5ba92bdd9300dd45d974    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 6 Jul 2019 15:02:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 6 Jul 2019 15:02:53 +0200    

commit   : 3f3542621f131379e32e9283d40853cb6d03a97f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 6 Jul 2019 14:58:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 6 Jul 2019 14:58:08 +0200    

In normal interactive mode, psql's log messages accidentally got a  
"psql:" prefix that was not supposed to be there.  This only happened  
if there was no .psqlrc file being read, so it wasn't discovered for a  
while.  Fix this by adding the appropriate logging format  
configuration call in the right code path.  
  
Discussion: https://www.postgresql.org/message-id/7586.1560540361@sss.pgh.pa.us  

commit   : 78d41f6c9b0e1c4bd28f9b80cd07c7530660312f    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 6 Jul 2019 11:41:23 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 6 Jul 2019 11:41:23 +0530    

Reported-by: Ashwin Agrawal  
Author: Ashwin Agrawal  
Reviewed-by: Amit Kapila  
Backpatch-through: 12, where it was introduced  
Discussion: https://postgr.es/m/CALfoeisgdZhYDrJOukaBzvXfJOK2FQ0szVMK7dzmcy6w93iDUA@mail.gmail.com  

commit   : cf20cc00a99155a8e41a1bb2a1e498624c86db29    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jul 2019 23:56:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jul 2019 23:56:34 -0400    

I chanced to notice while thumbing through lcov reports that we had  
exactly no coverage of BETWEEN SYMMETRIC, nor of current_time(N) and  
localtime(N).  Improve that.  
  
parse_expr.c still has a pretty awful coverage number, but a large part  
of that is due to lack of coverage of the operator_precedence_warning  
logic.  I have zero desire to write tests for that; I think ripping it  
out would be more sensible at this point.  

commit   : 79b94716e72086b07549b1c867a8ecdea6bae77e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jul 2019 19:28:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jul 2019 19:28:45 -0400    

These seem to be leftovers from old patches, perhaps.  
  
Masahiko Sawada  
  
Discussion: https://postgr.es/m/CAD21AoDuAYsRb3Q9aobkFZ6DZMWxsyg4HOmgkwgeWNfSkTwGxw@mail.gmail.com  

commit   : 0ab1a2e39b6f65b0f6a5879605ddbf12f9f50de4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jul 2019 14:17:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jul 2019 14:17:27 -0400    

The code for conversions SQL_ASCII <-> MULE_INTERNAL and  
SQL_ASCII <-> UTF8 was unreachable, because we long ago changed  
the wrapper functions pg_do_encoding_conversion() et al so that  
they have hard-wired behaviors for conversions involving SQL_ASCII.  
(At least some of those fast paths date back to 2002, though it  
looks like we may not have been totally consistent about this until  
later.)  Given the lack of complaints, nobody is dissatisfied with  
this state of affairs.  Hence, let's just remove the unreachable code.  
  
Also, change CREATE CONVERSION so that it rejects attempts to  
define such conversions.  Since we consider that SQL_ASCII represents  
lack of knowledge about the encoding in use, such a conversion would  
be semantically dubious even if it were reachable.  
  
Adjust a couple of regression test cases that had randomly decided  
to rely on these conversion functions rather than any other ones.  
  
Discussion: https://postgr.es/m/41163.1559156593@sss.pgh.pa.us  

commit   : ef777cb093e8cb45dd3ae9d3f1499c765147c1dd    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 5 Jul 2019 18:06:02 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 5 Jul 2019 18:06:02 +0200    

The itemlen variable used to be referenced in multiple places, but since  
reworking the serialization code it's used only in one assert. Fixed by  
removing the variable and calling the macro from the assert directly.  
  
Backpatch to 12, where this code was introduced.  
  
Reported-by: Jeff Janes  
Discussion: https://postgr.es/m/CAMkU=1zc_ovH9NZd_9ovuiEWkF9yX06URUDdXCmgDydf-bqB5A@mail.gmail.com  

commit   : 02e95a5049f7933cbde1dacf401604ea3fc02aa5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jul 2019 12:32:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jul 2019 12:32:36 -0400    

This is like \echo except that the text is sent to stderr not stdout.  
  
In passing, fix a pre-existing bug in \echo and \qecho: per documentation  
the -n switch should only be recognized when it is the first argument,  
but actually any argument matching "-n" was treated as a switch.  
(Should we back-patch that?)  
  
David Fetter (bug fix by me), reviewed by Fabien Coelho  
  
Discussion: https://postgr.es/m/20190421183115.GA4311@fetter.org  

commit   : e8fdcacc6cbeed7d1a2175c5eddf0b162e0cb7c4    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 5 Jul 2019 20:59:29 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 5 Jul 2019 20:59:29 +1200    

The Unix manual section that "man tcp" appears in varies, so let's  
just leave it out of the command to run.  

commit   : 594df378ffb04a72b713a13cc0a7166b3bced7b7    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 Jul 2019 08:33:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 5 Jul 2019 08:33:51 +0200    

commit   : 313f87a17155a6dbd27a3ce687cf59bd171fe75e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Jul 2019 12:21:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Jul 2019 12:21:11 +0900    

This is useful for monitoring, when it comes for example to calculations  
of WAL retention with replication slots and delays with a set of  
standbys.  
  
Bump catalog version.  
  
Author: Fabrízio de Royes Mello  
Reviewed-by: Surafel Temesgen  
Discussion: https://postgr.es/m/CAFcNs+oc8ZoHhowA4rR1GGCgG8QNgK_TOwPRVYQo5rYy8_PXzA@mail.gmail.com  

commit   : 8a810a177c80909b71e9fb3760a1d56ed988638a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Jul 2019 10:47:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Jul 2019 10:47:32 +0900    

The source defining the current fallback and hardcoded DH parameters  
has disappeared from the web a long time ago, and RFC 3526 defines the  
most current Diffie-Hellman MODP groups, so update to those new values.  
  
Author: Daniel Gustafsson  
Reviewed-by: Peter Eisentraut, Michael Paquier  
Discussion: https://postgr.es/m/5E60AC9A-CB10-4851-9EF2-7209490A164C@yesql.se  

commit   : 08aa131c7a72195113ab3a7b191fe8014dd3a898    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 5 Jul 2019 00:45:20 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 5 Jul 2019 00:45:20 +0200    

The serialization format of multivariate MCV lists included alignment in  
order to allow direct access to part of the serialized data, but despite  
multiple fixes (see for example commits d85e0f366a and ea4e1c0e8f) this  
proved to be problematic.  
  
This commit abandons alignment in the serialized format, and just copies  
everything during deserialization.  We now also track amount of memory  
needed after deserialization (including alignment), which allows us to  
deserialize the MCV list in a single pass.  
  
Bump catversion, as this affects contents of pg_statistic_ext_data.  
  
Backpatch to 12, where multi-column MCV lists were introduced.  
  
Author: Tomas Vondra  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/2201.1561521148@sss.pgh.pa.us  

commit   : 4d66285adc6bb4f9e4fd394d478d663cbccb5fc8    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 4 Jul 2019 23:43:04 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 4 Jul 2019 23:43:04 +0200    

The function pg_mcv_list_items() returns values stored in MCV items. The  
items may contain columns with different data types, so the function was  
generating text array-like representation, but in an ad-hoc way without  
properly escaping various characters etc.  
  
Fixed by simply building a text[] array, which also makes it easier to  
use from queries etc.  
  
Requires changes to pg_proc entry, so bump catversion.  
  
Backpatch to 12, where multi-column MCV lists were introduced.  
  
Author: Tomas Vondra  
Reviewed-by: Dean Rasheed  
Discussion: https://postgr.es/m/20190618205920.qtlzcu73whfpfqne@development  

commit   : e365a581c246a8e18f38cc530013391329dcdb02    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 4 Jul 2019 23:02:02 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 4 Jul 2019 23:02:02 +0200    

When building multi-column MCV lists, we compute base frequency for each  
item, i.e. a product of per-column frequencies for values from the item.  
As a value may be in multiple groups, the code was scanning the whole  
array of groups while adding items to the MCV list.  This works fine as  
long as the number of distinct groups is small, but it's easy to trigger  
trigger O(N^2) behavior, especially after increasing statistics target.  
  
This commit precomputes frequencies for values in all columns, so that  
when computing the base frequency it's enough to make a simple bsearch  
lookup in the array.  
  
Backpatch to 12, where multi-column MCV lists were introduced.  
  
Discussion: https://postgr.es/m/20190618205920.qtlzcu73whfpfqne@development  

commit   : d5ab9df7774b4570ff50e64b7fa3ba8295596d06    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 6 Jun 2019 14:32:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 6 Jun 2019 14:32:54 +0200    

We can use the %zu format specifier directly, no need to cast to int.  

commit   : 6a1cd8b9236dcfa91b40af3a8337859e16ba7113    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 6 Jun 2019 14:14:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 6 Jun 2019 14:14:29 +0200    

Because there is no portable int64/uint64 format specifier and we  
can't stick macros like INT64_FORMAT into the middle of a translatable  
string, we have been using various workarounds that put the number to  
be printed into a string buffer first.  Now that we always use our own  
sprintf(), we can rely on %lld and %llu to work, so we can use those.  
  
This patch undoes this workaround in a few places where it was  
egregiously verbose.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/CAH2-Wz%3DWbNxc5ob5NJ9yqo2RMJ0q4HXDS30GVCobeCvC9A1L9A%40mail.gmail.com  

commit   : 7b925e12703652fef63a2fbbb28d3407b2971d6e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 4 Jul 2019 13:10:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 4 Jul 2019 13:10:41 +0200    

The main change is a new stemmer for Greek.  There are minor changes  
in the Danish and French stemmers.  
  
Author: Panagiotis Mavrogiorgos <pmav99@gmail.com>  

commit   : dedb6e0143554e76d4d11376d65c0aa68f8412d4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 4 Jul 2019 12:31:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 4 Jul 2019 12:31:08 +0200    

commit   : cfc40d384ae51ea2886d599d2008ae57b529e6ea    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 4 Jul 2019 16:08:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 4 Jul 2019 16:08:09 +0900    

This is a follow-up refactoring after 09ec55b and b674211, which has  
proved that the encoding and decoding routines used by SCRAM have a  
poor interface when it comes to check after buffer overflows.  This adds  
an extra argument in the shape of the length of the result buffer for  
each routine, which is used for overflow checks when encoding or  
decoding an input string.  The original idea comes from Tom Lane.  
  
As a result of that, the encoding routine can now fail, so all its  
callers are adjusted to generate proper error messages in case of  
problems.  
  
On failure, the result buffer gets zeroed.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/20190623132535.GB1628@paquier.xyz  

commit   : d5ab9a891cb590aad4278026b2edda685f2524a2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 4 Jul 2019 11:33:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 4 Jul 2019 11:33:42 +0900    

The last set of scenarios did an initialization of nodes followed by an  
extra command to set up the authentication policy with pg_regress  
--config-auth.  This configuration step can be integrated directly using  
the option auth_extra from PostgresNode::init when initializing the  
node, saving from one extra command.  On Windows, this also restricts  
more pg_ident.conf for the SSPI user mapping by removing the entry of  
the OS user running the test, which is not needed anyway.  
  
Note that IPC::Run mishandles double quotes, hence the restore user name  
is changed to map with that.  This was already done in the test as a  
later step, but not in a consistent way, causing the switch to use  
auth_extra to fail.  
  
Found while reviewing ca129e5.  
  
Discussion: https://postgr.es/m/20190703062024.GD3084@paquier.xyz  

commit   : 8abc13a88938ef473b8a486186f1b96630450728    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 4 Jul 2019 13:01:13 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 4 Jul 2019 13:01:13 +1200    

This changes various places where appendPQExpBuffer was used in places  
where it was possible to use appendPQExpBufferStr, and likewise for  
appendStringInfo and appendStringInfoString.  This is really just a  
stylistic improvement, but there are also small performance gains to be  
had from doing this.  
  
Discussion: http://postgr.es/m/CAKJS1f9P=M-3ULmPvr8iCno8yvfDViHibJjpriHU8+SXUgeZ=w@mail.gmail.com  

commit   : 5683b34956b4e8da9dccadc2e3a53b86104ebb33    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Jul 2019 18:08:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Jul 2019 18:08:53 -0400    

A function that is declared to return a named composite type must  
return tuple datums that are physically marked as having that type.  
The plpgsql code path that allowed directly returning an expanded-record  
datum forgot to check that, so that an expanded record marked as type  
RECORDOID could be returned if it had a physically-compatible tupdesc.  
This'd be harmless, I think, if the record value never escaped the  
current session --- but it's possible for it to get stored into a table,  
and then subsequent sessions can't interpret the anonymous record type.  
  
Fix by flattening the record into a tuple datum and overwriting its  
type/typmod fields, if its declared type doesn't match the function's  
declared type.  (In principle it might be possible to just change the  
expanded record's stored type ID info, but there are enough tricky  
consequences that I didn't want to mess with that, especially not in  
a back-patched bug fix.)  
  
Per bug report from Steve Rogerson.  Back-patch to v11 where the bug  
was introduced.  
  
Discussion: https://postgr.es/m/cbaecae6-7b87-584e-45f6-4d047b92ca2a@yewtc.demon.co.uk  

commit   : 03e7b302b1d5a67758e756b1f64686c29d37558f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Jul 2019 12:18:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Jul 2019 12:18:10 -0400    

Forgotten in commit 9a2ea6183.  

commit   : 9a2ea618323a4cf8ca7eb6a828b08c6e39b95cdd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Jul 2019 11:46:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Jul 2019 11:46:34 -0400    

In verbose mode, listTables() now emits a "Persistence" column  
showing whether the table/index/view/etc is permanent, temporary,  
or unlogged.  
  
David Fetter, reviewed by Fabien Coelho and Rafia Sabih  
  
Discussion: https://postgr.es/m/20190423005642.GZ28936@fetter.org  

commit   : a5be4062f7bf2ae9487c5a31ee337a56425cdc84    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 3 Jul 2019 23:44:54 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 3 Jul 2019 23:44:54 +1200    

d4c3a156c added code to remove columns that were not part of a table's  
PRIMARY KEY constraint from the GROUP BY clause when all the primary key  
columns were present in the group by.  This is fine to do since we know  
that there will only be one row per group coming from this relation.  
However, the logic failed to consider inheritance parent relations.  These  
can have child relations without a primary key, but even if they did, they  
could duplicate one of the parent's rows or one from another child  
relation.  In this case, those additional GROUP BY columns are required.  
  
Fix this by disabling the optimization for inheritance parent tables.  
In v11 and beyond, partitioned tables are fine since partitions cannot  
overlap and before v11 partitioned tables could not have a primary key.  
  
Reported-by: Manuel Rigger  
Discussion: http://postgr.es/m/CA+u7OA7VLKf_vEr6kLF3MnWSA9LToJYncgpNX2tQ-oWzYCBQAw@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 2a1612104cadbfdc739ff0370f279779f323c3b5    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 3 Jul 2019 17:51:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 3 Jul 2019 17:51:00 +0900    

Previously, in the loop in postgresAcquireSampleRowsFunc() to iterate  
fetching rows from a given remote table, we redundantly 1) determined the  
fetch size by parsing the table's server/table-level options and then 2)  
constructed the fetch command; remove that redundancy.  
  
Author: Etsuro Fujita  
Reviewed-by: Julien Rouhaud  
Discussion: https://postgr.es/m/CAPmGK17_urk9qkLV65_iYMFw64z5qhdfhY=tMVV6Jg4KNYx8+w@mail.gmail.com  

commit   : e72489e101b21c328e3d10ca64e5367c60f424a5    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 2 Jul 2019 03:51:13 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 2 Jul 2019 03:51:13 +0200    

Author: "Zhang, Jie" <zhangjie2@cn.fujitsu.com>  

commit   : 8372e3c98fbbd529e4545c4d7982e278e118958e    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 2 Jul 2019 03:42:09 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 2 Jul 2019 03:42:09 +0200    

Author: Yang Xiao <YangX92@hotmail.com>  

commit   : 75220fb62b1387b61f92c42b1bd147cb30607012    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 2 Jul 2019 03:34:58 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 2 Jul 2019 03:34:58 +0200    

commit   : 84c41ae81bdf15cac71cc5ae0af69b4815594522    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 2 Jul 2019 23:44:30 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 2 Jul 2019 23:44:30 +0100    

Author: Alexey Kondratov <a.kondratov@postgrespro.ru>  

commit   : 24c7000f64487323fedb52b8aeadf2c84274dcf5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 2 Jul 2019 23:18:43 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 2 Jul 2019 23:18:43 +0100    

These are no longer needed/allowed with the new logging API.  

commit   : b4771d7c7f37d19e2879b18e288f681849d55806    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Jul 2019 14:04:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Jul 2019 14:04:42 -0400    

Commit 4f3b38fe2 supposed that complete_from_const() is equivalent to  
the one-element-list case of complete_from_list(), but that's not  
really true at all.  complete_from_const() supposes that the completion  
is certain enough to justify wiping out whatever the user typed, while  
complete_from_list() will only provide completions that match the  
word-so-far.  
  
In practice, given the lame parsing technology used by tab-complete.c,  
it's fairly hard to believe that we're *ever* certain enough about  
a completion to justify auto-correcting user input that doesn't match.  
  
Hence, remove the inappropriate unification of the two cases.  
As things now stand, complete_from_const() is used only for the  
situation where we have no matches and we need to keep readline  
from applying its default complete-with-file-names behavior.  
  
This (mis?) behavior actually exists much further back, but  
I'm hesitant to change it in released branches.  It's not too  
late for v12, though, especially seeing that the aforesaid  
commit is new in v12.  
  
Per gripe from Ken Tanzer.  
  
Discussion: https://postgr.es/m/CAD3a31XpXzrZA9TT3BqLSHghdTK+=cXjNCE+oL2Zn4+oWoc=qA@mail.gmail.com  

commit   : 0ec3e13c69779117c8cfa39adcc6863631dedd44    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Jul 2019 13:35:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Jul 2019 13:35:14 -0400    

Don't think that the context "UPDATE tab SET var =" is a GUC-setting  
command.  
  
If we have "SET var =" but the "var" is not a known GUC variable,  
don't offer any completions.  The most likely explanation is that  
we've misparsed the context and it's not really a GUC-setting command.  
  
Per gripe from Ken Tanzer.  Back-patch to 9.6.  The issue exists  
further back, but before 9.6 the code looks very different and it  
doesn't actually know whether the "var" name matches anything,  
so I desisted from trying to fix it.  
  
Discussion: https://postgr.es/m/CAD3a31XpXzrZA9TT3BqLSHghdTK+=cXjNCE+oL2Zn4+oWoc=qA@mail.gmail.com  

commit   : 4d6603f28dfc4a1cab0d7d317855d935e314297a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Jul 2019 12:32:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Jul 2019 12:32:49 -0400    

The previous rule was "primary key (if any) first, then other unique  
indexes in name order, then all other indexes in name order".  
But the preference for unique indexes seems a bit obsolete since the  
introduction of exclusion constraints.   It's no longer the case  
that unique indexes are the only ones that constrain what data can  
be in the table, and it's hard to see what other rationale there is  
for separating out unique indexes.  Other new features like the  
possibility for some indexes to be INVALID (hence, not constraining  
anything) make this even shakier.  
  
Hence, simplify the sort order to be "primary key (if any) first,  
then all other indexes in name order".  
  
No documentation change, since this was never documented anyway.  
A couple of existing regression test cases change output, though.  
  
Discussion: https://postgr.es/m/14422.1561474929@sss.pgh.pa.us  

commit   : 66c5bd3a6fd8a4c317412838ab3870ab251833b6    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 1 Jul 2019 22:28:08 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 1 Jul 2019 22:28:08 -0700    

Remove a very old Berkeley era comment that doesn't seem to have  
anything to do with the current locking considerations within  
_bt_getroot().  
  
Discussion: https://postgr.es/m/CAH2-WzmA2H+rL-xxF5o6QhMD+9x6cJTnz2Mr3Li_pbPBmqoTBQ@mail.gmail.com  

commit   : 2b1394fc2b52a2573d08aa626e7b49568f27464e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 Jul 2019 14:02:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 Jul 2019 14:02:33 +0900    

This fixes at the same time a set of inconsistencies in the  
documentation and the scripts related to the versions of Windows SDK  
supported.  
  
Author: Haribabu Kommi  
Reviewed-by: Andrew Dunstan, Juan José Santamaría Flecha, Michael  
Paquier  
Discussion: https://postgr.es/m/CAJrrPGcfqXhfPyMrny9apoDU7M1t59dzVAvoJ9AeAh5BJi+UzA@mail.gmail.com  

commit   : 9adda24543e354317abf5400d7e7d3961a93bce6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 Jul 2019 11:36:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 2 Jul 2019 11:36:53 +0900    

This merges the portion related to REINDEX SYSTEM into the routine  
already available for all the other reindex types, making the query  
generation cleaner.  While on it, change the handling of the reindex  
types using an enum, which allows to get rid of the hardcoded strings  
used directly in the query generation present for the same purpose (aka  
"TABLE", "DATABASE", etc.).  
  
Per discussion with Julien Rouhaud, Tom Lane, Alvaro Herrera and me.  
  
Author: Julien Rouhaud  
Discussion: https://postgr.es/m/CAOBaU_bSmSik_WRK9niDnm-3NkNZky6+uKxkmQwvthZvMWpS5A@mail.gmail.com  

commit   : c72f9b9502eadb6b84c6681cdb3bff12b35d3c8a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Jul 2019 23:46:24 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Jul 2019 23:46:24 +0100    

This is long obsolete.  
  
Discussion: https://www.postgresql.org/message-id/8eacdc0d-123f-dbca-bacf-0a68766a4889@2ndquadrant.com  

commit   : 615cebc94b5ef8fbe353e3c8b838b1e97bcdfd49    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jul 2019 12:50:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jul 2019 12:50:55 -0400    

Let the hacking begin ...  

commit   : 9e1c9f959422192bbe1b842a2a1ffaf76b080196    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jul 2019 12:37:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jul 2019 12:37:52 -0400    

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

commit   : 145b18688c04963efcab8ef3e7e10659bf783eb1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jul 2019 12:09:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jul 2019 12:09:06 -0400    

Looks like one copy of this text didn't get updated.  
  
Justin Pryzby  
  
Discussion: https://postgr.es/m/20190701155932.GA22866@telsasoft.com  

commit   : f5db56fc4d6e95c582b61c99328ea0702b869fa0    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 2 Jul 2019 03:44:56 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 2 Jul 2019 03:44:56 +1200    

This reverts commits 4de60244e and b2d69806d. Further thought is  
required to make this work properly.  

commit   : b2d69806d8cc902802a7b56ba37fb7c55e58b0ed    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 2 Jul 2019 03:07:15 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 2 Jul 2019 03:07:15 +1200    

4de60244e added the call to table_finish_bulk_insert to the  
CopyMultiInsertBufferCleanup function.  We use a CopyMultiInsertBuffer even  
for non-partitioned tables, so having the cleanup do that meant we would  
call table_finsh_bulk_insert twice when performing COPY FROM with  
a non-partitioned table.  
  
Here we can just remove the direct call in CopyFrom and let  
CopyMultiInsertBufferCleanup handle the call instead.  

commit   : 4de60244e2fcdeb100afc7f8bf5c28b32923a637    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 2 Jul 2019 01:23:26 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 2 Jul 2019 01:23:26 +1200    

86b85044e abstracted calls to heap functions in COPY FROM to support a  
generic table AM.  However, when performing a copy into a partitioned  
table, this commit neglected to call table_finish_bulk_insert for each  
partition.  Before 86b85044e, when we always called the heap functions,  
there was no need to call heapam_finish_bulk_insert for partitions since  
it only did any work when performing a copy without WAL. For partitioned  
tables, this was unsupported anyway, so there was no issue. With pluggable  
storage, we can't make any assumptions about what the table AM might want  
to do in its equivalent function, so we'd better ensure we always call  
table_finish_bulk_insert each partition that's received a row.  
  
For now, we make the table_finish_bulk_insert call whenever we evict a  
CopyMultiInsertBuffer out of the CopyMultiInsertInfo.  This does mean  
that it's possible that we call table_finish_bulk_insert multiple times  
per partition, which is not a problem other than being an inefficiency.  
Improving this requires a more invasive patch, so let's leave that for  
another day.  
  
In passing, move the table_finish_bulk_insert for the target of the COPY  
command so that it's only called when we're actually performing bulk  
inserts.  We don't need to call this when inserting 1 row at a time.  
  
Reported-by: Robert Haas  
Discussion: https://postgr.es/m/CA+TgmoYK=6BpxiJ0tN-p9wtH0BTAfbdxzHhwou0mdud4+BkYuQ@mail.gmail.com  

commit   : 95bbe5d82e428db342fa3ec60b95f1b9873741e5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Jul 2019 13:34:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Jul 2019 13:34:31 +0200    

commit   : 1b29e990e352885642149262859b83c19d362405    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Jul 2019 13:07:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 1 Jul 2019 13:07:14 +0200    

commit   : c74d49d41c9e0fabeb1179dcabfb3137833ed831    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 1 Jul 2019 10:00:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 1 Jul 2019 10:00:23 +0900    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/af27d1b3-a128-9d62-46e0-88f424397f44@gmail.com  

commit   : 459c3cdb4ad8323bfe6bcae0186a3831e0c89c94    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 30 Jun 2019 17:34:17 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 30 Jun 2019 17:34:17 -0700    

UBSan complains about this.  Instead, cast to a suitable type requiring  
only 4-byte alignment.  DatumGetAnyArrayP() already assumes one can cast  
between AnyArrayType and ArrayType, so this doesn't introduce a new  
assumption.  Back-patch to 9.5, where AnyArrayType was introduced.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/20190629210334.GA1244217@rfd.leadboat.com  

commit   : da53be23d1c5e529675e958eaee54cfed4e4dbac    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sun, 30 Jun 2019 23:49:13 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sun, 30 Jun 2019 23:49:13 +0100    

The logic in reorder_grouping_sets to order grouping set elements to  
match a pre-specified sort ordering was defective, resulting in  
unnecessary sort nodes (though the query output would still be  
correct). Repair, simplifying the code a little, and add a test.  
  
Per report from Richard Guo, though I didn't use their patch. Original  
bug seems to have been my fault.  
  
Backpatch back to 9.5 where grouping sets were introduced.  
  
Discussion: https://postgr.es/m/CAN_9JTzyjGcUjiBHxLsgqfk7PkdLGXiM=pwM+=ph2LsWw0WO1A@mail.gmail.com  

commit   : c000a47ad1fdd4fb92c7068279d97e0c3db4f8eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Jun 2019 14:05:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Jun 2019 14:05:24 -0400    

There's nothing to build here, and that was confusing AddContrib().  
Per buildfarm.  

commit   : 681cca86f5071379c4a8599ef9387b666b7e6879    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Jun 2019 13:34:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Jun 2019 13:34:45 -0400    

Up to now, pg_regress --config-auth had a hard-wired assumption  
that the target cluster uses the default bootstrap superuser name.  
pg_dump's 010_dump_connstr.pl TAP test uses non-default superuser  
names, and was klugily getting around the restriction by listing  
the desired superuser name as a role to "create".  This is pretty  
confusing (or at least, it confused me).  Let's make it clearer by  
allowing --config-auth mode to be told the bootstrap superuser name.  
Repurpose the existing --user switch for that, since it has no  
other function in --config-auth mode.  
  
Per buildfarm.  I don't have an environment at hand in which I can  
test this fix, but the buildfarm should soon show if it works.  
  
Discussion: https://postgr.es/m/3142.1561840611@sss.pgh.pa.us  

commit   : c91504b958e1647f87ffb7168e61db75ca09b928    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Jun 2019 12:51:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Jun 2019 12:51:08 -0400    

This test script is unsafe to run in "make installcheck" mode for  
(at least) two reasons: it creates and destroys some role names  
that don't follow the "regress_xxx" naming convention, and it  
sets and then resets the application_name GUC attached to every  
existing role.  While we've not had complaints, these surely are  
not good things to do within a production installation, and  
regress.sgml pretty clearly implies that we won't do them.  
  
Rather than lose test coverage altogether, let's just move this  
script somewhere where it will get run by "make check" but not  
"make installcheck".  src/test/modules/ already has that property.  
  
Since it seems likely that we'll want other regression tests in  
future that also exceed the constraints of "make installcheck",  
create a generically-named src/test/modules/unsafe_tests/  
directory to hold them.  
  
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us  

commit   : 2e810508f6b0d89621094445620a1bea3ceff3f1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 30 Jun 2019 13:25:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 30 Jun 2019 13:25:33 +0200    

Using PG_RETURN_LSN() from non-fmgr pg_lsn_in_internal() happened to  
work on some platforms, but should just be a plain "return".  

commit   : 21f428ebde39339487c271a830fed135d6032d73    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 30 Jun 2019 10:15:25 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 30 Jun 2019 10:15:25 +0200    

Instead of calling pg_lsn_in() in check_recovery_target_lsn and  
timestamptz_in() in check_recovery_target_time, reorganize the  
respective code so that we don't raise any errors in the check hooks.  
The previous code tried to use PG_TRY/PG_CATCH to handle errors in a  
way that is not safe, so now the code contains no ereport() calls and  
can operate safely within the GUC error handling system.  
  
Moreover, since the interpretation of the recovery_target_time string  
may depend on the time zone, we cannot do the final processing of that  
string until all the GUC processing is done.  Instead,  
check_recovery_target_time() now does some parsing for syntax  
checking, but the actual conversion to a timestamptz value is done  
later in the recovery code that uses it.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/20190611061115.njjwkagvxp4qujhp%40alap3.anarazel.de  

commit   : 666cbae16da46b833f57ef8b12ff0bf215684d9c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 12 Jun 2019 11:29:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 12 Jun 2019 11:29:53 +0200    

The date/time values 'current', 'invalid', and 'undefined' were  
removed a long time ago, but the code still contains explicit error  
handling for the transition.  To simplify the code and avoid having to  
handle these values everywhere, just remove the recognition of these  
tokens altogether now.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  

commit   : 54100f5c6052404f68de9ce7310ceb61f1c291f8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Jun 2019 11:34:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Jun 2019 11:34:00 -0400    

In commit 18555b132 we tentatively established a rule that regression  
tests should use names containing "regression" for databases, and names  
starting with "regress_" for all other globally-visible object names, so  
as to circumscribe the side-effects that "make installcheck" could have  
on an existing installation.  
  
This commit adds a simple enforcement mechanism for that rule: if the code  
is compiled with ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS defined, it  
will emit a warning (not an error) whenever a database, role, tablespace,  
subscription, or replication origin name is created that doesn't obey the  
rule.  Running one or more buildfarm members with that symbol defined  
should be enough to catch new violations, at least in the regular  
regression tests.  Most TAP tests wouldn't notice such warnings, but  
that's actually fine because TAP tests don't execute against an existing  
server anyway.  
  
Since it's already the case that running src/test/modules/ tests in  
installcheck mode is deprecated, we can use that as a home for tests  
that seem unsafe to run against an existing server, such as tests that  
might have side-effects on existing roles.  Document that (though this  
commit doesn't in itself make it any less safe than before).  
  
Update regress.sgml to define these restrictions more clearly, and  
to clean up assorted lack-of-up-to-date-ness in its descriptions of  
the available regression tests.  
  
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us  

commit   : ca129e58c01f29ef24a734313ff315933b3d5b67    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Jun 2019 11:09:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Jun 2019 11:09:03 -0400    

In commit 18555b132 we tentatively established a rule that regression  
tests should use names containing "regression" for databases, and names  
starting with "regress_" for all other globally-visible object names, so  
as to circumscribe the side-effects that "make installcheck" could have on  
an existing installation.  However, no enforcement mechanism was created,  
so it's unsurprising that some new violations have crept in since then.  
  
In fact, a whole new *category* of violations has crept in, to wit we now  
also have globally-visible subscription and replication origin names, and  
"make installcheck" could very easily clobber user-created objects of  
those types.  So it's past time to do something about this.  
  
This commit sanitizes the tests enough that they will pass (i.e. not  
generate any visible warnings) with the enforcement mechanism I'll add  
in the next commit.  There are some TAP tests that still trigger the  
warnings, but the warnings do not cause test failure.  Since these tests  
do not actually run against a pre-existing installation, there's no need  
to worry whether they could conflict with user-created objects.  
  
The problem with rolenames.sql testing special role names like "user"  
is still there, and is dealt with only very cosmetically in this patch  
(by hiding the warnings :-().  What we actually need to do to be safe is  
to take that test script out of "make installcheck" altogether, but that  
seems like material for a separate patch.  
  
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us  

commit   : a1e61badf97bc446053145ba40de6db835678ce3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Jun 2019 10:30:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Jun 2019 10:30:08 -0400    

Since we generate such names internally, it seems like a good idea  
to have a policy of disallowing them for user use, as we do for many  
other object types.  Otherwise attempts to use them will randomly  
fail due to collisions with internally-generated names.  
  
Discussion: https://postgr.es/m/3606.1561747369@sss.pgh.pa.us  

commit   : c0faa727507ed34db0d02769d21bbaaf9605e2e4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 29 Jun 2019 11:14:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 29 Jun 2019 11:14:21 +0900    

libpq/libpq-be.h is included by libpq/libpq.h so there is no need to  
explicitly include it separately.  
  
Author: Daniel Gustafsson  
Reviewed-by: Julien Rouhaud  
Discussion: https://postgr.es/m/A4852E46-9ED1-4861-A23B-22A83E34A084@yesql.se  

commit   : 23cccb17fe0bbb5df86780da5c346cc060c21421    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 28 Jun 2019 14:51:08 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 28 Jun 2019 14:51:08 -0400    

We forgot to map column numbers to/from the default partition for  
various operations, leading to valid cases failing with spurious  
errors, such as  
ERROR:  attribute N of type some_partition has been dropped  
  
It was also possible that the search for conflicting rows in the default  
partition when attaching another partition would fail to detect some.  
Secondarily, it was also possible that such a search should be skipped  
(because the constraint was implied) but wasn't.  
  
Fix all this by mapping column numbers when necessary.  
  
Reported by: Daniel Wilches  
Author: Amit Langote  
Discussion: https://postgr.es/m/15873-8c61945d6b3ef87c@postgresql.org  

commit   : 74b7cc8c02137f059703972aa14445b1e073f005    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 28 Jun 2019 11:11:26 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 28 Jun 2019 11:11:26 +1200    

The stated reason for acquiring predicate locks on heap pages hasn't  
existed since commit c01262a8, so fix the comment.  Perhaps in a later  
release we'll also be able to change the code to use tuple locks.  
  
Back-patch all the way.  
  
Reviewed-by: Ashwin Agrawal  
Discussion: https://postgr.es/m/CAEepm%3D2GK3FVdnt5V3d%2Bh9njWipCv_fNL%3DwjxyUhzsF%3D0PcbNg%40mail.gmail.com  

commit   : 69fd82fedd746b82427097883daf2921dd77584e    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 27 Jun 2019 17:41:29 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 27 Jun 2019 17:41:29 +0200    

Commit 83e176ec1 moved row sampling functions from analyze.c to  
utils/misc/sampling.c, but failed to update comment referring to  
the sampling algorithm from Jeff Vitter's paper. Correct the  
comment by pointing to utils/misc/sampling.c.  
  
Author: Etsuro Fujita  
Discussion: https://postgr.es/m/CAPmGK154gp%2BQd%3DcorQOv%2BPmbyVyZBjp_%2Bhb766UJeD1e_ie6XQ%40mail.gmail.com  

commit   : 050098b14e33a5d3dfabf172ebbddd20c6bb4665    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 27 Jun 2019 11:57:10 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 27 Jun 2019 11:57:10 -0400    

Evidenced by failure under RELCACHE_FORCE_RELEASE (buildfarm member  
prion).  
  
Author: Amit Langote  
Discussion: https://postgr.es/m/CA+HiwqGV=k_Eh4jBiQw66ivvdG+EUkrEYeHTYL1SvDj_YOYV0g@mail.gmail.com  

commit   : f2f0082ef5969b57d0b52d0c2e891872ed1b0a51    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 Jun 2019 15:57:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 27 Jun 2019 15:57:14 +0200    

Function was renamed/replaced in  
c2fe139c201c48f1133e9fbea2dd99b8efe2fadd but the header comment was  
not updated.  

commit   : 322c5bfdc3d76f6463768ecd8fced30c881b8be5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Jun 2019 08:25:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 27 Jun 2019 08:25:26 +0900    

fe0a0b5 has removed the last use of this routine from pgcrypto, leading  
to a useless symbol definition and an extra configure check.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson, Tom Lane  
Discussion: https://postgr.es/m/20190626142544.GN1714@paquier.xyz  

commit   : 55ed3defc966cf718fe1e8c0efe964580bb23351    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 26 Jun 2019 18:38:51 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 26 Jun 2019 18:38:51 -0400    

When a partitioned tables contains foreign tables as partitions, it is  
not possible to implement unique or primary key indexes -- but when  
regular indexes are created, there is no reason to do anything other  
than ignoring such partitions.  We were raising errors upon encountering  
the foreign partitions, which is unfriendly and doesn't protect against  
any actual problems.  
  
Relax this restriction so that index creation is allowed on partitioned  
tables containing foreign partitions, becoming a no-op on them.  (We may  
later want to redefine this so that the FDW is told to create the  
indexes on the foreign side.)  This applies to CREATE INDEX, as well as  
ALTER TABLE / ATTACH PARTITION and CREATE TABLE / PARTITION OF.  
  
Backpatch to 11, where indexes on partitioned tables were introduced.  
  
Discussion: https://postgr.es/m/15724-d5a58fa9472eef4f@postgresql.org  
Author: Álvaro Herrera  
Reviewed-by: Amit Langote  

commit   : 65e6d42140c8d9918638b9f73528288ab980af82    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Jun 2019 23:06:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Jun 2019 23:06:17 -0400    

contrib/amcheck didn't get the memo either.  

commit   : c360477d2e2f65fdea64aa8bc94a6286d0883f7a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Jun 2019 22:53:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Jun 2019 22:53:42 -0400    

Commit 1c5d9270e had not gotten the word about this.  (For previous  
context, see 18555b132.)  

commit   : d993e0fb82ffaa15be72c1ac10403bfa06708069    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Jun 2019 10:44:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 26 Jun 2019 10:44:46 +0900    

Up to now, the MSVC build scripts are able to support only one fixed  
version of OpenSSL, and they lacked logic to detect the version of  
OpenSSL a given compilation of Postgres is linking to (currently 1.0.2,  
the latest LTS of upstream which will be EOL'd at the end of 2019).  
  
This commit adds more logic to detect the version of OpenSSL used by a  
build and makes use of it to add support for compilation with OpenSSL  
1.1.0 which requires a new set of compilation flags to work properly.  
  
The supported OpenSSL installers have changed their library layer with  
various library renames with the upgrade to 1.1.0, making the logic a  
bit more complicated.  The scripts are now able to adapt to the new  
world order.  
  
Reported-by: Sergey Pashkov  
Author: Juan José Santamaría Flecha, Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/15789-8fc75dea3c5a17c8@postgresql.org  

commit   : ce59b75d449d9152667ce3e9eab33ef2872bfd98    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Jun 2019 09:09:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 25 Jun 2019 09:09:27 +0900    

a96c41f has introduced the option for heap, but it still lacked the  
variant to control the behavior for toast relations.  
  
While on it, refactor the tests so as they stress more scenarios with  
the various values that vacuum_index_cleanup can use.  It would be  
useful to couple those tests with pageinspect to check that pages are  
actually cleaned up, but this is left for later.  
  
Author: Masahiko Sawada, Michael Paquier  
Reviewed-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAD21AoCqs8iN04RX=i1KtLSaX5RrTEM04b7NHYps4+rqtpWNEg@mail.gmail.com  

commit   : 0089c3059cb6b3dd20cf072f26d1a7a33412df39    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 25 Jun 2019 09:29:53 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 25 Jun 2019 09:29:53 +1200    

It's useful to be able to pass down options like -s and -j.  
  
Back-patch to 9.5, like commit a76200de.  
  
Discussion: https://postgr.es/m/CA%2BhUKG%2Be1M8-BbL%3DPqhTp6oO6XPO6%2Bs9WGQMLfbuZ%3DG9CtzyXg%40mail.gmail.com  

commit   : a2dec374807565f6337915fb236bb3ae37af0644    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 25 Jun 2019 09:17:04 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 25 Jun 2019 09:17:04 +1200    

As of commit e5253fdc, it is no longer true that the leader always  
executes the subplan of a Gather Merge node.  Remove comment to that  
effect.  
  
Back-patch to 11.  
  
Discussion: https://postgr.es/m/CA%2BhUKGJEaZJYezXAOutuiWT%2BfxCA44%2BoKtVPAND2ubLiigR%3D-w%40mail.gmail.com  

commit   : ccfcc8fdbd9bdbfd18fda5d7c698af8d175f5319    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jun 2019 17:19:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jun 2019 17:19:32 -0400    

Move ATExecAlterColumnGenericOptions away from where it was unthinkingly  
dropped, in the middle of a lot of ALTER COLUMN TYPE code.  I don't have  
any high principles about where to put it instead, so let's just put it  
after ALTER COLUMN TYPE and before ALTER OWNER, matching existing  
decisions about how to order related code stanzas.  
  
Also add the minimal function header comment that the original author  
was too cool to bother with.  
  
Along the way, upgrade header comments for nearby ALTER COLUMN TYPE  
functions.  
  
Discussion: https://postgr.es/m/14787.1561403130@sss.pgh.pa.us  

commit   : 82be666ee36842af2a1b81e570bd5578f264de65    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 22:15:43 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 22:15:43 +0200    

commit   : 2cadefbb97ff8e5566476780dc200db06af6ba09    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 22:09:50 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 22:09:50 +0200    

commit   : eb8d05bfeca416a970cc33af5915ec7b4f4a2f69    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 22:09:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 22:09:29 +0200    

commit   : f946a409143d01951411382fbc3c91c7eb640094    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jun 2019 16:43:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jun 2019 16:43:05 -0400    

This patch reverts all the code changes of commit e76de8861, which turns  
out to have been seriously misguided.  We can't wait till later to compute  
the definition string for an index; we must capture that before applying  
the data type change for any column it depends on, else ruleutils.c will  
deliverr wrong/misleading results.  (This fine point was documented  
nowhere, of course.)  
  
I'd also managed to forget that ATExecAlterColumnType executes once per  
ALTER COLUMN TYPE clause, not once per statement; which resulted in the  
code being basically completely broken for any case in which multiple ALTER  
COLUMN TYPE clauses are applied to a table having non-constraint indexes  
that must be rebuilt.  Through very bad luck, none of the existing test  
cases nor the ones added by e76de8861 caught that, but of course it was  
soon found in the field.  
  
The previous patch also had an implicit assumption that if a constraint's  
index had a dependency on a table column, so would the constraint --- but  
that isn't actually true, so it didn't fix such cases.  
  
Instead of trying to delete unneeded index dependencies later, do the  
is-there-a-constraint lookup immediately on seeing an index dependency,  
and switch to remembering the constraint if so.  In the unusual case of  
multiple column dependencies for a constraint index, this will result in  
duplicate constraint lookups, but that's not that horrible compared to all  
the other work that happens here.  Besides, such cases did not work at all  
before, so it's hard to argue that they're performance-critical for anyone.  
  
Per bug #15865 from Keith Fiske.  As before, back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/15865-17940eacc8f8b081@postgresql.org  

commit   : b00326df7ad4ab7d21aad3b6fe6558ea6b61897d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 24 Jun 2019 10:31:58 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 24 Jun 2019 10:31:58 -0700    

Oversight in commit dd299df8.  

commit   : f31111bbe81db0e84fb486c6423a234c47091b30    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jun 2019 12:36:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 24 Jun 2019 12:36:51 -0400    

Commit d7f8d26d9 added a test case that created a user, but forgot  
to drop it again.  This is no good; for one thing, it causes repeated  
"make installcheck" runs to fail.  

commit   : 12e037e2090b1a6446376814ea0419463b02c254    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 24 Jun 2019 10:39:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 24 Jun 2019 10:39:12 +0200    

As part of REINDEX CONCURRENTLY, this formerly internal-only error  
message becomes potentially user-visible (see regression tests), so  
change from errmsg_internal() to errmsg(), and update comment.  

commit   : 9a81c9fa3f6a2f57b9db2a1ce5584c85fc1d977e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 23 Jun 2019 12:02:19 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 23 Jun 2019 12:02:19 -0700    

This code is new in v12, and the defect probably was not user-visible.  

commit   : d7f8d26d9f4c0a574250ec53a03b3dc08d13796c    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 23 Jun 2019 18:50:08 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 23 Jun 2019 18:50:08 +0100    

The multivariate MCV estimation code may run user-defined operators on  
the values in the MCV list, which means that those operators may  
potentially leak the values from the MCV list. Guard against leaking  
data to unprivileged users by checking that the user has SELECT  
privileges on the table or all of the columns referred to by the  
statistics.  
  
Additionally, if there are any securityQuals on the RTE (either due to  
RLS policies on the table, or accessing the table via a security  
barrier view), not all rows may be visible to the current user, even  
if they have table or column privileges. Thus we further insist that  
the operator be leakproof in this case.  
  
Dean Rasheed, reviewed by Tomas Vondra.  
  
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui=Vdx4N==VV5XOK5dsXfnGgVOz_JhAicB=ZA@mail.gmail.com  

commit   : 89ff7c08eee355195eba6f544d28584e61200665    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 23 Jun 2019 22:19:59 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 23 Jun 2019 22:19:59 +1200    

Author: Vik Fearing  
Discussion: https://postgr.es/m/150d3e9f-c7ec-3fb3-4fdb-def47c4144af%402ndquadrant.com  

commit   : 1323bfce55109dd54ee164828aab7983d3020a25    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Jun 2019 20:31:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Jun 2019 20:31:50 -0400    

Original MIPS-I processors didn't have the LL/SC instructions (nor any  
other userland synchronization primitive).  If the build toolchain  
targets that ISA variant by default, as an astonishingly large fraction  
of MIPS platforms still do, the assembler won't take LL/SC without  
coercion in the form of a ".set mips2" instruction.  But we issued that  
unconditionally, making it an ISA downgrade for chips later than MIPS2.  
That breaks things for the latest MIPS r6 ISA, which encodes these  
instructions differently.  Adjust the code so we don't change ISA level  
if it's >= 2.  
  
Note that this patch doesn't change what happens on an actual MIPS-I  
processor: either the kernel will emulate these instructions  
transparently, or you'll get a SIGILL failure.  That tradeoff seemed  
fine in 2002 when this code was added (cf 3cbe6b247), and it's even  
more so today when MIPS-I is basically extinct.  But let's add a  
comment about that.  
  
YunQiang Su (with cosmetic adjustments by me).  Back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/15844-8f62fe7e163939b3@postgresql.org  

commit   : 660a2b19038b2f6b9f6bcb2c3297a47d5e3557a8    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 21 Jun 2019 20:34:23 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 21 Jun 2019 20:34:23 -0700    

This fixes some TAP suites when using msys Perl and a builddir located  
in an msys mount point other than "/".  For example, builddir=/c/pg  
exhibited the problem, since /c/pg falls in mount point "/c".  
Back-patch to 9.6, where tests first started to perform such  
translations.  In back branches, offer both new and old APIs.  
  
Reviewed by Andrew Dunstan.  
  
Discussion: https://postgr.es/m/20190610045838.GA238501@rfd.leadboat.com  

commit   : 25b93a2967a4ebfb90168ca087026cc697fc4b77    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 21 Jun 2019 10:57:07 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 21 Jun 2019 10:57:07 +1200    

Commit 6753333f switched from a semaphore-based wait to a latch-based  
wait for ProcSleep()/ProcWakeup(), but left behind some stray references  
to semaphores.  
  
Back-patch to 9.5.  
  
Reviewed-by: Daniel Gustafsson, Michael Paquier  
Discussion: https://postgr.es/m/CA+hUKGLs5H6zhmgTijZ1OaJvC1sG0=AFXc1aHuce32tKiQrdEA@mail.gmail.com  

commit   : 20e1cc898da6f82b5680973c107e8a96d46caf01    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Jun 2019 13:28:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Jun 2019 13:28:12 +0900    

This makes the whole user experience more consistent when bumping into  
failures, and more in line with the rewording done via 508300e.  
  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/20190514153252.GA22168@alvherre.pgsql  

commit   : 252f9a2580b013fe45ba28bb6d7a4994abc93bb5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Jun 2019 13:04:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 20 Jun 2019 13:04:56 +0900    

Author: Ian Barwick  
Discussion: https://postgr.es/m/087a6961-1aaf-e36c-b712-bd5a644da20a@2ndquadrant.com  

commit   : cd917ffb9a43e9e4699c2a89d495ee02a8701034    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:49:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:49:03 +0200    

Make wording more accurate and add strerror() information.  
  
Discussion: https://www.postgresql.org/message-id/24c8bd05-aed1-6301-919d-8acbabdb8c24@2ndquadrant.com  

commit   : aba78ab4a9509e7ed92acefd707a99425568f49f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:43:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:43:31 +0200    

Currently, calling pg_upgrade with an invalid command-line option  
aborts pg_upgrade but leaves a pg_upgrade_internal.log file lying  
around.  Reorder things a bit so that that file is not created until  
all the options have been parsed.  
  
Discussion: https://www.postgresql.org/message-id/24c8bd05-aed1-6301-919d-8acbabdb8c24@2ndquadrant.com  

commit   : dfd79e2d0e8f399785ca2f7c659b45fd620cba17    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 19 Jun 2019 22:41:12 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 19 Jun 2019 22:41:12 +0300    

The description is ended part way and PASSING clause is not implemented yet.  
But the variables might be passed as parameters to several jsonpath functions.  
So, complete the description based on the current implementation, leaving  
description of PASSING clause in TODO.  
  
Discussion: https://postgr.es/m/CAKPRHz%2BxOuQSSvkuB1mCQjedd%2BB2B1Vnkrq0E-pLmoXyTO%2Bz9Q%40mail.gmail.com  
Author: Kyotaro Horiguchi, Alexander Korotkov  

commit   : 1ff8dc9f19ddf00e3ad69d7141f78341769cd8a3    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 19 Jun 2019 22:41:05 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 19 Jun 2019 22:41:05 +0300    

Reference posix regex documentation section and list supported flags.  
  
Discussion: https://postgr.es/m/CAKPRHz%2BxOuQSSvkuB1mCQjedd%2BB2B1Vnkrq0E-pLmoXyTO%2Bz9Q%40mail.gmail.com  
Author: Kyotaro Horiguchi, Alexander Korotkov  

commit   : 261a5c1928566f938cbda0f62dc16f6a2d1e871d    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 19 Jun 2019 22:40:58 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 19 Jun 2019 22:40:58 +0300    

SQL/JSON standard defines that jsonpath 'like_regex' predicate should support  
the same set of flags as XQuery/XPath.  It appears that implementation of 'q'  
flag was missed.  This commit fixes that.  
  
Discussion: https://postgr.es/m/CAPpHfdtyfPsxLYiTjp5Ov8T5xGsB5t3CwE5%2B3PS%3DLLwA%2BxTJog%40mail.gmail.com  
Author: Nikita Glukhov, Alexander Korotkov  

commit   : d8594d123c155aeecd47fc2450f62f5100b2fbf0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:35:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:35:41 +0200    

The list of combining characters to ignore for calculating the display  
width of a string (used for example by psql) was wildly outdated and  
incorrect.  
  
Discussion: https://www.postgresql.org/message-id/flat/bbb19114-af1e-513b-08a9-61272794bd5c%402ndquadrant.com  

commit   : ac5bb8f275dd9b2746fe6d433f1c08c1c3bd3d61    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:26:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 19 Jun 2019 21:26:42 +0200    

The SVG output produced by external tools needs some postprocessing.  
This is implemented by this new XSL stylesheet.  
  
Issues are:  
  
- SVG produced by Ditaa does not add a viewBox attribute to the svg  
  element, needed to make the image scalable.  
  
- SVG produced by Graphviz uses a stroke="transparent" attribute,  
  which is not valid SVG.  It appears to mostly work, but FOP  
  complains.  
  
Other tweaks can be added over time.  
  
This reverts 7dc78d8ef3e62f7e06d7767c63dcede048377b9a and  
29046c44f36099f4c979b1491fcf27db2f9184f9, which applied these fixes  
manually.  

commit   : 66013fe73095f851c151a17ccc7553abe6246891    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 19 Jun 2019 14:59:26 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 19 Jun 2019 14:59:26 +0200    

Author: Daniel Gustafsson  

commit   : 992fe54e77f66ed67b6480fcf7dd208b2cd28aac    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 19 Jun 2019 14:38:23 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 19 Jun 2019 14:38:23 +0200    

Commit a1ef920e27ba6ab3602aaf6d6751d8628fac1af8 replaced the use of  
slave with standby, but overlooked this comment.  
  
Author: Daniel Gustafsson  

commit   : 414cca40d506dd3f17b49ae3139853139192c2ba    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Jun 2019 11:18:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Jun 2019 11:18:50 +0900    

fc49e24 has removed the last use of this compile-time variable as WAL  
segment size is something that can now be set at initdb time, still this  
commit has forgotten some references to it.  
  
Discussion: https://postgr.es/m/20190617073228.GE18917@paquier.xyz  

commit   : 3c28fd2281223580b88473e5145b752cc7cbadf9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Jun 2019 11:02:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 19 Jun 2019 11:02:19 +0900    

This record uses one metadata buffer and registers some data associated  
to the buffer, but when parsing the record for its description a direct  
access to the record data was done, but there is none.  This leads  
usually to an incorrect description, but can also cause crashes like in  
pg_waldump.  Instead, fix things so as the parsing uses the data  
associated to the metadata block.  
  
This is an oversight from 3d92796, so backpatch down to 11.  
  
Author: Michael Paquier  
Description: https://postgr.es/m/20190617013059.GA3153@paquier.xyz  
Backpatch-through: 11  

commit   : 23224563d97913aa824d04c498d59ad4d85fda38    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 18 Jun 2019 15:51:04 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 18 Jun 2019 15:51:04 -0700    

This fixes an embarrassing oversight I (Andres) made in 737a292b,  
namely missing two place where liverows/deadrows were used when  
converting those variables to pointers, leading to incrementing the  
pointer, rather than the value.  
  
It's not that actually that easy to trigger a crash: One needs tuples  
deleted by the current transaction, followed by a tuple deleted in  
another session, all in one page. Which is presumably why this hasn't  
been noticed before.  
  
Reported-By: Steve Singer  
Author: Steve Singer  
Discussion: https://postgr.es/m/c7988239-d42c-ddc4-41db-171b23b35e4f@ssinger.info  

commit   : 8b21b416ed621501db3be38817c298c57470524f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 18 Jun 2019 18:23:16 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 18 Jun 2019 18:23:16 -0400    

This puts back reverted commit de87a084c0a5, with some bug fixes.  
  
When two (or more) transactions are waiting for transaction T1 to release a  
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a  
spurious deadlock can be reported among the waiting transactions when T1  
finishes.  The simplest example case seems to be:  
  
T1: select id from job where name = 'a' for key share;  
Y: select id from job where name = 'a' for update; -- starts waiting for T1  
Z: select id from job where name = 'a' for key share;  
T1: update job set name = 'b' where id = 1;  
Z: update job set name = 'c' where id = 1; -- starts waiting for T1  
T1: rollback;  
  
At this point, transaction Y is rolled back on account of a deadlock: Y  
holds the heavyweight tuple lock and is waiting for the Xmax to be released,  
while Z holds part of the multixact and tries to acquire the heavyweight  
lock (per protocol) and goes to sleep; once T1 releases its part of the  
multixact, Z is awakened only to be put back to sleep on the heavyweight  
lock that Y is holding while sleeping.  Kaboom.  
  
This can be avoided by having Z skip the heavyweight lock acquisition.  As  
far as I can see, the biggest downside is that if there are multiple Z  
transactions, the order in which they resume after T1 finishes is not  
guaranteed.  
  
Backpatch to 9.6.  The patch applies cleanly on 9.5, but the new tests don't  
work there (because isolationtester is not smart enough), so I'm not going  
to risk it.  
  
Author: Oleksii Kliukin  
Discussion: https://postgr.es/m/B9C9D7CD-EB94-4635-91B6-E558ACEC0EC3@hintbits.com  
Discussion: https://postgr.es/m/2815.1560521451@sss.pgh.pa.us  

commit   : aca127c105aae551620d607e88d76930e6b9a2cf    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 18 Jun 2019 22:38:30 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 18 Jun 2019 22:38:30 +1200    

WHERE EXISTS (...) queries cannot be executed by Parallel Hash Join  
with jointype JOIN_UNIQUE_INNER, because there is no way to make a  
partial plan totally unique.  The consequence of allowing such plans  
was duplicate results from some EXISTS queries.  
  
Back-patch to 11.  Bug #15857.  
  
Author: Thomas Munro  
Reviewed-by: Tom Lane  
Reported-by: Vladimir Kriukov  
Discussion: https://postgr.es/m/15857-d1ba2a64bce0795e%40postgresql.org  

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

commit   : 91acff7a538e6e6a8175450a38c7fa1d9a290011    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 Jun 2019 15:07:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 17 Jun 2019 15:07:14 +0200    

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

commit   : b67421178880f9df337dc19b8601b54b99efbc78    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Jun 2019 22:13:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Jun 2019 22:13:57 +0900    

When a client connects to a rogue server sending specifically-crafted  
messages, this can suffice to execute arbitrary code as the operating  
system account used by the client.  
  
While on it, fix one error handling when decoding an incorrect salt  
included in the first message received from server.  
  
Author: Michael Paquier  
Reviewed-by: Jonathan Katz, Heikki Linnakangas  
Security: CVE-2019-10164  
Backpatch-through: 10  

commit   : 09ec55b933091cb5b0af99978718cb3d289c71b6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Jun 2019 21:48:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Jun 2019 21:48:17 +0900    

Any authenticated user can overflow a stack-based buffer by changing the  
user's own password to a purpose-crafted value.  This often suffices to  
execute arbitrary code as the PostgreSQL operating system account.  
  
This fix is contributed by multiple folks, based on an initial analysis  
from Tom Lane.  This issue has been introduced by 68e61ee, so it was  
possible to make use of it at authentication time.  It became more  
easily to trigger after ccae190 which has made the SCRAM parsing more  
strict when changing a password, in the case where the client passes  
down a verifier already hashed using SCRAM.  Back-patch to v10 where  
SCRAM has been introduced.  
  
Reported-by: Alexander Lakhin  
Author: Jonathan Katz, Heikki Linnakangas, Michael Paquier  
Security: CVE-2019-10164  
Backpatch-through: 10  

commit   : 3412030205211079f9b0510e2244083e4ee7b15a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Jun 2019 16:13:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 17 Jun 2019 16:13:16 +0900    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/0a5419ea-1452-a4e6-72ff-545b1a5a8076@gmail.com  

commit   : 9d20b0ec8f2af43041b1a65e5fcd91acc47e9ace    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 16 Jun 2019 22:24:21 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 16 Jun 2019 22:24:21 -0400    

This reverts commits 3da73d6839dc and de87a084c0a5.  
  
This code has some tricky corner cases that I'm not sure are correct and  
not properly tested anyway, so I'm reverting the whole thing for next  
week's releases (reintroducing the deadlock bug that we set to fix).  
I'll try again afterwards.  
  
Discussion: https://postgr.es/m/E1hbXKQ-0003g1-0C@gemulon.postgresql.org  

commit   : 16c4e76f1b0a0145572551b7e919b967e406a0b1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Jun 2019 14:02:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Jun 2019 14:02:22 -0400    

Now that we've back-patched that, it shouldn't be mentioned in v12  
anymore.  

commit   : 6973b058bc8d32e104bed99c134a4fab4b5dfe13    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Jun 2019 11:00:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Jun 2019 11:00:23 -0400    

We don't need to restrict column privileges on pg_statistic_ext;  
all of that data is OK to read publicly.  What we *do* need to do,  
which was overlooked by 6cbfb784c, is revoke public read access on  
pg_statistic_ext_data; otherwise we still have the same security  
hole we started with.  
  
Catversion bump to ensure that installations calling themselves  
beta2 will have this fix.  
  
Diagnosis/correction by Dean Rasheed and Tomas Vondra, but I'm  
going to go ahead and push this fix ASAP so we get more buildfarm  
cycles on it.  
  
Discussion: https://postgr.es/m/8833.1560647898@sss.pgh.pa.us  

commit   : fc8cf3df478e054b892f6698b6d336e72f3a7328    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 16 Jun 2019 12:04:40 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 16 Jun 2019 12:04:40 +0200    

The GRANT in system_views allowed SELECT privileges on various columns in  
the pg_statistic_ext catalog, but tableoid was not included in the list.  
That made pg_dump fail because it's accessing this column when building  
the list of extended statistics to dump.  
  
Discussion: https://postgr.es/m/8833.1560647898%40sss.pgh.pa.us  

commit   : 7f44efa10b6ea3e5fd125e2800f357f38ab1068c    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 15 Jun 2019 21:38:53 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 15 Jun 2019 21:38:53 +0200    

The example was incorrectly using parantheses around the list of columns, so  
just drop them.  
  
Reported-By: Robert Haas  
Discussion: https://postgr.es/m/CA%2BTgmoZZEMAqWMAfvLHZnK57SoxOutgvE-ALO94WsRA7zZ7wyQ%40mail.gmail.com  

commit   : aa087ec64f703a52f3c48c70117bb02e578f1802    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 13 Jun 2019 17:25:04 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 13 Jun 2019 17:25:04 +0200    

Regular per-column statistics are stored in pg_statistics catalog, which  
is however rather difficult to read, so we also have pg_stats view with  
a human-reablable version of the data.  
  
For extended statistic the catalog was fairly easy to read, so we did  
not have such human-readable view so far.  Commit 9b6babfa2d however did  
split the catalog into two, which makes querying harder.  Furthermore,  
we want to show the multi-column MCV list in a way similar to per-column  
stats (and not as a bytea value).  
  
This commit introduces pg_stats_ext view, joining the two catalogs and  
massaging the data to produce human-readable output similar to pg_stats.  
It also considers RLS and access privileges - the data is shown only when  
the user has access to all columns the extended statistic is defined on.  
  
Bumped CATVERSION due to adding new system view.  
  
Author: Dean Rasheed, with improvements by me  
Reviewed-by: Dean Rasheed, John Naylor  
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com  

commit   : 6cbfb784c3c91146148a76d50cda6f69ae6a79fb    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 13 Jun 2019 17:19:21 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 13 Jun 2019 17:19:21 +0200    

Since extended statistic got introduced in PostgreSQL 10, there was a  
single catalog pg_statistic_ext storing both the definitions and built  
statistic.  That's however problematic when a user is supposed to have  
access only to the definitions, but not to user data.  
  
Consider for example pg_dump on a database with RLS enabled - if the  
pg_statistic_ext catalog respects RLS (which it should, if it contains  
user data), pg_dump would not see any records and the result would not  
define any extended statistics.  That would be a surprising behavior.  
  
Until now this was not a pressing issue, because the existing types of  
extended statistic (functional dependencies and ndistinct coefficients)  
do not include any user data directly.  This changed with introduction  
of MCV lists, which do include most common combinations of values.  
  
The easiest way to fix this is to split the pg_statistic_ext catalog  
into two - one for definitions, one for the built statistic values.  
The new catalog is called pg_statistic_ext_data, and we're maintaining  
a 1:1 relationship with the old catalog - either there are matching  
records in both catalogs, or neither of them.  
  
Bumped CATVERSION due to changing system catalog definitions.  
  
Author: Dean Rasheed, with improvements by me  
Reviewed-by: Dean Rasheed, John Naylor  
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com  

commit   : e3846a00c2f87402dcedf7f07950ab2d89cf5827    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sat, 15 Jun 2019 18:15:23 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sat, 15 Jun 2019 18:15:23 +0100    

tzdb 2019a made "UCT" a link to the "UTC" zone rather than a separate  
zone with its own abbreviation. Unfortunately, our code for choosing a  
timezone in initdb has an arbitrary preference for names earlier in  
the alphabet, and so it would choose the spelling "UCT" over "UTC"  
when the system is running on a UTC zone.  
  
Commit 23bd3cec6 was backpatched in order to address this issue, but  
that code helps only when /etc/localtime exists as a symlink, and does  
nothing to help on systems where /etc/localtime is a copy of a zone  
file (as is the standard setup on FreeBSD and probably some other  
platforms too) or when /etc/localtime is simply absent (giving UTC as  
the default).  
  
Accordingly, add a preference for the spelling "UTC", such that if  
multiple zone names have equally good content matches, we prefer that  
name before applying the existing arbitrary rules. Also add a slightly  
lower preference for "Etc/UTC"; lower because that preserves the  
previous behaviour of choosing the shorter name, but letting us still  
choose "Etc/UTC" over "Etc/UCT" when both exist but "UTC" does  
not (not common, but I've seen it happen).  
  
Backpatch all the way, because the tzdb change that sparked this issue  
is in those branches too.  

commit   : a193cbec1199e4e529c46645b7aecbf38956048b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Jun 2019 18:21:52 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Jun 2019 18:21:52 -0400    

Commit 7e413a0f82c8 added that option to pg_dump, but neglected to teach  
pg_dumpall how to pass it along.  Repair.  
  
Author: Fabien Coelho  
Reported-by: Peter Eisentraut  
Reviewed-by: David Rowley  
Discussion: https://postgr.es/m/45f50c59-ddbb-8cf2-eedb-81003f603528@2ndquadrant.com  

commit   : 313f56ce2d1b9dfd3483e4f39611baa27852835a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Jun 2019 18:02:26 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Jun 2019 18:02:26 -0400    

Fixes some problems introduced by 6e5f8d489acc:  
  
* When reusing conninfo data from the previous connection in \connect,  
  the host address should only be reused if it was specified as  
  hostaddr; if it wasn't, then 'host' is resolved afresh.  We were  
  reusing the same IP address, which ignores a possible DNS change  
  as well as any other addresses that the name resolves to than the  
  one that was used in the original connection.  
  
* PQhost, PQhostaddr: Don't present user-specified hostaddr when we have  
  an inet_net_ntop-produced equivalent address.  The latter has been  
  put in canonical format, which is cleaner (so it produces "127.0.0.1"  
  when given "host=2130706433", for example).  
  
* Document the hostaddr-reusing aspect of \connect.  
  
* Fix some code comments  
  
Author: Fabien Coelho  
Reported-by: Noah Misch  
Discussion: https://postgr.es/m/20190527203713.GA58392@gust.leadboat.com  

commit   : 3da73d6839dc47f1f47ca57974bf28e5abd9b572    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Jun 2019 11:33:40 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Jun 2019 11:33:40 -0400    

Introduced in de87a084c0a5.  

commit   : b9a0724cf7a3ecf19aaaa098ffd26e52bb800c5c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 14 Jun 2019 09:30:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 14 Jun 2019 09:30:31 -0400    

Add mention of single-child optimization for partitions and UNION ALL.  
  
Reported-by: David Rowley  
  
Discussion: https://postgr.es/m/CAKJS1f8R8riwBXw==7ijV=UZNuhP+3qXgDBKSiM+=_cTf4mXXw@mail.gmail.com  

commit   : 08d2d58a2a1c8ef8d39e8132d39ee14a1d029500    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 14 Jun 2019 20:49:59 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 14 Jun 2019 20:49:59 +0900    

Commit aa09cd242 modified estimate_path_cost_size() so that it reuses  
cached costs of a basic foreign path for a given foreign-base/join  
relation when costing pre-sorted foreign paths for that relation, but it  
incorrectly re-computed retrieved_rows, an estimated number of rows  
fetched from the remote side, which is needed for costing both the basic  
and pre-sorted foreign paths.  To fix, handle retrieved_rows the same way  
as the cached costs: store in that relation's fpinfo the retrieved_rows  
estimate computed for costing the basic foreign path, and reuse it when  
costing the pre-sorted foreign paths.  Also, reuse the rows/width  
estimates stored in that relation's fpinfo when costing the pre-sorted  
foreign paths, to make the code consistent.  
  
In commit ffab494a4, to extend the costing mentioned above to the  
foreign-grouping case, I made a change to add_foreign_grouping_paths() to  
store in a given foreign-grouped relation's RelOptInfo the rows estimate  
for that relation for reuse, but this patch makes that change unnecessary  
since we already store the row estimate in that relation's fpinfo, which  
this patch reuses when costing a foreign path for that relation with the  
sortClause ordering; remove that change.  
  
In passing, fix thinko in commit 7012b132d: in estimate_path_cost_size(),  
the width estimate for a given foreign-grouped relation to be stored in  
that relation's fpinfo was reset incorrectly when costing a basic foreign  
path for that relation with local stats.  
  
Apply the patch to HEAD only to avoid destabilizing existing plan choices.  
  
Author: Etsuro Fujita  
Discussion: https://postgr.es/m/CAPmGK17jaJLPDEkgnP2VmkOg=5wT8YQ1CqssU8JRpZ_NSE+dqQ@mail.gmail.com  

commit   : be2e024bd6527b050da4ad02c921869fed84bb5d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 Jun 2019 22:53:20 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 Jun 2019 22:53:20 -0400    

Reported-by: Robert Haas  
  
Discussion: https://postgr.es/m/CA+TgmoY==TZwk-4cM3Usebq1f=j7Hpm1brFbk1v48h45wsWzzg@mail.gmail.com  

commit   : 18ef7a34fe616dc63f7de672a5ab7dd88137dc5c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 Jun 2019 22:07:25 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 Jun 2019 22:07:25 -0400    

It was previously incorrectly placed in the server application section.  
  
Reported-by: Tatsuo Ishii  
  
Discussion: https://postgr.es/m/20190526.215341.1023150119477784132.t-ishii@sraoss.co.jp  

commit   : f43608bda2111a1fda514d1bed4df313ee2bbec3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 14 Jun 2019 09:34:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 14 Jun 2019 09:34:34 +0900    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/dec6aae8-2d63-639f-4d50-20e229fb83e3@gmail.com  

commit   : 96719e52b1abd3a8c712d06a809b7e6c97c2e3a0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 14 Jun 2019 09:00:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 14 Jun 2019 09:00:36 +0900    

In order to separate OpenSSL's SHA symbols, this header has been using  
USE_SSL, which is equivalent to USE_OPENSSL.  There is now only one SSL  
implementation included in the tree, so this works fine, but when  
adding a new SSL implementation this would run into failures.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/0DF29010-CE26-4F51-85A6-9C8ABF5536F9@yesql.se  

commit   : d25ea0127598dd0ad27a029215172f396fbd1009    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Jun 2019 18:10:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Jun 2019 18:10:08 -0400    

If an EquivalenceClass member expression includes variables from  
multiple appendrels, then instead of producing one substituted  
expression per child relation as intended, we'd create additional  
child expressions for combinations of children of different appendrels.  
This happened because the child expressions generated while considering  
the first appendrel were taken as sources during substitution of the  
second appendrel, and so on.  The extra expressions are useless, and are  
harmless unless there are too many of them --- but if you have several  
appendrels with a thousand or so members each, it gets bad fast.  
  
To fix, consider only original (non-em_is_child) EC members as candidates  
to be expanded.  This requires the ability to substitute directly from a  
top parent relation's Vars to those of an indirect descendant relation,  
but we already have that in adjust_appendrel_attrs_multilevel().  
  
Per bug #15847 from Feike Steenbergen.  This is a longstanding misbehavior,  
but it's only worth worrying about when there are more appendrel children  
than we've historically considered wise to use.  So I'm not going to take  
the risk of back-patching this.  
  
Discussion: https://postgr.es/m/15847-ea3734094bf8ae61@postgresql.org  

commit   : de87a084c0a5ac927017cd0834b33a932651cfc9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Jun 2019 17:28:24 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Jun 2019 17:28:24 -0400    

When two (or more) transactions are waiting for transaction T1 to release a  
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a  
spurious deadlock can be reported among the waiting transactions when T1  
finishes.  The simplest example case seems to be:  
  
T1: select id from job where name = 'a' for key share;  
Y: select id from job where name = 'a' for update; -- starts waiting for X  
Z: select id from job where name = 'a' for key share;  
T1: update job set name = 'b' where id = 1;  
Z: update job set name = 'c' where id = 1; -- starts waiting for X  
T1: rollback;  
  
At this point, transaction Y is rolled back on account of a deadlock: Y  
holds the heavyweight tuple lock and is waiting for the Xmax to be released,  
while Z holds part of the multixact and tries to acquire the heavyweight  
lock (per protocol) and goes to sleep; once X releases its part of the  
multixact, Z is awakened only to be put back to sleep on the heavyweight  
lock that Y is holding while sleeping.  Kaboom.  
  
This can be avoided by having Z skip the heavyweight lock acquisition.  As  
far as I can see, the biggest downside is that if there are multiple Z  
transactions, the order in which they resume after X finishes is not  
guaranteed.  
  
Backpatch to 9.6.  The patch applies cleanly on 9.5, but the new tests don't  
work there (because isolationtester is not smart enough), so I'm not going  
to risk it.  
  
Author: Oleksii Kliukin  
Discussion: https://postgr.es/m/B9C9D7CD-EB94-4635-91B6-E558ACEC0EC3@hintbits.com  

commit   : 3c8f8f6ebefb3c2debd1cad1ba445a729290dac7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Jun 2019 10:53:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Jun 2019 10:53:17 -0400    

Also MyReplicationSlot, in branches where it wasn't already.  
  
This was discussed in the thread that resulted in c572599c6, but  
for some reason nobody pulled the trigger.  Now that we have another  
request for the same thing, we should just do it.  
  
Craig Ringer  
  
Discussion: https://postgr.es/m/CAMsr+YFTsq-86MnsNng=mPvjjh5EAbzfMK0ptJPvzyvpFARuRg@mail.gmail.com  
Discussion: https://postgr.es/m/345138875.20190611151943@cybertec.at  

commit   : b9768458154de6c001af23efc02514f120c6094f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 Jun 2019 14:16:18 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 Jun 2019 14:16:18 -0400    

Discussion: https://postgr.es/m/20190612184527.GA24266@alvherre.pgsql  
Reviewed-by: Michaël Paquier  

commit   : 4f41a7227511a3f96148b7f3d4ae6f0c350bc7b2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 Jun 2019 09:15:57 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 13 Jun 2019 09:15:57 -0400    

This item prevents unauthorized locking of relations, and the previous  
wording was unclear.  
  
Reported-by: Michael Paquier  
  
Discussion: https://postgr.es/m/20190522072651.GC1278@paquier.xyz  

commit   : 8b6da83d162cb0ac9f6d21082727bbd45c972c53    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 13 Jun 2019 17:59:09 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 13 Jun 2019 17:59:09 +0900    

Previously, in postgresPlanForeignModify, we planned an UPDATE operation  
on a foreign table so that we transmit only columns that were explicitly  
targets of the UPDATE, so as to avoid unnecessary data transmission, but  
if there were BEFORE ROW UPDATE triggers on the foreign table, those  
triggers might change values for non-target columns, in which case we  
would miss sending changed values for those columns.  Prevent optimizing  
away transmitting all columns if there are BEFORE ROW UPDATE triggers on  
the foreign table.  
  
This is an oversight in commit 7cbe57c34 which added triggers on foreign  
tables, so apply the patch all the way back to 9.4 where that came in.  
  
Author: Shohei Mochizuki  
Reviewed-by: Amit Langote  
Discussion: https://postgr.es/m/201905270152.x4R1q3qi014550@toshiba.co.jp  

commit   : 7dc6ae37def50b5344c157eee5e029a09359f8ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 23:05:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 23:05:40 -0400    

This wasn't incorrect SQL, but it was doing cm-to-inch conversion  
backward, so it might confuse readers.  
  
Per bug #15849 from TAKATSUKA Haruka.  
  
Discussion: https://postgr.es/m/15849-37ad0c561a836107@postgresql.org  

commit   : 9729c9360886bee7feddc6a1124b0742de4b9f3d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 22:54:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 22:54:46 -0400    

datatype.sgml failed to explain that boolin() accepts any unique  
prefix of the basic input strings.  Indeed it was actively misleading  
because it called out a few minimal prefixes without mentioning that  
there were more valid inputs.  
  
I also felt that it wasn't doing anybody any favors by conflating  
SQL key words, valid Boolean input, and string literals containing  
valid Boolean input.  Rewrite in hopes of reducing the confusion.  
  
Per bug #15836 from Yuming Wang, as diagnosed by David Johnston.  
Back-patch to supported branches.  
  
Discussion: https://postgr.es/m/15836-656fab055735f511@postgresql.org  

commit   : 4bfb79ff6b1fd400b3dbc761921472173675a968    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 Jun 2019 22:48:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 Jun 2019 22:48:04 -0400    

Reported-by: Peter Geoghegan  
  
Discussion: https://postgr.es/m/CAH2-Wzn-aH4ToZEWR05ELSSp7bO_JMn=sMPfUhNruwVmCXKh-w@mail.gmail.com  

commit   : 3d99a81397abb8bb7b95aee794d6644e174e174f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 19:42:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 19:42:38 -0400    

Given a query in which multiple JOIN nodes used the same alias  
(which'd necessarily be in different sub-SELECTs), ruleutils.c  
would assign the JOIN nodes distinct aliases for clarity ...  
but then it forgot to print the modified aliases when dumping  
the JOIN nodes themselves.  This results in a dump/reload hazard  
for views, because the emitted query is flat-out incorrect:  
Vars will be printed with table names that have no referent.  
  
This has been wrong for a long time, so back-patch to all supported  
branches.  
  
Philip Dubé  
  
Discussion: https://postgr.es/m/CY4PR2101MB080246F2955FF58A6ED1FEAC98140@CY4PR2101MB0802.namprd21.prod.outlook.com  

commit   : ddc053dc503a773267a4d035418e0c81ce3b4851    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 13 Jun 2019 10:35:11 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 13 Jun 2019 10:35:11 +1200    

Reported-by: Amit Langote  
Discussion: https://postgr.es/m/CA+HiwqGZFkKi0TkBGYpr2_5qrRAbHZoP47AP1BRLUOUkfQdy_A@mail.gmail.com  
Backpatch-through: 10  

commit   : 968072837173a0c0fa426114b17177f997b85473    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 Jun 2019 17:46:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 Jun 2019 17:46:38 -0400    

Reported-by: Adrien Nayrat  
  
Discussion: https://postgr.es/m/9d6a7515-bcd8-05be-d2a5-e81dc11023cd@anayrat.info  

commit   : 6a631a454664c145b7da88c9ef3976f8ac3ab0b1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 Jun 2019 17:36:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 Jun 2019 17:36:43 -0400    

Reported-by: Andres Freund  
  
Discussion: https://postgr.es/m/20190528155823.3e4cezblxjxotq2q@alap3.anarazel.de  

commit   : e76de886157b7f974d4d247908b242607cfbf043    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 12:29:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jun 2019 12:29:24 -0400    

ATExecAlterColumnType failed to consider the possibility that an index  
that needs to be rebuilt might be a child of a constraint that needs to be  
rebuilt.  We missed this so far because usually a constraint index doesn't  
have a direct dependency on its table, just on the constraint object.  
But if there's a WHERE clause, then dependency analysis of the WHERE  
clause results in direct dependencies on the column(s) mentioned in WHERE.  
This led to trying to drop and rebuild both the constraint and its  
underlying index.  
  
In v11/HEAD, we successfully drop both the index and the constraint,  
and then try to rebuild both, and of course the second rebuild hits a  
duplicate-index-name problem.  Before v11, it fails with obscure messages  
about a missing relation OID, due to trying to drop the index twice.  
  
This is essentially the same kind of problem noted in commit  
20bef2c31: the possible dependency linkages are broader than what  
ATExecAlterColumnType was designed for.  It was probably OK when  
written, but it's certainly been broken since the introduction of  
partial exclusion constraints.  Fix by adding an explicit check  
for whether any of the indexes-to-be-rebuilt belong to any of the  
constraints-to-be-rebuilt, and ignoring any that do.  
  
In passing, fix a latent bug introduced by commit 8b08f7d48: in  
get_constraint_index() we must "continue" not "break" when rejecting  
a relation of a wrong relkind.  This is harmless today because we don't  
expect that code path to be taken anyway; but if there ever were any  
relations to be ignored, the existing coding would have an extremely  
undesirable dependency on the order of pg_depend entries.  
  
Also adjust a couple of obsolete comments.  
  
Per bug #15835 from Yaroslav Schekin.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/15835-32d9b7a76c06a7a9@postgresql.org  

commit   : ceac4505d3428a8414b4f3d6708ea81506811a5f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 12 Jun 2019 11:30:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 12 Jun 2019 11:30:11 +0900    

For a non-superuser, changing a comment on a domain constraint was  
leading to a cache lookup failure as the code tried to perform the  
ownership lookup on the constraint OID itself, thinking that it was a  
type, but this check needs to happen on the type the domain constraint  
relies on.  As the type a domain constraint relies on can be guessed  
directly based on the constraint OID, first fetch its type OID and  
perform the ownership on it.  
  
This is broken since 7eca575, which has split the handling of comments  
for table constraints and domain constraints, so back-patch down to  
9.5.  
  
Reported-by: Clemens Ladisch  
Author: Daniel Gustafsson, Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/15833-808e11904835d26f@postgresql.org  
Backpatch-through: 9.5  

commit   : e788e849addd56007a0e75f3b5514f294a0f3bca    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 12 Jun 2019 08:08:57 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 12 Jun 2019 08:08:57 +1200    

A few questionable partitioning designs have been cropping up lately  
around the mailing lists.  Generally, these cases have been partitioning  
using too many partitions which have caused performance or OOM problems for  
the users.  
  
Since we have very little else to guide users into good design, here we  
add a new section to the partitioning documentation with some best  
practise guidelines for good design.  
  
Reviewed-by: Justin Pryzby, Amit Langote, Alvaro Herrera  
Discussion: https://postgr.es/m/CAKJS1f-2rx+E9mG3xrCVHupefMjAp1+tpczQa9SEOZWyU7fjEA@mail.gmail.com  
Backpatch-through: 10  

commit   : 6f34fcbbd5ad5a6546710e7b90e6331cacfd36dc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Jun 2019 13:33:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Jun 2019 13:33:08 -0400    

json_to_record(), when an output column is declared as type json or jsonb,  
should emit the corresponding field of the input JSON object.  But it got  
this slightly wrong when the field is just a string literal: it failed to  
escape the contents of the string.  That typically resulted in syntax  
errors if the string contained any double quotes or backslashes.  
  
jsonb_to_record() handles such cases correctly, but I added corresponding  
test cases for it too, to prevent future backsliding.  
  
Improve the documentation, as it provided only a very hand-wavy  
description of the conversion rules used by these functions.  
  
Per bug report from Robert Vollmert.  Back-patch to v10 where the  
error was introduced (by commit cf35346e8).  
  
Note that PG 9.4 - 9.6 also get this case wrong, but differently so:  
they feed the de-escaped contents of the string literal to json[b]_in.  
That behavior is less obviously wrong, so possibly it's being depended on  
in the field, so I won't risk trying to make the older branches behave  
like the newer ones.  
  
Discussion: https://postgr.es/m/D6921B37-BD8E-4664-8D5F-DB3525765DCD@vllmrt.net  

commit   : 9f05c44ba4a4a6a857b957734bb369a2bb4dd62b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 11 Jun 2019 12:22:11 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 11 Jun 2019 12:22:11 -0400    

The docs have always been slightly inaccurate, but got particularly so  
in a874fe7b4c89, which made DISCARD ALL occur before everything else;  
reorder.  
  
Author: Jan Chochol  
Discussion: https://postgr.es/m/CAEASf_3TzBbnXm64HpnD5zCZEh8An9jN8ubMR=De-vOXHMHGeA@mail.gmail.com  

commit   : fff2a7d7bd09db38e1bafc1303c29b10a9805dc0    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Jun 2019 23:20:48 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Jun 2019 23:20:48 -0700    

Vignesh found this bug in the check function for  
default_table_access_method's check hook, but that was just copied  
from older GUCs. Investigation by Michael and me then found the bug in  
further places.  
  
When not connected to a database (e.g. in a walsender connection), we  
cannot perform (most) GUC checks that need database access. Even when  
only shared tables are needed, unless they're  
nailed (c.f. RelationCacheInitializePhase2()), they cannot be accessed  
without pg_class etc. being present.  
  
Fix by extending the existing IsTransactionState() checks to also  
check for MyDatabaseOid.  
  
Reported-By: Vignesh C, Michael Paquier, Andres Freund  
Author: Vignesh C, Andres Freund  
Discussion: https://postgr.es/m/CALDaNm1KXK9gbZfY-p_peRFm_XrBh1OwQO1Kk6Gig0c0fVZ2uw%40mail.gmail.com  
Backpatch: 9.4-  

commit   : 92a88644d2b7208e98d9e913c3a574c5c2fe7b78    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 11 Jun 2019 13:39:31 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 11 Jun 2019 13:39:31 +0900    

Reorder header files in postgres_fdw.c and connection.c in alphabetical  
order.  
  
Author: Etsuro Fujita  
Reviewed-by: Alvaro Herrera  
Discussion: https://postgr.es/m/CAPmGK17ZmNb-EELqu8LmMh2t2uFdbfWNVDEfDO5-bpejHPONMQ@mail.gmail.com  

commit   : 727e45c8a457ab7378494ff33bf3b50607d303a8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 11 Jun 2019 12:58:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 11 Jun 2019 12:58:51 +0900    

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

commit   : 132a1c101a205ee52ec7d731abcb8593a6354097    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 10 Jun 2019 20:04:44 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 10 Jun 2019 20:04:44 -0400    

All of the other code thinks that the 8th parameter is the number of  
blocks, but this declaration thinks that it's the ending block number.  
Repair this inconsistency.  
  
Patch by me, reviewed by Andres Freund.  
  
Discussion: http://postgr.es/m/CA+TgmoY49ManQWnJtiwkuytXBkmyTuDFqb74Pr4Zn2Nq9TuNBQ@mail.gmail.com  

commit   : 33a53130a89447e171a8268ae0b221bb48af6468    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 10 Jun 2019 18:56:23 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 10 Jun 2019 18:56:23 -0400    

Using PARTITION OF can result in column ordering being changed from the  
database being dumped, if the partition uses a column layout different  
from the parent's.  It's not pg_dump's job to editorialize on table  
definitions, so this is not acceptable; back-patch all the way back to  
pg10, where partitioned tables where introduced.  
  
This change also ensures that partitions end up in the correct  
tablespace, if different from the parent's; this is an oversight in  
ca4103025dfe (in pg12 only).  Partitioned indexes (in pg11) don't have  
this problem, because they're already created as independent indexes and  
attached to their parents afterwards.  
  
This change also has the advantage that the partition is restorable from  
the dump (as a standalone table) even if its parent table isn't  
restored.  
  
The original commits (3b23552ad8bb in branch master) failed to cover  
subsidiary column elements correctly, such as NOT NULL constraint and  
CHECK constraints, as reported by Rushabh Lathia (initially as a failure  
to restore serial columns).  They were reverted.  This recapitulation  
commit fixes those problems.  
  
Add some pg_dump tests to verify these things more exhaustively,  
including constraints with legacy-inheritance tables, which were not  
tested originally.  In branches 10 and 11, add a local constraint to the  
pg_dump test partition that was added by commit 2d7eeb1b1492 to master.  
  
Author: Álvaro Herrera, David Rowley  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com  
Discussion: https://postgr.es/m/20190423185007.GA27954@alvherre.pgsql  
Discussion: https://postgr.es/m/CAGPqQf0iQV=PPOv2Btog9J9AwOQp6HmuVd6SbGTR_v3Zp2XT1w@mail.gmail.com  

commit   : b6987a885ba9216e1f4319441303ee115556922c    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 10 Jun 2019 20:14:19 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 10 Jun 2019 20:14:19 +0300    

Descriptions of pg_trgm GUC options have % replaced with %% like it was  
a printf-like format.  But that's not needed since they are just plain strings.  
This commit fixed that.  Backpatch to last supported version since this error  
present from the beginning.  
  
Reported-by: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoAgPKODUsu9gqUFiNqEOAqedStxJ-a0sapsJXWWAVp%3Dxg%40mail.gmail.com  
Backpatch-through: 9.4  

commit   : ba3783e0244e3502d1b08896ffc72b3a88dbdb83    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 10 Jun 2019 19:38:13 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 10 Jun 2019 19:38:13 +0300    

be8a7a68 introduced pg_trgm.strict_word_similarity_threshold GUC, but missed  
docs for that.  This commit fixes that.  
  
Discussion: https://postgr.es/m/fc907f70-448e-fda3-3aa4-209a59597af0%402ndquadrant.com  
Author: Ian Barwick  
Reviewed-by: Masahiko Sawada, Michael Paquier  
Backpatch-through: 9.6  

commit   : 852ddfbbe2121c905f2ecd750b1ec4cbfbea9f76    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 10 Jun 2019 19:28:47 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 10 Jun 2019 19:28:47 +0300    

5871b884 introduced pg_trgm.word_similarity_threshold GUC, but its documentation  
contains wrong indentation.  This commit fixes that.  Backpatch for easier  
backpatching of other documentation fixes.  
  
Discussion: https://postgr.es/m/4c735d30-ab59-fc0e-45d8-f90eb5ed3855%402ndquadrant.com  
Author: Ian Barwick  
Backpatch-through: 9.6  

commit   : ae78a9456c8986a8869ec470b40e177b5617a2f1    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 9 Jun 2019 15:50:54 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 9 Jun 2019 15:50:54 -0700    

commit   : 44982e7d09cf9b1a08fded7fb0ca9a60dae869a5    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 9 Jun 2019 14:00:36 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 9 Jun 2019 14:00:36 -0700    

One would have needed out-of-tree code to observe the defects.  Remove  
unreferenced fields instead of completing their support functions.  
Since in-tree code can't reach _readIntoClause(), no catversion bump.  

commit   : cf4263cc6c3a2310de4f1540745990e62fa2312c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 9 Jun 2019 11:33:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 9 Jun 2019 11:33:52 +0900    

This makes the header more consistent with the surroundings, with  
declarations associated to a given file grouped together.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/20190608012439.GB7228@paquier.xyz  

commit   : b880e22de4b2543f1c1db758bca4b2135525e87a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 9 Jun 2019 11:25:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 9 Jun 2019 11:25:56 +0900    

Author: Guillaume Lelarge  
Discussion: https://postgr.es/m/CAECtzeWPz4JikzUqZdMjqPTe8dAP3nZxPD-58Y-Hhvirg0fF+A@mail.gmail.com  

commit   : a806b14a1139d3443a7c2c263abb9ff8e4a65694    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Jun 2019 10:12:26 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Jun 2019 10:12:26 -0700    

Removing shared memory and semaphores in response to server start  
failure often masks the real problem, a live process associated with the  
data directory; see commit 5a907404b52753c4d6c6a7c21765aeaa42fd6a3b.  
Since 9.6, it's rarely necessary to kill subprocesses manually.  (When  
it is necessary, that commit's HINT will say as much, in all supported  
versions.)  

commit   : f2c71cb71fe186dcf8ebec967f98d1c7c4777943    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Jun 2019 10:12:26 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Jun 2019 10:12:26 -0700    

The documentation used "nonexistent" exclusively, and the source tree  
used it three times as often as "nonexistant".  

commit   : 31d250e049b4e3d51a635edaa2221c11815e40e7    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Jun 2019 10:12:26 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 8 Jun 2019 10:12:26 -0700    

commit   : 92c4abc73693690ce9ff13ede160f0dcb0a2de7b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 8 Jun 2019 08:16:38 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 8 Jun 2019 08:16:38 +0530    

There were a number of issues in the recent commits which include typos,  
code and comments mismatch, leftover function declarations.  Fix them.  
  
Reported-by: Alexander Lakhin  
Author: Alexander Lakhin, Amit Kapila and Amit Langote  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/ef0c0232-0c1d-3a35-63d4-0ebd06e31387@gmail.com  

commit   : 35b2d4bc0eb5d61a2a294ccb6b2e4abdad307604    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 8 Jun 2019 09:59:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 8 Jun 2019 09:59:02 +0900    

The file has been introduced in src/backend/libpq/ as of b0b39f72, but  
all backend-side headers of libpq are located in src/include/libpq/.  
Note that the identification path on top of the file referred to  
src/include/libpq/ from the start.  
  
Author: Michael Paquier  
Reviewed-by: Stephen Frost  
Discussion: https://postgr.es/m/20190607043415.GE1736@paquier.xyz  

commit   : 84d4de97e8d14469974eb488730a13f942aa787a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Jun 2019 20:48:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 7 Jun 2019 20:48:39 +0900    

It was not clear from the code why it is necessary.  And we need a clean  
shutdown to avoid random checksum failures caused by torn pages.  
  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoDum5MbAb7F=pa9dOD1W2tukuDMPzWT7NjZceNoWB_6Qw@mail.gmail.com  

commit   : 77b68e3a4f854d95350a3366ecfc8b3b506ebaa7    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Jun 2019 12:42:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Jun 2019 12:42:27 +0300    

It's harmless to call PQfreemem() with a NULL argument, so the only  
consequence was that if allocating 'schema' failed, but allocating 'table'  
or 'field' succeeded, we would leak a bit of memory. That's highly  
unlikely to happen, so this is just academical, but let's get it right.  
  
Per bug #15838 from Timur Birsh. Backpatch back to 9.5, where the  
PQfreemem() calls were introduced.  
  
Discussion: https://www.postgresql.org/message-id/15838-3221652c72c5e69d@postgresql.org  

commit   : a36c84c3e4a9bee6baa740848f67a5db3fa279b0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 Jun 2019 00:44:17 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 7 Jun 2019 00:44:17 -0400    

In commit 87259588d0ab I (Álvaro) tried to rationalize the determination  
of tablespace to use for partitioned tables, but failed to handle the  
default_tablespace case.  Repair and add proper tests.  
  
Author: Amit Langote, Rushabh Lathia  
Reported-by: Rushabh Lathia  
Reviewed-by: Amit Langote, Álvaro Herrera  
Discussion: https://postgr.es/m/CAGPqQf0cYjm1=rjxk_6gU0SjUS70=yFUAdCJLwWzh9bhNJnyVg@mail.gmail.com  

commit   : d8261595bc6f5189896cdce6861915ac23830e7c    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 7 Jun 2019 05:23:52 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 7 Jun 2019 05:23:52 +0530    

When this code was initially introduced in commit d1b7c1ff, the structure  
used was SharedPlanStateInstrumentation, but later when it got changed to  
Instrumentation structure in commit b287df70, we forgot to update the  
comment.  
  
Reported-by: Wu Fei  
Author: Wu Fei  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/52E6E0843B9D774C8C73D6CF64402F0562215EB2@G08CNEXMBPEKD02.g08.fujitsu.local  

commit   : e8bdea58f960eac669ebac01dc3865606dd7b453    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 6 Jun 2019 12:18:14 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 6 Jun 2019 12:18:14 -0400    

Mark one message not for translation, and prefer "cannot" over "may  
not", per commentary from Robert Haas.  
  
Discussion: https://postgr.es/m/20190430145813.GA29872@alvherre.pgsql  

commit   : 438e51987dcc21ca7ce28c6d1a4e58b0249eb690    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 6 Jun 2019 22:10:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 6 Jun 2019 22:10:52 +0900    

Oversight in commit 280e5f1.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20190606.200612.110313249.horikyota.ntt@gmail.com  

commit   : f65eced25118aab29804debc4e0b9a67f4d043ad    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 5 Jun 2019 22:55:16 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 5 Jun 2019 22:55:16 +0200    

Previously, running pg_waldump with an invalid option (pg_waldump  
--foo) would print the help output and exit successfully.  This was  
because it tried to process the option letter '?' as a normal option,  
but that letter is used by getopt() to report an invalid option.  
  
To fix, process help and version options separately, like we do  
everywhere else.  Also add a basic test suite for pg_waldump and run  
the basic option handling tests, which would have caught this.  

commit   : cd96389d713787b025c84869ba417c6f2f008a86    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 6 Jun 2019 09:46:52 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 6 Jun 2019 09:46:52 +0300    

We used the same slot to store a tuple from the index, and to store a  
tuple from the table. That's not OK. It worked with the heap, because  
heapam_getnextslot() stores a HeapTuple to the slot, and doesn't care how  
large the tts_values/nulls arrays are. But when I played with a toy table  
AM implementation that used a virtual tuple, it caused memory overruns.  
  
In the passing, tidy up comments on the ioss_PscanLen fields.  

commit   : 6c0c28383749c0ade89ac70ba6dbce9af140c0a9    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 6 Jun 2019 12:36:37 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 6 Jun 2019 12:36:37 +1200    

Document that CREATE INDEX CONCURRENTLY is not currently supported for  
indexes on partitioned tables.  
  
Discussion: https://postgr.es/m/CAKJS1f_CErd2z9L21Q8OGLD4TgH7yw1z9MAtHTSO13sXVG-yow@mail.gmail.com  
Backpatch-through: 11  

commit   : b250898c76f3a04421656f1bd8c5c520de02046d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 5 Jun 2019 22:08:50 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 5 Jun 2019 22:08:50 +0200    

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

commit   : e24a815c1c8550fcba5cc5aeb0d130db46570872    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 5 Jun 2019 21:05:41 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 5 Jun 2019 21:05:41 +1200    

When performing REINDEX TABLE CONCURRENTLY, if all of the table's indexes  
could not be reindexed, a NOTICE message claimed that the table had no  
indexes.  This was confusing, so let's change the NOTICE text to something  
less confusing.  
  
In passing, also mention in the comment before ReindexRelationConcurrently  
that materialized views are supported too and also explain what the return  
value of the function means.  
  
Author: Ashwin Agrawal  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CALfoeithHvi13p_VyR8kt9o6Pa7Z=Smi6Nfc2anHnQx5Lj8bTQ@mail.gmail.com  

commit   : 56b3b3838284f53c83556592e60688522155f57f    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 5 Jun 2019 18:28:38 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 5 Jun 2019 18:28:38 +1200    

86b85044e rewrote how COPY FROM works to allow multiple tuple buffers to  
exist to once thus allowing multi-inserts to be used in more cases with  
partitioned tables.  That commit neglected to update the estate's  
es_result_relation_info when flushing the insert buffer to the partition  
making it possible for the index tuples to be added into an index on the  
wrong partition.  
  
Fix this and also add an Assert in ExecInsertIndexTuples to help ensure  
that we never make this mistake again.  
  
Reported-by: Haruka Takatsuka  
Author: Ashutosh Sharma  
Discussion: https://postgr.es/m/15832-b1bf336a4ee246b5@postgresql.org  

commit   : f7e954ad1cf99a65b1785d999058898a6d56e014    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Jun 2019 15:01:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 5 Jun 2019 15:01:14 +0900    

When merging two attributes, we are sure that at least one remains.  
However, when deleting one element in the attribute list we may finish  
with an empty list returned as NIL by list_delete_cell(), but the code  
failed to track that, which is not project-like.  Adjust the call so as  
we check for an empty list, and make use of it in an assertion.  
  
This has been introduced by e7b3349, when adding support for CREATE  
TABLE OF.  
  
Author: Mark Dilger  
Reviewed-by: Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/CAE-h2TpPDqSWgOvfvSziOaMngMPwW+QZcmPpY8hQ_KOJ2+3hXQ@mail.gmail.com  

commit   : 5efd604ec0a3bdde98fe19d8cada69ab4ef80db3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 4 Jun 2019 16:42:40 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 4 Jun 2019 16:42:40 -0400    

Continuous operation cannot be achieved without applying this technique,  
so it needs to be properly described.  
  
Author: Álvaro Herrera  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/8756.1556302759@sss.pgh.pa.us  

commit   : ece9dc40d6d77a8607e72931510e30cfdfb78fd4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 Jun 2019 13:57:38 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 Jun 2019 13:57:38 +0200    

Verbatim environment tags should not be indented.  

commit   : c880096dc1e14b62610aa34bc98db226fa134260    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 Jun 2019 09:16:02 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 4 Jun 2019 09:16:02 +0200    

This allows determining which command is running, similar to  
pg_stat_progress_cluster.  
  
Discussion: https://www.postgresql.org/message-id/flat/f0e56b3b-74b7-6cbc-e207-a5ed6bee18dc%402ndquadrant.com  

commit   : 041a2642e51eb008351435709dcb054760a43bb9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Jun 2019 09:48:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 4 Jun 2019 09:48:25 +0900    

The defined callback definitions have been using references to heap for  
a couple of variables and comments.  This makes the whole interface more  
consistent by using "table" which is more generic.  
  
A variable storing index information was misspelled as well.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20190601190946.GB1905@paquier.xyz  

commit   : 2cd4e835701e15f5e32dd8bde488f8669ddf7ae8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Jun 2019 18:06:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Jun 2019 18:06:04 -0400    

A parallel worker process should not be making any decisions of its  
own about whether to auto-explain.  If the parent session process  
passed down flags asking for instrumentation data, do that, otherwise  
not.  Trying to enable instrumentation anyway leads to bugs like the  
"could not find key N in shm TOC" failure reported in bug #15821  
from Christian Hofstaedtler.  
  
We can implement this cheaply by piggybacking on the existing logic  
for not doing anything when we've chosen not to sample a statement.  
  
While at it, clean up some tin-eared coding related to the sampling  
feature, including an off-by-one error that meant that asking for 1.0  
sampling rate didn't actually result in sampling every statement.  
  
Although the specific case reported here only manifested in >= v11,  
I believe that related misbehaviors can be demonstrated in any version  
that has parallel query; and the off-by-one error is certainly there  
back to 9.6 where that feature was added.  So back-patch to 9.6.  
  
Discussion: https://postgr.es/m/15821-5eb422e980594075@postgresql.org  

commit   : eaf0292c3ba7acac2735f99a8988bd49a26112f5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Jun 2019 16:59:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Jun 2019 16:59:16 -0400    

It's not really supported to call systable_getnext() in a different  
memory context than systable_beginscan() was called in, and it's  
*definitely* not safe to do so and then reset that context between  
calls.  I'm not very clear on how this code survived  
CLOBBER_CACHE_ALWAYS testing ... but Alexander Lakhin found a case  
that would crash it pretty reliably.  
  
Per bug #15828.  Fix, and backpatch to v11 where this code came in.  
  
Discussion: https://postgr.es/m/15828-f6ddd7df4852f473@postgresql.org  

commit   : 05d36b68ed011d112ee287b1fedd981c73a48f85    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 Jun 2019 21:33:01 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 3 Jun 2019 21:33:01 +0200    

Reviewed-by: Oleg Bartunov <obartunov@postgrespro.ru>  

commit   : 1fb6f62a84041b668fd9e85a2f33bb3a0fd28fdc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 3 Jun 2019 13:44:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 3 Jun 2019 13:44:03 +0900    

Author: Andrea Gelmini  
Reviewed-by: Michael Paquier, Justin Pryzby  
Discussion: https://postgr.es/m/20190528181718.GA39034@glet  

commit   : 0240a00fbd4fd14f577edf8d36a032237fd0b9cb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 3 Jun 2019 11:02:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 3 Jun 2019 11:02:32 +0900    

The following issues have been spotted:  
- CREATE INDEX .. USING suggests both index and table AMs, but it should  
consider only index AMs.  
- CREATE TABLE .. USING has no completion support.  USING was not being  
included in the completion list where it should, and follow-up  
suggestions for table AMs have been missing as well.  
- CREATE ACCESS METHOD .. TYPE suggests only INDEX, with TABLE missing.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20190601191007.GC1905@paquier.xyz  

commit   : f4755a2c01486519cfce5b21ab04529ad26f5ed1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 13:45:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 13:45:01 -0400    

Teach it to scrape -I and -D switches from CPPFLAGS in Makefile.global.  
This is useful for testing on, eg, FreeBSD, where you won't get far  
without "-I/usr/local/include".  
  
Also, expand the set of blacklisted-for-unportability atomics headers,  
based on noting that arch-x86.h fails to compile on an ARM box.  The  
other ones I'd omitted seem to compile all right on architectures they  
don't belong to, but that's surely too shaky to rely on.  Let's do  
like we did for the src/include/port/ headers, and ignore all except  
the variant that's pulled in by the arch-independent header.  

commit   : 032627ee7837f0baa539df7247e003dbaded2c90    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 12:23:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 12:23:39 -0400    

Perl likes to redefine the _() macro:  
  
#ifdef CAN_PROTOTYPE  
#define	_(args) args  
#else ...  
  
There was lots not to like about the way we dealt with this before:  
  
1. Instead of taking care of the conflict centrally in plperl.h, we  
expected every one of its ever-growing number of includers to do so.  
This is duplicative and error-prone in itself, plus it means that  
plperl.h fails to meet the expectation of being compilable standalone,  
resulting in macro-redefinition warnings in cpluspluscheck.  
  
2. We left _() with its Perl definition, meaning that if someone tried  
to use it in any Perl-related extension, it would silently fail to  
provide run-time translation.  I don't see any live bugs of this ilk,  
but it's clearly a hard-to-notice bug waiting to happen.  
  
So fix that by centralizing the cleanup logic, making it match what  
we're already doing for other macro conflicts with Perl.  Since we only  
expect plperl.h to be included by extensions not core code, we should  
redefine _() as dgettext() not gettext().  

commit   : 135063e6f6ee61c7243801e9f4d702921ed53e06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 11:13:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 11:13:23 -0400    

commit   : 10a53cae9993abae159abdc6a76e46f6aac120d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 11:07:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2019 11:07:54 -0400    

Declaring a function "inline" still doesn't work with Windows compilers  
(C99? what's that?), unless the macro provided by pg_config.h is  
in-scope, which it is not in our ECPG test programs.  So the workaround  
I tried to use in commit 7640f9312 doesn't work for Windows.  Revert  
the change in printf_hack.h, and instead just blacklist that file  
in cpluspluscheck --- since it's a not-installed test file, we don't  
really need to verify its C++ cleanliness anyway.  

commit   : 4b3f1dd71b74f82dedbf37c331d0a444368c4009    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 2 Jun 2019 00:29:49 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 2 Jun 2019 00:29:49 -0400    

This test module was not getting invoked, other than at compile time,  
limiting its usefulness -- and keeping its coverage at 0%.  Add a  
minimal regression test to ensure it runs on make check-world; this  
makes it 92% covered (line-wise), which seems sufficient.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20190529193256.GA17603@alvherre.pgsql  

commit   : 0b8e0532c65c3a2d4b0e9c254efa022767bacceb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 1 Jun 2019 15:33:47 -0400    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 1 Jun 2019 15:33:47 -0400    

Support of CHECK OPTION for updatable views has been added in 9.4, but  
the documentation of information_schema never got the call even if the  
information displayed is correct.  
  
Author: Gilles Darold  
Discussion: https://postgr.es/m/75d07704-6c74-4f26-656a-10045c01a17e@darold.net  
Backpatch-through: 9.4  

commit   : 6f54b80edd88abd5665aa12fbcf10f846dd80939    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 16:32:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 16:32:07 -0400    

Formerly, cpluspluscheck was only meant to examine headers that  
we thought of as exported --- but its notion of what we export  
was well behind the times.  Let's just make it check *all* .h  
files, except for a well-defined blacklist, instead.  
  
While at it, improve its ability to use a C++ compiler other than g++,  
by scraping the CXX setting from Makefile.global and making it possible  
to override the warning options used (per suggestion from Andres Freund).  
  
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru  

commit   : b1cd7ce23f40e1e443b3f2ab127bbe8348add678    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 31 May 2019 12:36:17 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 31 May 2019 12:36:17 -0700    

Previously cpluspluscheck wouldn't work in vpath builds, this commit  
fixes that. To make it easier to invoke, there's a top-level  
cpluspluscheck target.  
  
Discussion: https://postgr.es/20190530220244.kiputcbl4gkl2oo6@alap3.anarazel.de  

commit   : 72b6223f766d6ba9076d7b1ebdf05df75e83ba5c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 31 May 2019 13:30:05 -0400    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 31 May 2019 13:30:05 -0400    

Author: Antonin Houska  
Discussion: https://postgr.es/m/22370.1559293357@localhost  

commit   : ec66ec8b21d3d779047313ac214fba7bcd29a97c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 12:47:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 12:47:19 -0400    

Mea culpa for not rechecking check-world at the last step :-(  
Per buildfarm.  

commit   : 4f67858d3f210658d42f44fc674d2850581e572e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 12:38:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 12:38:53 -0400    

There's probably no need to back-patch this, since it seems unlikely  
that anybody would be inserting C++ code into ecpg's preprocessor.  
  
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru  

commit   : 3f61b3205f1a8bd27909be97341f002db8842093    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 12:34:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 12:34:54 -0400    

Rename some exposed parameters so that they don't conflict with  
C++ reserved words.  
  
Back-patch to all supported versions.  
  
George Tarasov  
  
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru  

commit   : 7640f9312321ceba2af61f7017da7e64f0f7b667    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 11:45:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 11:45:33 -0400    

We have a longstanding project convention that all .h files should  
be includable with no prerequisites other than postgres.h.  This is  
tested/relied-on by cpluspluscheck.  However, cpluspluscheck has not  
historically been applied to most headers outside the src/include  
tree, with the predictable consequence that some of them don't work.  
Fix that, usually by adding missing #include dependencies.  
  
The change in printf_hack.h might require some explanation: without  
it, my C++ compiler whines that the function is unused.  There's  
not so many call sites that "inline" is going to cost much, and  
besides all the callers are in test code that we really don't care  
about the size of.  
  
There's no actual bugs being fixed here, so I see no need to back-patch.  
  
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru  

commit   : 9e58705a7f9728f10b2e0f0c9adc6e6ecff7486e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 10:40:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 May 2019 10:40:00 -0400    

While C is happy to cast "const void *" to "const unsigned char *"  
silently, C++ insists on an explicit cast.  Since we put these  
functions into header files, cpluspluscheck whines about that.  
Add the cast to pacify it.  
  
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru  

commit   : d22f885f895add7e0184b08a78ba92ff091e36c4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 31 May 2019 10:08:37 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 31 May 2019 10:08:37 -0400    

New in 147e3722f7e5.  

commit   : fc115d0f9fc656967260815c031e0f25741428ae    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 May 2019 16:58:17 -0400    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 May 2019 16:58:17 -0400    

This makes the tool consistent with the option set of oid2name, which  
has been historically using -f for filenodes, and has more recently  
gained long options and --filenode via 1aaf532.  
  
Reported-by: Peter Eisentraut  
Author: Fabien Coelho  
Discussion: https://postgr.es/m/97045260-fb9e-e145-a950-cf7d28c4eaea@2ndquadrant.com  

commit   : 13002bf0bcdf4900987684ca6ef7665a25aa692b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 30 May 2019 13:44:38 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 30 May 2019 13:44:38 -0700    

Interestingly only C++ compilers have, so far, complained about this  
odd forward declaration. This originated when IndexBuildCallback was  
defined in another file, but now is completely unnecessary (but was  
wrong before too, cpluspluscheck just wouldn't have noticed).  
  
Reported-By: Tom Lane  
Discussion: https://postgr.es/m/53941.1559239260@sss.pgh.pa.us  

commit   : fe415ff10408a1487d5773b47459306476ec58f0    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 30 May 2019 16:16:12 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 30 May 2019 16:16:12 +0200    

Most errors reported in extended statistics are internal issues, and so  
should use elog(). The MCV list code was already following this rule, but  
the functional dependencies and ndistinct coefficients were using a mix  
of elog() and ereport(). Fix this by changing most places to elog(), with  
the exception of input functions.  
  
This is a mostly cosmetic change, it makes the life a little bit easier  
for translators, as elog() messages are not translated. So backpatch to  
PostgreSQL 10, where extended statistics were introduced.  
  
Author: Tomas Vondra  
Backpatch-through: 10 where extended statistics were added  
Discussion: https://postgr.es/m/20190503154404.GA7478@alvherre.pgsql  

commit   : 56b78626c7288fad498c0fae7fe4fd1f240ed13f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 May 2019 11:37:37 -0400    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 May 2019 11:37:37 -0400    

Author: Guillaume Lelarge  
Discussion: https://postgr.es/m/CAECtzeWPz4JikzUqZdMjqPTe8dAP3nZxPD-58Y-Hhvirg0fF+A@mail.gmail.com  

commit   : f73293aba4d43e48707e361b2b1ef1465fef46e0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 May 2019 11:19:06 -0400    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 29 May 2019 11:19:06 -0400    

This got forgotten in f56f8f which has added foreign key support for  
partitioned tables.  In passing, add a mention about caveats applying to  
tables partitioned using inheritance regarding indexes and foreign keys.  
  
Author: Paul A Jungwirth  
Reviewed-by: Amit Langote, Michael Paquier  
Discussion: https://postgr.es/m/CA+renyUuSmYgmZjKc_DfUNVZ0uttF91-FwhDVW3F7WEPj0jL5w@mail.gmail.com  

commit   : d890fa812dd4620db0d092da1cd7cba01494cd21    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 May 2019 23:44:22 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 May 2019 23:44:22 -0400    

commit   : a100974751baec7e13a527bf0c378ce8ef2787b6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 May 2019 17:34:38 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 May 2019 17:34:38 -0400    

I introduced the typo in source code in the course of 75445c1515ff.  
Repair.  

commit   : 40b132c1afbb4b1494aa8e48cc35ec98d2b90777    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 28 May 2019 12:59:00 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 28 May 2019 12:59:00 -0700    

When this suite runs installcheck, redirect file creations from  
src/test/regress to src/bin/pg_upgrade/tmp_check/regress.  This closes a  
race condition in "make -j check-world".  If the pg_upgrade suite wrote  
to a given src/test/regress/results file in parallel with the regular  
src/test/regress invocation writing it, a test failed spuriously.  Even  
without parallelism, in "make -k check-world", the suite finishing  
second overwrote the other's regression.diffs.  This revealed test  
"largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too.  
  
Buildfarm client REL_10, released fifty-four days ago, supports saving  
regression.diffs from its new location.  When an older client reports a  
pg_upgradeCheck failure, it will no longer include regression.diffs.  
Back-patch to 9.5, where pg_upgrade moved to src/bin.  
  
Reviewed (in earlier versions) by Andrew Dunstan.  
  
Discussion: https://postgr.es/m/20181224034411.GA3224776@rfd.leadboat.com  

commit   : 10b72deafea5972edcafb9eb3f97154f32ccd340    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 28 May 2019 12:58:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 28 May 2019 12:58:30 -0700    

This allows "vcregress upgradecheck" to pass twice in immediate  
succession, and it's more like how $(prove_check) works.  Back-patch to  
9.5, where pg_upgrade moved to src/bin.  
  
Discussion: https://postgr.es/m/20190520012436.GA1480421@rfd.leadboat.com  

commit   : d5ec46bf224d2ea1b010b2bc10a65e44d4456553    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 28 May 2019 09:06:40 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 28 May 2019 09:06:40 -0700    

Mea culpa.  

commit   : a94fd139df975a006d1697d2a7180d3656222d4d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 28 May 2019 08:26:24 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 28 May 2019 08:26:24 -0400    

This code block was copied/adapted from other similar places but  
somehow the comment placement was changed so that it makes less sense.  

commit   : 3ceaed106d95e76c7dbfd41f5d83a163fd0d25c8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 May 2019 07:17:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 May 2019 07:17:34 -0400    

Reported-by: Gaby Schilders  

commit   : af94ea7406f332567331a9b2525fae4b57c96061    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 May 2019 06:33:30 -0400    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 May 2019 06:33:30 -0400    

Author: Gurjeet Singh  
Discussion: https://postgr.es/m/CABwTF4U_5kEnH93PXZEuEsZHuoSSuBEOqC6pian8vDfLZSQJNA@mail.gmail.com  

commit   : 00ef6e3b28a8220f2dba881dbf56e3ba62f851bd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 27 May 2019 12:26:16 -0400    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 27 May 2019 12:26:16 -0400    

The old text still had an implicit reference to the virtual behavior,  
which was not in the final patch.  
  
Author: Tobias Bussmann <t.bussmann@gmx.net>  

commit   : 39fe881d3cf315d8d2ea9ee4ea1e3e39a82d5cc7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 May 2019 10:39:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 May 2019 10:39:11 -0400    

ecpg_build_params() failed to check for ecpg_alloc failure in one  
newly-added code path, and leaked a temporary string in another path.  
Errors in commit a1dc6ab46, spotted by Coverity.  

commit   : 331695a4d9ca40864240aca721dc588a206ff395    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 May 2019 10:06:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 May 2019 10:06:37 -0400    

ecpg_register_prepared_stmt() is pretty obviously checking the wrong  
variable while trying to detect malloc failure.  Error in commit  
a1dc6ab46, spotted by Coverity.  

commit   : 9679345f3c5ec071f63db358581e28f06c8744a7    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sun, 26 May 2019 18:28:18 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sun, 26 May 2019 18:28:18 +0530    

Reported-by: Alexander Lakhin  
Author: Alexander Lakhin  
Reviewed-by: Amit Kapila and Tom Lane  
Discussion: https://postgr.es/m/7208de98-add8-8537-91c0-f8b089e2928c@gmail.com  

commit   : 41205719d34969018f708baa70d9d06dae0c0d08    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 26 May 2019 08:08:05 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 26 May 2019 08:08:05 +0200    

Change extension for Graphviz files from .dot to .gv.  The latter  
appears to be the generally preferred one nowadays.  
  
Discussion: https://www.postgresql.org/message-id/flat/71fe76d2-c7d7-2acc-6762-bbf9e61c566e%402ndquadrant.com  

commit   : 02aa15de1b3821b0288a13dec71ce99f2e31fda5    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 25 May 2019 15:40:53 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 25 May 2019 15:40:53 +0530    

Reported-by: Euler Taveira  
Author: Euler Taveira  
Discussion: https://postgr.es/m/CAHE3wgjiA8DdnUzH9WqBLxdrUVvjDkKNdHx-MkEg9uV+HtpMfg@mail.gmail.com  

commit   : 591fb289c3eef010ee1bb271a54fab7da385c4cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 May 2019 11:16:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 May 2019 11:16:06 -0400    

Per bug #15819 from Koizumi Satoru.  
  
Discussion: https://postgr.es/m/15819-e6191bef1f7334c0@postgresql.org  

commit   : 4c9210f34c621639f896d57cf7bfb5e9be139c91    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 23 May 2019 13:23:59 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 23 May 2019 13:23:59 +1200    

Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CA%2BhUKGJFWXmtYo6Frd77RR8YXCHz7hJ2mRy5aHV%3D7fJOqDnBHA%40mail.gmail.com  

commit   : 7988cb446d20512ec9d091db66dba6adee3f3d4b    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 23 May 2019 13:17:41 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 23 May 2019 13:17:41 +1200    

Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CA%2BhUKGJFWXmtYo6Frd77RR8YXCHz7hJ2mRy5aHV%3D7fJOqDnBHA%40mail.gmail.com  

commit   : 73b8c3bd2889fed986044e15aefd0911f96ccdd3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 23 May 2019 16:25:48 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 23 May 2019 16:25:48 -0700    

Some of the wrapper functions didn't match the callback names. Many of  
them due to staying "consistent" with historic naming of the wrapped  
functionality. We decided that for most cases it's more important to  
be for tableam to be consistent going forward, than with the past.  
  
The one exception is beginscan/endscan/...  because it'd have looked  
odd to have systable_beginscan/endscan/... with a different naming  
scheme, and changing the systable_* APIs would have caused way too  
much churn (including breaking a lot of external users).  
  
Author: Ashwin Agrawal, with some small additions by Andres Freund  
Reviewed-By: Andres Freund  
Discussion: https://postgr.es/m/CALfoeiugyrXZfX7n0ORCa4L-m834dzmaE8eFdbNR6PMpetU4Ww@mail.gmail.com  

commit   : 54487d1560619a0027e0651d1b8d715ca8fc388c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 24 May 2019 08:19:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 24 May 2019 08:19:21 +0900    

The access method name "amname" can be dumped as of 3b925e90, but  
queries for backends older than 9.5 forgot to map it to a dummy NULL  
value, causing the column to not be mapped to a number.  As a result,  
pg_dump was throwing some spurious errors in its stderr output coming  
from libpq:  
pg_dump: column number -1 is out of range 0..36  
  
Fix this issue by adding a mapping of "amname" to NULL to all the older  
queries.  
  
Discussion: https://postgr.es/m/20190522083038.GA16837@paquier.xyz  
Author: Michael Paquier  
Reviewed-by: Dmitry Dolgov, Andres Freund, Tom Lane  

commit   : f916221df5652b95c402847905bdf48950b5b281    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 23 May 2019 14:46:52 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 23 May 2019 14:46:52 -0700    

On master (after 700538) the old version's installed psql was used -  
even when the old version might not actually be installed / might be  
installed into a temporary directory. As commonly the case when just  
executing make check for pg_upgrade, as $oldbindir is just the current  
version's $bindir.  
  
In the back branches, with --install specified, psql from the new  
version's temporary installation was used, without --install (e.g for  
NO_TEMP_INSTALL, cf 47b3c26642), the new version's installed psql was  
used (which might or might not exist).  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190522175150.c26f4jkqytahajdg@alap3.anarazel.de  

commit   : 44e95b5728a4569c494fa4ea4317f8a2f50a206b    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 23 May 2019 15:26:01 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 23 May 2019 15:26:01 +0100    

When there were duplicate columns in the hash key list, the array  
sizes could be miscomputed, resulting in access off the end of the  
array. Adjust the computation to ensure the array is always large  
enough.  
  
(I considered whether the duplicates could be removed in planning, but  
I can't rule out the possibility that duplicate columns might have  
different hash functions assigned. Simpler to just make sure it works  
at execution time regardless.)  
  
Bug apparently introduced in fc4b3dea2 as part of narrowing down the  
tuples stored in the hashtable. Reported by Colm McHugh of Salesforce,  
though I didn't use their patch. Backpatch back to version 10 where  
the bug was introduced.  
  
Discussion: https://postgr.es/m/CAFeeJoKKu0u+A_A9R9316djW-YW3-+Gtgvy3ju655qRHR3jtdA@mail.gmail.com  

commit   : 156c0c2dff403fd115f3a5f6d73ab80959c84129    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 May 2019 10:48:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 May 2019 10:48:17 +0900    

This uses a method similar to 68a7c24f and now b8c6014 (applied for  
database creation), which guarantees that GRANT commands using the WITH  
GRANT OPTION are dumped in a way so as cascading dependencies are  
respected.  Note that tablespaces do not have support for initial  
privileges via pg_init_privs, so the same method needs to be applied  
again.  It would be nice to merge all the logic generating ACL queries  
in dumps under the same banner, but this requires extending the support  
of pg_init_privs to objects that cannot use it yet, so this is left as  
future work.  
  
Discussion: https://postgr.es/m/20190522071555.GB1278@paquier.xyz  
Author: Michael Paquier  
Reviewed-by: Nathan Bossart  
Backpatch-through: 9.6  

commit   : 657c2384c6c79c6ed0d6f71f811b2fc7c41f104a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 May 2019 09:36:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 23 May 2019 09:36:28 +0900    

This has been forgotten in 578b229, which has removed support for WITH  
OIDS.  
  
Discussion: https://postgr.es/m/CALAY4q99FcFCoG6ddke0V-AksGe82L_+bhDWgEfgZBakB840zA@mail.gmail.com  
Author: Surafel Temesgen  

commit   : db6e2b4c52ade524f3db419d75084728e96e1f9c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 13:36:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 13:36:19 -0400    

Make all the perl code look nice, too (for some value of "nice").  

commit   : 8255c7a5eeba8f1a38b7a431c04909bde4f5e67d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 13:04:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 13:04:48 -0400    

Switch to 2.1 version of pg_bsd_indent.  This formats  
multiline function declarations "correctly", that is with  
additional lines of parameter declarations indented to match  
where the first line's left parenthesis is.  
  
Discussion: https://postgr.es/m/CAEepm=0P3FeTXRcU5B2W3jv3PgRVZ-kGUXLGfd42FFhUROO3ug@mail.gmail.com  

commit   : be76af171cdb3e7465c4ef234af403f97ad79b7b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 12:55:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 12:55:34 -0400    

This is still using the 2.0 version of pg_bsd_indent.  
I thought it would be good to commit this separately,  
so as to document the differences between 2.0 and 2.1 behavior.  
  
Discussion: https://postgr.es/m/16296.1558103386@sss.pgh.pa.us  

commit   : 66a4bad83aaa6613a45a00a488c04427f9969fb4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 May 2019 19:37:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 May 2019 19:37:52 +0200    

This code was still using the old style of forming a heap tuple rather  
than using tuple slots.  This would be less efficient if a non-heap  
access method was used.  And using tuple slots is actually quite a bit  
faster when using heap as well.  
  
Also add some test cases for generated columns with null values and  
with varlena values.  This lack of coverage was discovered while  
working on this patch.  
  
Discussion: https://www.postgresql.org/message-id/flat/20190331025744.ugbsyks7czfcoksd%40alap3.anarazel.de  

commit   : 03de5187d50af67d154a47cf00899290dca13003    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 23 May 2019 01:18:16 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 23 May 2019 01:18:16 +0900    

Commit 41b54ba78e allowed not only VACUUM but also ANALYZE options  
to take a boolean argument. But it forgot to update the documentation  
for ANALYZE. This commit adds the descriptions about those ANALYZE  
boolean options into the documentation.  
  
This patch also updates tab-completion for ANALYZE boolean options.  
  
Reported-by: Kyotaro Horiguchi  
Author: Fujii Masao  
Reviewed-by: Masahiko Sawada, Michael Paquier  
Discussion: https://postgr.es/m/CAHGQGwHTUt-kuwgiwe8f0AvTnB+ySqJWh95jvmh-qcoKW9YA9g@mail.gmail.com  

commit   : 166f69f769c83ef8759d905bf7f1a9aa1d97a340    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 11:46:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 11:46:57 -0400    

The original coding of this view relied on a correlated IN sub-query.  
Our planner is not very bright about correlated sub-queries, and even  
if it were, there's no way for it to know that the output of  
pg_get_publication_tables() is duplicate-free, making the de-duplicating  
semantics of IN unnecessary.  Hence, rewrite as a LATERAL sub-query.  
This provides circa 100X speedup for me with a few hundred published  
tables (the whole regression database), and things would degrade as  
roughly O(published_relations * all_relations) beyond that.  
  
Because the rules.out expected output changes, force a catversion bump.  
Ordinarily we might not want to do that post-beta1; but we already know  
we'll be doing a catversion bump before beta2 to fix pg_statistic_ext  
issues, so it's pretty much free to fix it now instead of waiting for v13.  
  
Per report and fix suggestion from PegoraroF10.  
  
Discussion: https://postgr.es/m/1551385426763-0.post@n3.nabble.com  

commit   : 728840fe13acff7b03a4b1a813eeb8900ce5e469    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 22 May 2019 11:22:13 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 22 May 2019 11:22:13 -0400    

Move support function mention to the proper section, and reword.  
  
Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/5121.1558472431@sss.pgh.pa.us  

commit   : ba95a6933632410d103d6f17cd3bc1adf92a08f9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 22 May 2019 10:54:40 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 22 May 2019 10:54:40 -0400    

Clarify new restriction on recovery_target* variables.  
  
Reported-by: Gaby Schilders  
  
Discussion: reported via chat  

commit   : 4a657ab260499381c645673ca1c3255adc0b2ace    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 10:42:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 10:42:24 -0400    

Oversight in commit a1dc6ab465986a62b308dd1bb8da316b5ed9685a.  

commit   : 4fbf809e13c3ba09c4f03d148cb58767e56f67f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 10:38:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 May 2019 10:38:21 -0400    

That leads to unsatisfied external references if the C compiler fails  
to elide unused static functions.  Apparently, we have no buildfarm  
members building HEAD that have that issue ... but such compilers still  
exist in the wild.  Need to do something about that.  
  
In passing, fix Berkeley-era typo in comment.  
  
Discussion: https://postgr.es/m/27054.1558533367@sss.pgh.pa.us  

commit   : b8c6014a65ee0819e8fe4c7536f72da0df5d8e46    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 May 2019 14:48:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 May 2019 14:48:00 +0900    

This uses a method similar to 68a7c24f, which guarantees that GRANT  
commands using the WITH GRANT OPTION are dumped in a way so as cascading  
dependencies are respected.  As databases do not have support for  
initial privileges via pg_init_privs, we need to repeat again the same  
ACL reordering method.  
  
ACL for databases have been moved from pg_dumpall to pg_dump in v11, so  
this impacts pg_dump for v11 and above, and pg_dumpall for v9.6 and  
v10.  
  
Discussion: https://postgr.es/m/15788-4e18847520ebcc75@postgresql.org  
Author: Nathan Bossart  
Reviewed-by: Haribabu Kommi  
Backpatch-through: 9.6  

commit   : 5eb4a51cb15166392ca3ede6ec58f8f1f820ef53    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 May 2019 23:51:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 May 2019 23:51:19 -0400    

Commit 5af2e976d removed a bit too much from the test.sh invocation.  
Per buildfarm.  

commit   : a1dc6ab465986a62b308dd1bb8da316b5ed9685a    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Wed, 22 May 2019 04:58:29 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Wed, 22 May 2019 04:58:29 +0200    

Besides implementing the new statement this change fix some issues with the  
parsing of PREPARE and EXECUTE statements. The different forms of these  
statements are now all handled in a ujnified way.  
  
Author: Matsumura-san <matsumura.ryo@jp.fujitsu.com>  

commit   : 5af2e976d72aa345337596cc986237c57e1146b2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 21 May 2019 15:03:27 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 21 May 2019 15:03:27 -0700    

When $(MAKE) is present in a rule, make assumes that target is a  
submake, and it doesn't need to buffer its output. But in this case  
it's a shell script that needs buffered output. Avoid that heuristic,  
by referring to $(MAKE) via an indirection.  
  
Discussion: https://postgr.es/m/20190521004717.qsktdsugj3shagco@alap3.anarazel.de  

commit   : 7005389b2ad17258bc3aa0a2427c4eb77fed1d09    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 21 May 2019 14:56:29 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 21 May 2019 14:56:29 -0700    

For pg_upgrade's test we (unless prevented by the caller via via  
NO_TEMP_INSTALL) built a separate installation. That causes an  
unnecessary slowdown after the infrastructure introduced by  
dcae5faccab (and unnecessarily duplicates code).  
  
Author: Andres Freund  
Reviewed-By: Tom Lane  
Discussion:  
    https://postgr.es/m/20190521191918.z7kwnrlj45mk2k67@alap3.anarazel.de  
    https://postgr.es/m/20190521195209.qfzwfxvymguuwlu5@alap3.anarazel.de  

commit   : 8e719d33fd253fc378871ba4dbf2de41fd2ba462    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 21 May 2019 16:45:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 21 May 2019 16:45:48 -0400    

Discussion: https://postgr.es/m/22793.1558399695@sss.pgh.pa.us  

commit   : 3468a04a3e498bab755909505e8f7b6023bea493    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 21 May 2019 16:35:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 21 May 2019 16:35:43 -0400    

Discussion: https://postgr.es/m/15486.1558393010@sss.pgh.pa.us  

commit   : b84a801d6a6737e6d84326b77d98b498402ecad0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 21 May 2019 16:31:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 21 May 2019 16:31:02 -0400    

Discussion: https://postgr.es/m/87y330d8ty.fsf@news-spur.riddles.org.uk  

commit   : 0fca8285ea533fa669a372c91fdb42265dcf7435    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 21 May 2019 16:19:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 21 May 2019 16:19:43 -0400    

commit   : 32fe2e3194c7198ca4afdb6bea4ffa12466612b1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 21 May 2019 16:14:33 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 21 May 2019 16:14:33 -0400    

Mostly commit messages, attribution, and text, all suggested by Andres  
Freund.  
  
Discussion: https://postgr.es/m/20190520221719.pqgld3krjc2docr5@alap3.anarazel.de  

commit   : eb9812f272db8e93416831e5254569b76edf8264    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 May 2019 13:11:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 May 2019 13:11:57 -0400    

The use of "set -x" to echo a subset of the test's commands might've  
been a good idea during development of this test, but it's been stable  
for long enough now that the extra output isn't very useful.  Also  
our project expectations have been trending towards less output in  
non-error cases; the fact that "set -x" produces output on stderr  
is particularly annoying from that standpoint.  So get rid of it.  
  
Also, pass "-A trust" to initdb explicitly so that it won't issue  
a warning about "trust" being an insecure default.  This matches  
what the TAP tests have done for a long time, and again gets rid  
of some noise on stderr.  
  
Discussion: https://postgr.es/m/21766.1558397960@sss.pgh.pa.us  

commit   : f03a9ca4366d064d89b7cf7ed75d4e43f2ed0667    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 May 2019 12:23:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 May 2019 12:23:16 -0400    

We're seeing occasional instability in the plans generated for  
parallel queries on the "a_star" table hierarchy.  This suggests  
that something is changing the planner's stats for those tables,  
but that should not be happening within a regression test run.  
To try to gather some information about what's happening, insert  
additional queries to check the basic page/tuple counts for these  
tables, as well as whether any vacuums or analyzes have happened  
on them.  (We expect that only the database-wide VACUUM in  
sanity_check.sql will have touched them.)  
  
I added the probes not only in select_parallel.sql itself, but  
also in stats.sql, bearing in mind that the stats collector's  
lag may prevent the initial query from reporting current truth.  
If any extra vacuum/analyze has happened, the recheck in stats.sql  
definitely ought to see it.  
  
This commit can be reverted once we figure out what's going on.  
  
Per suggestion from David Rowley, though I changed the queries around.  
  
Discussion: https://postgr.es/m/CA+hUKG+0CxrKRWRMf5ymN3gm+BECHna2B-q1w8onKBep4HasUw@mail.gmail.com  

commit   : 1171d7d58545f26a402f76a05936d572bf29d53b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 21 May 2019 11:57:13 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 21 May 2019 11:57:13 -0400    

This allows table AMs to completely suppress TOAST table creation, or  
to modify the conditions under which they are created.  
  
Patch by me.  Reviewed by Andres Freund.  
  
Discussion: http://postgr.es/m/CA+Tgmoa4O2n=yphqD2pERUnYmUO84bH1SqMsA-nSxBGsZ7gWfA@mail.gmail.com  

commit   : cf92226e9f7f985a678287167b954a831a3b660c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 May 2019 18:39:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 May 2019 18:39:53 -0400    

Define the meanings of the POSIX-spec character classes in line,  
rather than referring to the ctype(3) man page.  That man page  
doesn't even exist on many modern systems, and if it does exist  
it probably says the wrong things about non-ASCII characters.  
Also document our non-POSIX-spec "ascii" character class.  
  
Also, point out here that this behavior is controlled by collation or  
LC_CTYPE, since the existing text explaining that is pretty far away.  
  
Per gripe from Geert Lobbestael.  Given the lack of prior complaints,  
I'm not excited about back-patching this.  
  
Discussion: https://postgr.es/m/155837022049.1359.2948065118562813468@wrigleys.postgresql.org  

commit   : a240570b1e3802d1e82da08a9d72abeade370249    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 May 2019 16:37:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 May 2019 16:37:22 -0400    

commit   : 47a14c99e4715dde7f570d050e1ddb6d21278bf8    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 20 May 2019 09:36:06 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 20 May 2019 09:36:06 -0700    

This shouldn't have been committed without even running the tests (nor  
were the tests added that were suggested). I'm fixing up the results  
to get the buildfarm back to green, it's quite possible we'll want to  
revert this later.  

commit   : b8e2170e40a151eb94079ce9cd791a712ed95342    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 21 May 2019 00:44:00 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 21 May 2019 00:44:00 +0900    

"segno" is the argument for the function, not "log" and "seg".  
  
Author: Antonin Houska  
Discussion: https://postgr.es/m/11863.1558361020@spoje.net  

commit   : fc7c281f87467c1ff24fd72e0cc313dd6a71873f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 21 May 2019 00:22:06 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 21 May 2019 00:22:06 +0900    

Commit 41b54ba78e allowed existing VACUUM options to take a boolean  
argument. It's documented that valid boolean values that VACUUM can  
accept are true, false, on, off, 1, and 0. But previously the parser  
failed to accept 1 and 0 as a boolean value in VACUUM syntax because  
of a lack of NumericOnly clause for vac_analyze_option_arg in gram.y.  
  
This commit adds such NumericOnly clause so that VACUUM options  
can take also 1 and 0 as a boolean value.  
  
Discussion: https://postgr.es/m/CAHGQGwGYg82A8UCQxZe7Zn9MnyUBGdyB=1CNpKF3jBny+RbyfA@mail.gmail.com  

commit   : 3c439a58df83ae51f650cfae9878df1f9b70c4b8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 20 May 2019 16:00:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 20 May 2019 16:00:53 +0200    

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

commit   : 8bbb8166b63eeebd0cb618ddcf7dcaf8c4ba66f4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 20 May 2019 08:33:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 20 May 2019 08:33:31 +0200    

It's outdated and not really in use anymore.  
  
Discussion: https://www.postgresql.org/message-id/flat/cf7ed2b1-1ebe-83cf-e05e-d5943f67af2d%402ndquadrant.com  

commit   : fb504c5e4b5ce71e703006375ee2f5e4b57d89c9    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 19 May 2019 20:47:54 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 19 May 2019 20:47:54 -0700    

commit   : 2657283256f1cab53d09d2c7db1ce9b7065193a0    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 19 May 2019 18:01:06 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 19 May 2019 18:01:06 -0700    

For partial aggregation combine steps,  
AggStatePerTrans->numTransInputs was set to the transition function's  
number of inputs, rather than the combine function's number of  
inputs (always 1).  
  
That lead to partial aggregates with strict combine functions to  
wrongly check for NOT NULL input as required by strictness. When the  
aggregate wasn't exactly passed one argument, the strictness check was  
either omitted (in the 0 args case) or too many arguments were  
checked. In the latter case we'd read beyond the end of  
FunctionCallInfoData->args (only in master).  
  
AggStatePerTrans->numTransInputs actually has been wrong since since  
9.6, where partial aggregates were added. But it turns out to not be  
an active problem in 9.6 and 10, because numTransInputs wasn't used at  
all for combine functions: Before c253b722f6 there simply was no NULL  
check for the input to strict trans functions, and after that the  
check was simply hardcoded for the right offset in fcinfo, as it's  
done by code specific to combine functions.  
  
In bf6c614a2f2 (11) the strictness check was generalized, with common  
code doing the strictness checks for both plain and combine transition  
functions, based on numTransInputs. For combine functions this lead to  
not emitting an expression step to check for strict input in the 0  
arguments case, and in the > 1 arguments case, we'd check too many  
arguments.Due to the fact that the relevant fcinfo->isnull[2..] was  
always zero-initialized (more or less by accident, by being part of  
the AggStatePerTrans struct, which is palloc0'ed), there was no  
observable damage in the latter case before a9c35cf85ca1f, we just  
checked too many array elements.  
  
Due to the changes in a9c35cf85ca1f, > 1 argument bug became visible,  
because these days fcinfo is a) dynamically allocated without being  
zeroed b) exactly the length required for the number of specified  
arguments (hardcoded to 2 in this case).  
  
This commit only contains a fairly minimal fix, setting numTransInputs  
to a hardcoded 1 when building a pertrans for a combine function. It  
seems likely that we'll want to clean this up further (e.g. the  
arguments build_pertrans_for_aggref() aren't particularly meaningful  
for combine functions). But the wrap date for 12 beta1 is coming up  
fast, so it seems good to have a minimal fix in place.  
  
Backpatch to 11. While AggStatePerTrans->numTransInputs was set  
wrongly before that, the value was not used for combine functions.  
  
Reported-By: Rajkumar Raghuwanshi  
Diagnosed-By: Kyotaro Horiguchi, Jeevan Chalke, Andres Freund, David Rowley  
Author: David Rowley, Kyotaro Horiguchi, Andres Freund  
Discussion: https://postgr.es/m/CAKcux6=uZEyWyLw0N7HtR9OBc-sWEFeByEZC7t-KDf15FKxVew@mail.gmail.com  

commit   : 03310dbea9746439e9f0fdedce0fa298b8c4cc76    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 20 May 2019 09:47:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 20 May 2019 09:47:19 +0900    

Discussion: https://postgr.es/m/92961161-9b49-e42f-0a72-d5d47e0ed4de@postgrespro.ru  
Author: Liudmila Mantrova  
Reviewed-by: Jonathan Katz, Tom Lane, Michael Paquier  
Backpatch-through: 9.4  

commit   : 78d6a9cbd3438969ac87b9f1aaf0f07226636ed7    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 19 May 2019 16:17:18 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 19 May 2019 16:17:18 -0700    

The comment for SNAPSHOT_SELF was unfortunately explaining  
SNAPSHOT_DIRTY, as reported by Sergei. Also expand a few comments, and  
include a few more comments from heapam_visibility.c, so they're in an  
AM independent place.  
  
Reported-By: Sergei Kornilov  
Author: Andres Freund  
Discussion: https://postgr.es/m/9152241558192351@sas1-d856b3d759c7.qloud-c.yandex.net  

commit   : ae35e1c9d74afc3b1e7572ad60781946fdf71e95    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 19 May 2019 15:24:42 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 19 May 2019 15:24:42 -0700    

This reverts commit bd1592e8570282b1650af6b8eede0016496daecd.  It had  
multiple defects.  
  
Discussion: https://postgr.es/m/12717.1558304356@sss.pgh.pa.us  

commit   : c3b23ae457ddc8b7bfacb3c0569278615a2df2cd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 19 May 2019 15:10:28 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 19 May 2019 15:10:28 -0700    

Before this commit, when ANALYZE was run on a table and serializable  
was used (either by virtue of an explicit BEGIN TRANSACTION ISOLATION  
LEVEL SERIALIZABLE, or default_transaction_isolation being set to  
serializable) a null pointer dereference lead to a crash.  
  
The analyze scan doesn't need a snapshot (nor predicate locking), but  
before this commit a scan only contained information about being a  
bitmap or sample scan.  
  
Refactor the option passing to the scan_begin callback to use a  
bitmask instead. Alternatively we could have added a new boolean  
parameter, but that seems harder to read. Even before this issue  
various people (Heikki, Tom, Robert) suggested doing so.  
  
These changes don't change the scan APIs outside of tableam. The flags  
argument could be exposed, it's not necessary to fix this  
problem. Also the wrapper table_beginscan* functions encapsulate most  
of that complexity.  
  
After these changes fixing the bug is trivial, just don't acquire  
predicate lock for analyze style scans. That was already done for  
bitmap heap scans.  Add an assert that a snapshot is passed when  
acquiring the predicate lock, so this kind of bug doesn't require  
running with serializable.  
  
Also add a comment about sample scans currently requiring predicate  
locking the entire relation, that previously wasn't remarked upon.  
  
Reported-By: Joe Wildish  
Author: Andres Freund  
Discussion:  
    https://postgr.es/m/4EA80A20-E9BF-49F1-9F01-5B66CAB21453@elusive.cx  
    https://postgr.es/m/20190411164947.nkii4gaeilt4bui7@alap3.anarazel.de  
    https://postgr.es/m/20190518203102.g7peu2fianukjuxm@alap3.anarazel.de  

commit   : bd1592e8570282b1650af6b8eede0016496daecd    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 19 May 2019 14:36:44 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 19 May 2019 14:36:44 -0700    

When this suite runs installcheck, redirect file creations from  
src/test/regress to src/bin/pg_upgrade/tmp_check/regress.  This closes a  
race condition in "make -j check-world".  If the pg_upgrade suite wrote  
to a given src/test/regress/results file in parallel with the regular  
src/test/regress invocation writing it, a test failed spuriously.  Even  
without parallelism, in "make -k check-world", the suite finishing  
second overwrote the other's regression.diffs.  This revealed test  
"largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too.  
  
Buildfarm client REL_10, released forty-five days ago, supports saving  
regression.diffs from its new location.  When an older client reports a  
pg_upgradeCheck failure, it will no longer include regression.diffs.  
Back-patch to 9.5, where pg_upgrade moved to src/bin.  
  
Reviewed by Andrew Dunstan.  
  
Discussion: https://postgr.es/m/20181224034411.GA3224776@rfd.leadboat.com  

commit   : 9d5c22d28f8c161aa729d841aeec936c646044d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 May 2019 13:55:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 May 2019 13:55:39 -0400    

Discussion of bug #15804 reveals that this test didn't really prove  
that the syslogger child process ever launched successfully, much  
less did anything.  It was only checking that the expected log file  
gets created, and that's done in the postmaster.  Moreover, the  
test assumed it could rename the log file, which is likely to fail  
on Windows (cf. commit d611175e5).  
  
Instead, use the default log file name pattern, which should result  
in a new file name being chosen after 1 second, and verify that  
rotation has occurred by checking for a new file name.  Also add code  
to test that messages actually do propagate through the syslogger.  
  
In theory this version of the test should work on Windows, so  
revert d611175e5.  
  
Discussion: https://postgr.es/m/15804-3721117bf40fb654@postgresql.org  

commit   : 833451552925d0175e1e15128e411ddef9a36996    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 May 2019 11:14:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 May 2019 11:14:23 -0400    

This commit reverts 57431a911d3a650451d198846ad3194900666152.  
  
While that's still a good idea in the abstract, we found out  
that there are multiple crasher bugs in it on Windows builds,  
making the logging_collector option unusable on Windows.  
There's no time left to fix these issues before 12beta1,  
so revert the patch to allow Windows beta testing to proceed.  
We'll try again at some future date.  
  
Per bug #15804 from Yulian Khodorkovskiy and additional  
investigation by Michael Paquier.  
  
Discussion: https://postgr.es/m/15804-3721117bf40fb654@postgresql.org  

commit   : da24961e9e1d887111d17cc2dcece2e3946ca5a6    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 19 May 2019 07:45:42 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 19 May 2019 07:45:42 +0300    

Make jsonb_path_query_array() and jsonb_path_query_first() use  
PG_FUNCTION_ARGS macro instead of its expansion.  

commit   : 87bcc02f4f739d76703feee0ff8346b98fa9b907    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 17 May 2019 05:47:53 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 17 May 2019 05:47:53 +0300    

Usage of expressions and multiple ranges in jsonpath array subscription was  
undocumented.  This commit adds lacking documentation.  

commit   : e0e3dad770d3eefc4ee6cd562d9c25b61c263a6e    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 17 May 2019 05:16:31 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 17 May 2019 05:16:31 +0300    

It appears that some variants of .** jsonpath accessor are undocumented.  In  
particular undocumented variants are:  
  
 .**{level}  
 .**{lower_level to upper_level}  
 .**{lower_level to last}  
  
This commit adds missing documentation for them.  

commit   : da71f98efba9aed493a178aa29f25dbca7407eaf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 May 2019 20:16:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 May 2019 20:16:50 -0400    

We still had a couple of these left in ancient src/port/ files.  
Convert them to modern style in preparation for switching to  
a version of pg_bsd_indent that doesn't cope well with K&R style.  
  
Discussion: https://postgr.es/m/16886.1558104483@sss.pgh.pa.us  

commit   : 93f03dad824f14f40519597e5e4a8fe7b6df858e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 May 2019 13:51:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 May 2019 13:51:16 -0400    

If PrepareTempTablespaces() has never been called in the current  
transaction, OpenTemporaryFile() will fall back to using the default  
tablespace, which is a bug if the user wanted temp files placed elsewhere.  
gistInitBuildBuffers() appears to have this disease already, and it  
seems like an easy trap for future coders to fall into.  
  
We discussed other ways to close this gap, but none of them are prettier  
or more reliable than just having BufFileCreateTemp do it.  In particular,  
having fd.c do this creates layering issues that we could do without.  
  
Per suggestion from Melanie Plageman.  Arguably this is a bug fix, but  
nobody seems very excited about back-patching, so change in HEAD only.  
  
Discussion: https://postgr.es/m/CAAKRu_YwzjuGAmmaw4-8XO=OVFGR1QhY_Pq-t3wjb9ribBJb_Q@mail.gmail.com  

commit   : b12db9ff5f09dc60dc05d0e208a5b28728970e55    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 18 May 2019 09:23:29 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 18 May 2019 09:23:29 -0400    

commit   : d307954a7d88ed45655d9206bbe1aefc280c09c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 May 2019 00:40:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 May 2019 00:40:39 -0400    

Per buildfarm.  

commit   : 147e3722f7e531f15ba389a4d518efe8cd0bd736    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 17 May 2019 18:52:01 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 17 May 2019 18:52:01 -0700    

Instead add a tableam callback to do so. To avoid adding per  
validation overhead, pass a scan to tuple_tid_valid. In heap's case  
we'd otherwise incurred a RelationGetNumberOfBlocks() call for each  
tid - which'd have added noticable overhead to nodeTidscan.c.  
  
Author: Andres Freund  
Reviewed-By: Ashwin Agrawal  
Discussion: https://postgr.es/m/20190515185447.gno2jtqxyktylyvs@alap3.anarazel.de  

commit   : 7f44ede5941499c4cee13b812dd93335f4005095    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 17 May 2019 18:06:18 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 17 May 2019 18:06:18 -0700    

Previously various parts of the code routed size requests through  
RelationGetNumberOfBlocks[InFork]. That works if md.c is used by the  
AM, but not otherwise.  
  
Add a tableam callback to return the size of the table. As not every  
AM will use postgres' BLCKSZ, have it return bytes, and have  
RelationGetNumberOfBlocksInFork() round the byte size up into blocks.  
  
To allow code outside of the AM to determine the actual relation size  
map InvalidForkNumber the total size of a relation, as not every AM  
might just need the postgres defined forks.  
  
A few users of RelationGetNumberOfBlocks() ought to be converted away  
from that. One case, the use of it to determine whether a tid is  
valid, will be fixed in a follow up commit. Others will have to wait  
for v13.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190423225201.3bbv6tbqzkb5w7cw@alap3.anarazel.de  

commit   : 6630ccad7a25cad32e2d1a6833fb971602cb67fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 May 2019 19:44:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 May 2019 19:44:19 -0400    

Previously, gen_partprune_steps() always built executor pruning steps  
using all suitable clauses, including those containing PARAM_EXEC  
Params.  This meant that the pruning steps were only completely safe  
for executor run-time (scan start) pruning.  To prune at executor  
startup, we had to ignore the steps involving exec Params.  But this  
doesn't really work in general, since there may be logic changes  
needed as well --- for example, pruning according to the last operator's  
btree strategy is the wrong thing if we're not applying that operator.  
The rules embodied in gen_partprune_steps() and its minions are  
sufficiently complicated that tracking their incremental effects in  
other logic seems quite impractical.  
  
Short of a complete redesign, the only safe fix seems to be to run  
gen_partprune_steps() twice, once to create executor startup pruning  
steps and then again for run-time pruning steps.  We can save a few  
cycles however by noting during the first scan whether we rejected  
any clauses because they involved exec Params --- if not, we don't  
need to do the second scan.  
  
In support of this, refactor the internal APIs in partprune.c to make  
more use of passing information in the GeneratePruningStepsContext  
struct, rather than as separate arguments.  
  
This is, I hope, the last piece of our response to a bug report from  
Alan Jackson.  Back-patch to v11 where this code came in.  
  
Discussion: https://postgr.es/m/FAD28A83-AC73-489E-A058-2681FA31D648@tvsquared.com  

commit   : 05685897f07e7ae5684f0247157faad1f782f889    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 17 May 2019 11:31:49 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 17 May 2019 11:31:49 -0400    

Discussion: https://postgr.es/m/0cf10a27-c6a0-de4a-cd20-ab7493ea7422@lab.ntt.co.jp  

commit   : 6ba500cae6f57acf8f392d9e1671640f7c9d43b3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 May 2019 09:40:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 May 2019 09:40:02 +0900    

75445c1 has caused various failures in tests across the tree after  
updating some error messages, so fix the newly-expected output.  
  
Author: Michael Paquier  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/8332.1558048838@sss.pgh.pa.us  

commit   : 41998f90ce66425ca6071ac5e170a19bb1498414    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 May 2019 08:22:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 May 2019 08:22:28 +0900    

Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/5520EDD8-7AC7-4307-8171-400DD1D84FDC@yesql.se  

commit   : 75445c1515fffa581585f1b72e5b5314c1c395ce    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 16 May 2019 18:50:56 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 16 May 2019 18:50:56 -0400    

Discussion: https://postgr.es/m/20190515183005.GA26486@alvherre.pgsql  

commit   : 3f58cc6dd8fc821992da7ed8099d283b014fc2dc    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 16 May 2019 15:11:58 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 16 May 2019 15:11:58 -0700    

It's not safe for nbtree VACUUM to attempt to delete a target page whose  
right sibling is already half-dead, since that would fail the  
cross-check when VACUUM attempts to re-find a downlink to the right  
sibling in the parent page.  Logic to prevent this from happening was  
added by commit 8da31837803, which addressed a bug in the overhaul of  
page deletion that went into PostgreSQL 9.4 (commit efada2b8e92).  
VACUUM was made to check the right sibling page, and back off when it  
happened to be half-dead already.  
  
However, it is only truly necessary to do the right sibling check on the  
leaf level, since that transitively determines if the deletion target's  
parent's right sibling page is itself undergoing deletion.  Remove the  
internal page level check, and add a comment explaining why the leaf  
level check alone suffices.  
  
The extra check is also unnecessary due to the fact that internal pages  
that are marked half-dead are generally considered corrupt.  Commit  
efada2b8e92 established the principle that there should never be  
half-dead internal pages (internal pages pending deletion are possible,  
but that status is never directly represented in the internal page).  
VACUUM will complain about corruption when it encounters half-dead  
internal pages, so VACUUM is bound to raise an error one way or another  
when an nbtree index has a half-dead internal page (contrib/amcheck will  
also report that the page is corrupt).  
  
It's possible that a pg_upgrade'd 9.3 database will still have half-dead  
internal pages, so it may seem like there is an argument for leaving the  
check in place to reliably get a cleaner error message that advises the  
user to REINDEX.  However, leaf pages are also deleted in the first  
phase of deletion prior to PostgreSQL 9.4, so I believe we won't even  
attempt to re-find the parent page anyway (we won't have the fully  
deleted leaf page as the right sibling of our target page, so we won't  
even try to find a downlink for it).  
  
Discussion: https://postgr.es/m/CAH2-Wzm_ntmqJjWLRyKzimFmFvk+BnVAvUpaA4s1h9Ja58woaQ@mail.gmail.com  

commit   : 3922f10646fc79264228ea3f6a7343cc3f8f528a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 May 2019 16:25:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 May 2019 16:25:43 -0400    

gen_prune_steps_from_opexps's notion of how to do this was overly  
complicated and underly correct.  
  
Per discussion of a report from Alan Jackson (though this fixes only one  
aspect of that problem).  Back-patch to v11 where this code came in.  
  
Amit Langote  
  
Discussion: https://postgr.es/m/FAD28A83-AC73-489E-A058-2681FA31D648@tvsquared.com  

commit   : 4b1fcb43d070ba8b34ea01d5a657630d76e4b33f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 May 2019 11:58:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 May 2019 11:58:21 -0400    

Cross-type comparison operators in a btree or hash opclass might be  
only stable not immutable (this is true of timestamp vs. timestamptz  
for example).  partprune.c ignored this possibility and would perform  
plan-time pruning with them anyway, possibly leading to wrong answers  
if the environment changed between planning and execution.  
  
To fix, teach gen_partprune_steps() to do things differently when  
creating plan-time pruning steps vs. run-time pruning steps.  
analyze_partkey_exprs() also needs an extra check, which is rather  
annoying but now is not the time to restructure things enough to  
avoid that.  
  
While at it, simplify the logic for the plan-time case a little  
by insisting that the comparison value be a Const and nothing else.  
This relies on the assumption that eval_const_expressions will have  
reduced any immutable expression to a Const; which is not quite  
100% true, but certainly any case that comes up often enough to be  
interesting should have simplification logic there.  
  
Also improve a bunch of inadequate/obsolete/wrong comments.  
  
Per discussion of a report from Alan Jackson (though this fixes only one  
aspect of that problem).  Back-patch to v11 where this code came in.  
  
David Rowley, with some further hacking by me  
  
Discussion: https://postgr.es/m/FAD28A83-AC73-489E-A058-2681FA31D648@tvsquared.com  

commit   : 489e431ba56b10f5736fb54a045ca40880f11bbc    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 15 May 2019 16:53:11 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 15 May 2019 16:53:11 -0700    

Remove a Berkeley-era comment above _bt_insertonpg() that admonishes the  
reader to grok Lehman and Yao's paper before making any changes.  This  
made a certain amount of sense back when _bt_insertonpg() was  
responsible for most of the things that are now spread across  
_bt_insertonpg(), _bt_findinsertloc(), _bt_insert_parent(), and  
_bt_split(), but it doesn't work like that anymore.  
  
I believe that this comment alludes to the need to "couple" or "crab"  
buffer locks as we ascend the tree as page splits cascade upwards.  The  
nbtree README already explains this in detail, which seems sufficient.  
Besides, the changes to page splits made by commit 40dae7ec537 altered  
the exact details of how buffer locks are retained during splits; Lehman  
and Yao's original algorithm seems to release the lock on the left child  
page/buffer slightly earlier than _bt_insertonpg()/_bt_insert_parent()  
can.  

commit   : 8a0f0ad54047c8dc1430e521e2dc90f2cd138a9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 May 2019 17:26:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 May 2019 17:26:52 -0400    

struct ClonedConstraint is no longer needed, so delete it.  
  
Discussion: https://postgr.es/m/18102.1557947143@sss.pgh.pa.us  

commit   : 7505da2f459776a397177f7d591991f5591c2812    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 15 May 2019 12:22:07 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 15 May 2019 12:22:07 -0700    

Commit fab25024, which taught nbtree to choose candidate split points  
more carefully, had _bt_findsplitloc() record all possible split points  
in an initial pass over a page that is about to be split.  The order  
that candidate split points were processed and stored in was assumed to  
match the offset number order of split points on an imaginary version of  
the page that contains the same items as the original, but also fits  
newitem (the item that provoked the split precisely because it didn't  
fit).  
  
However, the order of split points in the final array was not quite what  
was expected: the split point that makes newitem the firstright item  
came after the split point that makes newitem the lastleft item -- not  
before.  As a result, _bt_findsplitloc() could get confused about the  
leftmost and rightmost tuples among all possible split points recorded  
for the page.  This seems to have no appreciable impact on the quality  
of the final split point chosen by _bt_findsplitloc(), but it's still  
wrong.  
  
To fix, switch the order in which newitem candidate splits are recorded  
in.  This also makes it possible to describe candidate split points in  
terms of which pair of adjoining tuples enclose the split point within  
_bt_findsplitloc(), making it clearer why it's generally safe for  
_bt_split() to expect lastleft and firstright tuples.  

commit   : a429164ef31fc6899cef4d5e4f3f2ce8fc33aa27    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 15 May 2019 12:44:59 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 15 May 2019 12:44:59 -0400    

commit   : aa4b8c61d2cd57b53be03defb04d59b232a0e150    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 14 May 2019 12:11:26 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 14 May 2019 12:11:26 -0700    

For some reason both callsite and the implementation for heapam had  
the meaning inverted (i.e. succeeded == true was passed in case of  
conflict). That's confusing.  
  
I (Andres) briefly pondered whether it'd be better to rename  
table_complete_speculative's argument to 'bool specConflict' or such,  
but decided not to. The 'complete' in the function name for me makes  
`succeeded` sound a bit better.  
  
Reported-By: Ashwin Agrawal, Melanie Plageman, Heikki Linnakangas  
Discussion:  
   https://postgr.es/m/CALfoeitk7-TACwYv3hCw45FNPjkA86RfXg4iQ5kAOPhR+F1Y4w@mail.gmail.com  
   https://postgr.es/m/97673451-339f-b21e-a781-998d06b1067c@iki.fi  

commit   : 08e2edc0767ab6e619970f165cb34d4673105f23    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 14 May 2019 11:45:40 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 14 May 2019 11:45:40 -0700    

This path previously was not reliably covered. There was some  
heuristic coverage via insert-conflict-toast.spec, but that test is  
not deterministic, and only tested for a somewhat specific bug.  
  
Backpatch, as this is a complicated and otherwise untested code  
path. Unfortunately 9.5 cannot handle two waiting sessions, and thus  
cannot execute this test.  
  
Triggered by a conversion with Melanie Plageman.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/CAAKRu_a7hbyrk=wveHYhr4LbcRnRCG=yPUVoQYB9YO1CdUBE9Q@mail.gmail.com  
Backpatch: 9.5-  

commit   : 6d2fba3189608186d1a196a595f21760412ec5e8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 May 2019 14:28:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 May 2019 14:28:33 -0400    

We .gitignore'd this junk, but we didn't actually remove it.  

commit   : fc9a62af3f87f4bec1e8c904ea99ae50f3c881ef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 May 2019 14:19:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 May 2019 14:19:49 -0400    

The original placement of this module in src/fe_utils/ is ill-considered,  
because several src/common/ modules have dependencies on it, meaning that  
libpgcommon and libpgfeutils now have mutual dependencies.  That makes it  
pointless to have distinct libraries at all.  The intended design is that  
libpgcommon is lower-level than libpgfeutils, so only dependencies from  
the latter to the former are acceptable.  
  
We already have the precedent that fe_memutils and a couple of other  
modules in src/common/ are frontend-only, so it's not stretching anything  
out of whack to treat logging.c as a frontend-only module in src/common/.  
To the extent that such modules help provide a common frontend/backend  
environment for the rest of common/ to use, it's a reasonable design.  
(logging.c does not yet provide an ereport() emulation, but one can  
dream.)  
  
Hence, move these files over, and revert basically all of the build-system  
changes made by commit cc8d41511.  There are no places that need to grow  
new dependencies on libpgcommon, further reinforcing the idea that this  
is the right solution.  
  
Discussion: https://postgr.es/m/a912ffff-f6e4-778a-c86a-cf5c47a12933@2ndquadrant.com  

commit   : b71dad22ce8a645a47c01e544f640f35b91bfbd3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 May 2019 13:32:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 May 2019 13:32:03 -0400    

commit   : 53ddefbaf8a0493d2c1fa0b18bfaba72da556985    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 May 2019 13:11:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 May 2019 13:11:23 -0400    

The existence of these files became rather confusing with the  
introduction of a widely-known logging.h header in commit cc8d41511.  
(Indeed, there's already some duplicative #includes here, perhaps  
betraying such confusion.)  The only thing left in them, after that  
commit, is a progress-reporting function that's neither general-purpose  
nor tied in any way to other logging infrastructure.  Hence, let's just  
move that function to pg_rewind.c, and get rid of the separate files.  
  
Discussion: https://postgr.es/m/3971.1557787914@sss.pgh.pa.us  

commit   : 7c850320d8cfa5503ecec61c2559661b924f7595    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 May 2019 11:27:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 May 2019 11:27:31 -0400    

SQL's regular-expression substring() function is defined to have a  
pattern argument that's separated into three subpatterns by escape-  
double-quote markers; the function result is the part of the input  
matching the second subpattern.  The standard makes it clear that  
if there is ambiguity about how to match the input to the subpatterns,  
the first and third subpatterns should be taken to match the smallest  
possible amount of text (i.e., they're "non greedy", in the terms of  
our regex code).  We were not doing it that way: the first subpattern  
would eat the largest possible amount of text, causing the function  
result to be shorter than what the spec requires.  
  
Fix that by attaching explicit greediness quantifiers to the  
subpatterns.  (This depends on the regex fix in commit 8a29ed053;  
before that, this didn't reliably change the regex engine's behavior.)  
  
Also, by adding parentheses around each subpattern, we ensure that  
"|" (OR) in the subpatterns behave sanely.  Previously, "|" in the  
first or third subpatterns didn't work.  
  
This patch also makes the function throw error if you write more than  
two escape-double-quote markers, and do something sane if you write  
just one, and document that behavior.  Previously, an odd number of  
markers led to a confusing complaint about unbalanced parentheses,  
while extra pairs of markers were just ignored.  (Note that the spec  
requires exactly two markers, but we've historically allowed there  
to be none, and this patch preserves the old behavior for that case.)  
  
In passing, adjust some substring() test cases that didn't really  
prove what they said they were testing for: they used patterns  
that didn't match the data string, so that the output would be  
NULL whether or not the function was really strict.  
  
Although this is certainly a bug fix, changing the behavior in back  
branches seems undesirable: applications could perhaps be depending on  
the old behavior, since it's not obviously wrong unless you read the  
spec very closely.  Hence, no back-patch.  
  
Discussion: https://postgr.es/m/5bb27a41-350d-37bf-901e-9d26f5592dd0@charter.net  

commit   : fb489e4b3195fc33cccc0fd308e5a0ab502cf199    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 May 2019 10:22:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 May 2019 10:22:28 -0400    

Previously, the code pointed the standard process-termination signals  
to postgres.c's die().  That would typically result in an attempt to  
execute a transaction abort, which is not possible in bootstrap mode,  
leading to PANIC.  This choice seems to be a leftover from an old code  
structure in which the same signal-assignment code was used for many  
sorts of auxiliary processes, including interactive standalone  
backends.  It's not very sensible for bootstrap mode, which has no  
interest in either interactivity or continuing after an error.  We can  
get better behavior with less effort by just letting normal process  
termination happen, after which the parent initdb process will clean up.  
  
This is basically cosmetic in any case, since initdb will react the  
same way whether bootstrap dies on a signal or abort().  Given the  
lack of previous complaints, I don't feel a need to back-patch,  
even though the behavior is old.  
  
Discussion: https://postgr.es/m/3850b11a.5121.16aaf827e4a.Coremail.thunder1@126.com  

commit   : 037165ca95d854e04c0c28cfa85f1515bd852892    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 May 2019 14:56:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 May 2019 14:56:58 +0200    

commit   : eb3a1376c98a1d220354b468f4b09e4a1dca909a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 May 2019 15:15:05 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 May 2019 15:15:05 +0200    

This is mainly a light renumbering to match the sections in the  
standard.  

commit   : c29ba98189190288c2251c6073c13c6234479e5c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 May 2019 09:56:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 May 2019 09:56:40 +0200    

Per previous convention (see  
ace397e9d24eddc56e7dffa921f506117b602d78), drop SQL:2008 and only keep  
the latest two standards and SQL-92.  
  
Note: SQL:2016-2 lists a large number of non-reserved keywords that  
are really just information_schema column names related to new  
features.  Those kinds of thing have not previously been listed as  
keywords, and this was apparently done here by mistake, since these  
keywords have been removed again in post-2016 working drafts.  So in  
order to avoid bloating the keywords table unnecessarily, I have  
omitted these erroneous keywords here.  

commit   : 356c83795aaa39cfd9bca588bfe4f0196710962e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 May 2019 09:17:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 May 2019 09:17:08 -0400    

Reported-by: Amit Langote  
  
Discussion: https://postgr.es/m/b7954643-41ef-a174-479d-1f8d4834f40a@lab.ntt.co.jp  

commit   : 34d40becfa7a5c7343d0079f181597d7e06122e1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 May 2019 09:06:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 May 2019 09:06:03 -0400    

Reported-by: nickb@imap.cc  
  
Discussion: https://postgr.es/m/6b3414e1-fcef-4ad9-b123-b3ab3702d3db@www.fastmail.com  

commit   : 22251686f07f70527aecda22ab5402986884f6f5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 May 2019 13:18:44 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 May 2019 13:18:44 +0300    

As we descend the GiST tree during insertion, we modify any downlinks on  
the way down to include the new tuple we're about to insert (if they don't  
cover it already). Modifying an existing downlink might cause an internal  
page to split, if the new downlink tuple is larger than the old one. If  
that happens, we need to back up to the parent and re-choose a page to  
insert to. We used to detect that situation, thanks to the NSN-LSN  
interlock normally used to detect concurrent page splits, but that got  
broken by commit 9155580fd5. With that commit, we now use a dummy constant  
LSN value for every page during index build, so the LSN-NSN interlock no  
longer works. I thought that was OK because there can't be any other  
backends modifying the index during index build, but missed that the  
insertion itself can modify the page we're inserting to. The consequence  
was that we would sometimes insert the new tuple to an incorrect page, one  
whose downlink doesn't cover the new tuple.  
  
To fix, add a flag to the stack that keeps track of the state while  
descending tree, to indicate that a page was split, and that we need to  
retry the descend from the parent.  
  
Thomas Munro first reported that the contrib/intarray regression test was  
failing occasionally on the buildfarm after commit 9155580fd5. The failure  
was intermittent, because the gistchoose() function is not deterministic,  
and would only occasionally create the right circumstances for this bug to  
cause the failure.  
  
Patch by Anastasia Lubennikova, with some changes by me to make it work  
correctly also when the internal page split also causes the "grandparent"  
to be split.  
  
Discussion: https://www.postgresql.org/message-id/CA%2BhUKGJRzLo7tZExWfSbwM3XuK7aAK7FhdBV0FLkbUG%2BW0v0zg%40mail.gmail.com  

commit   : e95d550bbbe21f51d329fbae84cbac3545a9e650    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 May 2019 13:06:28 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 May 2019 13:06:28 +0300    

The conditions listed in this comment have changed several times, and at  
some point the thing that the "if so" referred to was negated.  
  
The text was OK up to 9.6. It was differently wrong in v10, v11 and  
master, so fix in all those versions.  

commit   : 7d9eca59cf958eb8c8ff47c40003392681a9ce68    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 14 May 2019 16:05:37 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 14 May 2019 16:05:37 +0900    

commit   : 0b62f0f2552d895301fdae56aa839c1eaae24a3a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 13 May 2019 22:55:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 13 May 2019 22:55:38 -0400    

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

commit   : f4125278e3c92d8cdd83c77d0b54f468ee81c750    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 13 May 2019 22:38:50 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 13 May 2019 22:38:50 -0400    

Reported-by: Amit Langote  
  
Discussion: https://postgr.es/m/d5267ae5-bd4a-3e96-c21b-56bfa9fec7e8@lab.ntt.co.jp  

commit   : 5d971565a7993ba8dcd06d34d1387af48fdbd034    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 13 May 2019 22:21:32 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 13 May 2019 22:21:32 -0400    

Reported-by: Fabien COELHO  
  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1905130839140.13487@lancre  

commit   : 7e19929ea29668f3d01280262e407b93042c959a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 May 2019 09:37:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 May 2019 09:37:35 +0900    

Author: Stephen Amell  
Discussion: https://postgr.es/m/539fa271-21b3-777e-a468-d96cffe9c768@gmail.com  

commit   : ae7291acbc5ae4c3751615177fc256f9f3399403    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 13 May 2019 15:53:39 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 13 May 2019 15:53:39 -0700    

The term "item pointer" should not be used to refer to ItemIdData  
variables, since that is needlessly ambiguous.  Only  
ItemPointerData/ItemPointer variables should be called item pointers.  
  
To fix, establish the convention that ItemIdData variables should always  
be referred to either as "item identifiers" or "line pointers".  The  
term "item identifier" already predominates in docs and translatable  
messages, and so should be the preferred alternative there.  
  
Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=E4ndQ2--8ew@mail.gmail.com  

commit   : 08ca9d7feca890e97f77ef1fde02d7542a54ac5e    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 13 May 2019 15:39:06 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 13 May 2019 15:39:06 -0700    

An upcoming HEAD-only patch will standardize the terminology around  
ItemIdData variables/line pointers, ending the practice of referring to  
them as "item pointers".  Make the "Database Page Layout" docs  
consistent with the new policy.  The term "item identifier" is already  
used in the same section, so stick with that.  
  
Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=E4ndQ2--8ew@mail.gmail.com  
Backpatch: All supported branches.  

commit   : 32ebb35128c3d16b64039f6d6774afd96a3d91b9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 May 2019 17:23:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 May 2019 17:23:00 -0400    

Only hand-assigned type OIDs should be presumed to match across different  
PG servers; those assigned during genbki.pl or during initdb are likely  
to change due to addition or removal of unrelated objects.  
  
This means that the cutoff should be FirstGenbkiObjectId (in HEAD)  
or FirstBootstrapObjectId (before that), not FirstNormalObjectId.  
Compare postgres_fdw's is_builtin() test.  
  
It's likely that this error has no observable consequence in a  
normally-functioning system, since ATM the only affected type OIDs are  
system catalog rowtypes and information_schema types, which would not  
typically be interesting for logical replication.  But you could  
probably break it if you tried hard, so back-patch.  
  
Discussion: https://postgr.es/m/15150.1557257111@sss.pgh.pa.us  

commit   : e34ee993fbc38c8538f9342c5961e5f61fd45180    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 May 2019 17:05:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 May 2019 17:05:48 -0400    

The FirstNormalObjectId test here is a kluge that needs to go away,  
but the only substitute we can think of is to add a column to pg_class,  
which will take more work than can be handled right now.  Add some  
commentary in the meanwhile.  
  
Discussion: https://postgr.es/m/15150.1557257111@sss.pgh.pa.us  

commit   : 9b42e713761a43e9ade3965285f077e2ba25bbb7    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 13 May 2019 10:27:59 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 13 May 2019 10:27:59 -0700    

Commit 8fa30f906be reduced the elevel of a number of "can't happen"  
_bt_split() errors from PANIC to ERROR.  At the same time, the new right  
page buffer for the split could continue to be acquired well before the  
critical section.  This was possible because it was relatively  
straightforward to make sure that _bt_split() could not throw an error,  
with a few specific exceptions.  The exceptional cases were safe because  
they involved specific, well understood errors, making it possible to  
consistently zero the right page before actually raising an error using  
elog().  There was no danger of leaving around a junk page, provided  
_bt_split() stuck to this coding rule.  
  
Commit 8224de4f, which introduced INCLUDE indexes, added code to make  
_bt_split() truncate away non-key attributes.  This happened at a point  
that broke the rule around zeroing the right page in _bt_split().  If  
truncation failed (perhaps due to palloc() failure), that would result  
in an errant right page buffer with junk contents.  This could confuse  
VACUUM when it attempted to delete the page, and should be avoided on  
general principle.  
  
To fix, reorganize _bt_split() so that truncation occurs before the new  
right page buffer is even acquired.  A junk page/buffer will not be left  
behind if _bt_nonkey_truncate()/_bt_truncate() raise an error.  
  
Discussion: https://postgr.es/m/CAH2-WzkcWT_-NH7EeL=Az4efg0KCV+wArygW8zKB=+HoP=VWMw@mail.gmail.com  
Backpatch: 11-, where INCLUDE indexes were introduced.  

commit   : 221b377f09a30dd7c74c26c8c1db439afcc59141    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 13 May 2019 13:13:24 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 13 May 2019 13:13:24 -0400    

The comment implies that a 1 in the null bitmap indicates a null value,  
but actually a 0 in the null bitmap indicates a null value. Try to  
be more clear.  
  
Patch by me; proposed wording reviewed by Alvaro Herrera and Tom Lane.  
  
Discussion: http://postgr.es/m/CA+TgmobHOP8r6cG+UnsDFMrS30-m=jRrCBhgw-nFkn0k9QnFsg@mail.gmail.com  

commit   : ddf927fb13471bec0cc76794eaf552df8a1178fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 May 2019 10:53:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 May 2019 10:53:19 -0400    

pgtls_read_pending is declared to return bool, but what the underlying  
SSL_pending function returns is a count of available bytes.  
  
This is actually somewhat harmless if we're using C99 bools, but in  
the back branches it's a live bug: if the available-bytes count happened  
to be a multiple of 256, it would get converted to a zero char value.  
On machines where char is signed, counts of 128 and up could misbehave  
as well.  The net effect is that when using SSL, libpq might block  
waiting for data even though some has already been received.  
  
Broken by careless refactoring in commit 4e86f1b16, so back-patch  
to 9.5 where that came in.  
  
Per bug #15802 from David Binderman.  
  
Discussion: https://postgr.es/m/15802-f0911a97f0346526@postgresql.org  

commit   : cc866941ad4583f07e5637c145f6f6ee8a573e11    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 13 May 2019 17:30:35 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 13 May 2019 17:30:35 +0900    

commit   : f86b0c3c465319b80d71db7d7a9de636950e104a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 12 May 2019 23:54:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 12 May 2019 23:54:02 -0400    

Reported-by: David Rowley  
  
Discussion: https://postgr.es/m/CAKJS1f-ktEhmQ2zJQ1L1niuJ9KB8WPA-bE-AhGiFsSO6QASB_w@mail.gmail.com  

commit   : a6927996be59ac329d65d41cf058d0b1b0978eeb    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 12 May 2019 23:41:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 12 May 2019 23:41:53 -0400    

Tighten section designations.  

commit   : fefb6a75386b72a40f697523953eafc7cb1c7a5b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 12 May 2019 23:24:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 12 May 2019 23:24:43 -0400    

commit   : 1171dbde2daef8f0dcd1dc1e54531a0d8dd34d88    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 May 2019 09:11:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 May 2019 09:11:50 +0900    

equalsJsonbScalarValue() uses a boolean as return type, however for one  
code path -1 gets returned, which is confusing.  The origin of the  
confusion is visibly that this code got copy-pasted from  
compareJsonbScalarValue() since it has been introduced in d1d50bf.  
  
No backpatch, as this is only cosmetic.  
  
Author: Rikard Falkeborn  
Discussion: https://postgr.es/m/CADRDgG7mJnek6HNW13f+LF6V=6gag9PM+P7H5dnyWZAv49aBGg@mail.gmail.com  

commit   : 8a29ed05302ea18b4be177c2d1181b43706af45f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 May 2019 18:53:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 May 2019 18:53:12 -0400    

A bounded quantifier with m = n = 1 might be thought a no-op.  But  
according to our documentation (which traces back to Henry Spencer's  
original man page) it still imposes greediness, or non-greediness in the  
case of the non-greedy variant "{1,1}?", on whatever it's attached to.  
  
This turns out not to work though, because parseqatom() optimizes away  
the m = n = 1 case without regard for whether it's supposed to change  
the greediness of the argument RE.  
  
We can fix this by just not applying the optimization when the greediness  
needs to change; the subsequent general cases handle it fine.  
  
The three cases in which we can still apply the optimization are  
(a) no quantifier, or quantifier does not impose a preference;  
(b) atom has no greediness property, implying it cannot match a  
variable amount of text anyway; or  
(c) quantifier's greediness is same as atom's.  
Note that in most cases where one of these applies, we'd have exited  
earlier in the "not a messy case" fast path.  I think it's now only  
possible to get to the optimization when the atom involves capturing  
parentheses or a non-top-level backref.  
  
Back-patch to all supported branches.  I'd ordinarily be hesitant to  
put a subtle behavioral change into back branches, but in this case  
it's very hard to see a reason why somebody would write "{1,1}?" unless  
they're trying to get the documented change-of-greediness behavior.  
  
Discussion: https://postgr.es/m/5bb27a41-350d-37bf-901e-9d26f5592dd0@charter.net  

commit   : d02768ddd1791bab742cf131de726d0a36b3f337    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 12 May 2019 10:33:05 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 12 May 2019 10:33:05 -0700    

The function had been interpreting SQL_ASCII messages as UTF8, throwing  
an error when they were invalid UTF8.  The new behavior is consistent  
with pg_do_encoding_conversion().  This affects LOG_DESTINATION_STDERR  
and LOG_DESTINATION_EVENTLOG, which will send untranslated bytes to  
write() and ReportEventA().  On buildfarm member bowerbird, enabling  
log_connections caused an error whenever the role name was not valid  
UTF8.  Back-patch to 9.4 (all supported versions).  
  
Discussion: https://postgr.es/m/20190512015615.GD1124997@rfd.leadboat.com  

commit   : 85ccb6899c6c8639bb3e5962ea3bcce5d886e613    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 May 2019 21:27:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 May 2019 21:27:13 -0400    

We long ago decided to design the shared PgBackendStatus data structure to  
minimize the cost of writing status updates, which means that writers just  
have to increment the st_changecount field twice.  That isn't hooked into  
any sort of resource management mechanism, which means that if something  
were to throw error between the two increments, the st_changecount field  
would be left odd indefinitely.  That would cause readers to lock up.  
Now, since it's also a bad idea to leave the field odd for longer than  
absolutely necessary (because readers will spin while we have it set),  
the expectation was that we'd treat these segments like spinlock critical  
sections, with only short, more or less straight-line, code in them.  
  
That was fine as originally designed, but commit 9029f4b37 broke it  
by inserting a significant amount of non-straight-line code into  
pgstat_bestart(), code that is very capable of throwing errors, not to  
mention taking a significant amount of time during which readers will spin.  
We have a report from Neeraj Kumar of readers actually locking up, which  
I suspect was due to an encoding conversion error in X509_NAME_to_cstring,  
though conceivably it was just a garden-variety OOM failure.  
  
Subsequent commits have loaded even more dubious code into pgstat_bestart's  
critical section (and commit fc70a4b0d deserves some kind of booby prize  
for managing to miss the critical section entirely, although the negative  
consequences seem minimal given that the PgBackendStatus entry should be  
seen by readers as inactive at that point).  
  
The right way to fix this mess seems to be to compute all these values  
into a local copy of the process' PgBackendStatus struct, and then just  
copy the data back within the critical section proper.  This plan can't  
be implemented completely cleanly because of the struct's heavy reliance  
on out-of-line strings, which we must initialize separately within the  
critical section.  But still, the critical section is far smaller and  
safer than it was before.  
  
In hopes of forestalling future errors of the same ilk, rename the  
macros for st_changecount management to make it more apparent that  
the writer-side macros create a critical section.  And to prevent  
the worst consequences if we nonetheless manage to mess it up anyway,  
adjust those macros so that they really are a critical section, ie  
they now bump CritSectionCount.  That doesn't add much overhead, and  
it guarantees that if we do somehow throw an error while the counter  
is odd, it will lead to PANIC and a database restart to reset shared  
memory.  
  
Back-patch to 9.5 where the problem was introduced.  
  
In HEAD, also fix an oversight in commit b0b39f72b: it failed to teach  
pgstat_read_current_status to copy st_gssstatus data from shared memory to  
local memory.  Hence, subsequent use of that data within the transaction  
would potentially see changing data that it shouldn't see.  
  
Discussion: https://postgr.es/m/CAPR3Wj5Z17=+eeyrn_ZDG3NQGYgMEOY6JV6Y-WRRhGgwc16U3Q@mail.gmail.com  

commit   : 4217d15d91128355ea13e6fb9c031b826e2a1335    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 11 May 2019 18:24:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 11 May 2019 18:24:31 -0400    

I already added that to the incompatibility section as a separate item.  
  
Reported-by: Peter Geoghegan  

commit   : 31f11f964734dbe2af2915182bf79f69e337d4d7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 11 May 2019 17:59:58 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 11 May 2019 17:59:58 -0400    

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

commit   : d56fd6357a5e0e76fecf20c3dc762c5301290331    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 11 May 2019 16:42:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 11 May 2019 16:42:05 -0400    

This is because of the new tid in the index entry.  
  
Reported-by: Peter Geoghegan  

commit   : 1708974485e82e1cf4694c683faa70fc5bcf142c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 11 May 2019 16:17:18 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 11 May 2019 16:17:18 -0400    

commit   : 0edc8fc47bc4482ceac85b09575d6372dbbc0bbf    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 11 May 2019 10:29:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 11 May 2019 10:29:30 -0400    

Reported-by: Andrew Gierth  
  
Discussion: https://postgr.es/m/87r295hjur.fsf@news-spur.riddles.org.uk  

commit   : 54c2ecb56707ed00844b8678a79570dd34cb95a3    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 11 May 2019 00:22:38 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 11 May 2019 00:22:38 -0700    

The buildfarm client uses TEMP_CONFIG to implement its extra_config  
setting.  Except for stats_temp_directory, extra_config now applies to  
TAP suites; extra_config values seen in the past month are compatible  
with this.  Back-patch to 9.6, where PostgresNode was introduced, so the  
buildfarm can rely on it sooner.  
  
Reviewed by Andrew Dunstan and Tom Lane.  
  
Discussion: https://postgr.es/m/20181229021950.GA3302966@rfd.leadboat.com  

commit   : e51bad8fb4c3f0ad5cb173034afdc0b349c7e488    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 11 May 2019 13:00:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 11 May 2019 13:00:54 +0900    

When failing to reindex a table or an index, reindexdb would generate an  
extra error message related to a database failure, which is misleading.  
  
Backpatch all the way down, as this has been introduced by 85e9a5a0.  
  
Discussion: https://postgr.es/m/CAOBaU_Yo61RwNO3cW6WVYWwH7EYMPuexhKqufb2nFGOdunbcHw@mail.gmail.com  
Author: Julien Rouhaud  
Reviewed-by: Daniel Gustafsson, Álvaro Herrera, Tom Lane, Michael  
Paquier  
Backpatch-through: 9.4  

commit   : b721e201a0bcf0f9e1795c295e134e47d698e80c    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sat, 11 May 2019 03:23:55 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sat, 11 May 2019 03:23:55 +0100    

My fault; the error was introduced in the Ryu patch.  

commit   : 064df0edfee91d3843d54d1f67c05a4634690a12    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 10 May 2019 22:11:13 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 10 May 2019 22:11:13 -0400    

Reported-by: Peter Geoghegan  
  
Discussion: https://postgr.es/m/CAH2-WzkrX-aA7d3OYtQT+8Mspq+tU5vwuVz=FTzMH3CdrSyprA@mail.gmail.com  

commit   : 13d258ec0e55ebc4378e848934f0f4c0ffac0a6f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 10 May 2019 21:22:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 10 May 2019 21:22:53 -0400    

Reported-by: Amit Langote  
  
Discussion: https://postgr.es/m/5936b052-5d92-a2c9-75d2-0245fb2330b5@lab.ntt.co.jp  

commit   : 05f9eba3498f4dbc8687f66eff53a2bfb88f2595    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 10 May 2019 21:16:33 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 10 May 2019 21:16:33 -0400    

Reported-by: Alexander Korotkov  
  
Discussion: https://postgr.es/m/CAPpHfdvkM-PkyrK6LQitJUDmC_1kOCEtTuseoVhCT=ew0XJmGg@mail.gmail.com  

commit   : 8aa1b0885e3d248dbf3e0b0c544125d13dbc36d0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 10 May 2019 21:06:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 10 May 2019 21:06:38 -0400    

Reported-by: David Rowley  
  
Discussion: https://postgr.es/m/CAKJS1f-NDmeA_tb0oRFhrgf19xq3A9MeoyMcckY04Ct=_i0c2A@mail.gmail.com  

commit   : 809e248299894b02e8f4eb3ee17829b2ae14ce9d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 10 May 2019 21:03:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 10 May 2019 21:03:31 -0400    

Reported-by: Peter Geoghegan  
  
Discussion: https://postgr.es/m/CAH2-WzkSYOM1GJVGtAbRW-OqymoCD=QWYG6ro+GaoOW-jPRuDQ@mail.gmail.com  

commit   : b299efaea433a7d2c04ce124e4f6588807bbe87a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 10 May 2019 20:25:52 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 10 May 2019 20:25:52 -0400    

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

commit   : 5997a8f4d7478ae6bac4dab12ca1f883e41a7aa1    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 5 May 2019 23:31:58 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 5 May 2019 23:31:58 -0700    

As none of the approaches for avoiding the deadlock issues seem  
promising enough, and all the expected reindex related changes have  
been made, apply 60c2951e1bab7e to master as well.  
  
Discussion: https://postgr.es/m/4622.1556982247@sss.pgh.pa.us  

commit   : 610747d86e46ae6e94b7288393d08823cc39b498    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 May 2019 14:56:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 May 2019 14:56:41 -0400    

There's a very old race condition in our code to see whether a pre-existing  
shared memory segment is still in use by a conflicting postmaster: it's  
possible for the other postmaster to remove the segment in between our  
shmctl() and shmat() calls.  It's a narrow window, and there's no risk  
unless both postmasters are using the same port number, but that's possible  
during parallelized "make check" tests.  (Note that while the TAP tests  
take some pains to choose a randomized port number, pg_regress doesn't.)  
If it does happen, we treated that as an unexpected case and errored out.  
  
To fix, allow EINVAL to be treated as segment-not-present, and the same  
for EIDRM on Linux.  AFAICS, the considerations here are basically  
identical to the checks for acceptable shmctl() failures, so I documented  
and coded it that way.  
  
While at it, adjust PGSharedMemoryAttach's API to remove its undocumented  
dependency on UsedShmemSegAddr in favor of passing the attach address  
explicitly.  This makes it easier to be sure we're using a null shmaddr  
when probing for segment conflicts (thus avoiding questions about what  
EINVAL means).  I don't think there was a bug there, but it required  
fragile assumptions about the state of UsedShmemSegAddr during  
PGSharedMemoryIsInUse.  
  
Commit c09850992 may have made this failure more probable by applying  
the conflicting-segment tests more often.  Hence, back-patch to all  
supported branches, as that was.  
  
Discussion: https://postgr.es/m/22224.1557340366@sss.pgh.pa.us  

commit   : c65bcfe9aeecae1c6204ad60612fae43669a88b0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 May 2019 23:26:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 May 2019 23:26:48 -0400    

I will add links to other parts of the docs later.  

commit   : d0bbf871ca243eafcac7a84138741521c1aea3d2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 May 2019 20:58:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 May 2019 20:58:02 -0400    

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

commit   : 752f06443fba7e906cd98987f247297663f19a16    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 May 2019 09:35:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 May 2019 09:35:27 +0900    

The description of the lock type for speculative insertions was  
incorrect, being copy-pasted from another one.  
  
As discussed, also move the description for all the fields of lock tag  
types from the structure listing lock tag types to the set of macros  
setting each LOCKTAG.  
  
Author: John Naylor  
Discussion: https://postgr.es/m/CACPNZCtA0-ybaC4fFfaDq_8p_TUOLvGxZH9Dm-=TMHZJarBa7Q@mail.gmail.com  

commit   : 97b1654da7dd38fa50c9b6139f4213a1c47f0c39    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 May 2019 20:32:35 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 May 2019 20:32:35 -0400    

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

commit   : 32fe7ee2dd2b2aa8620e69451f60b2b35989677c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 May 2019 20:10:17 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 May 2019 20:10:17 -0400    

Reported-by: Thomas Munro  
  
Discussion: https://postgr.es/m/CA+hUKGJpep8uSXoDtVF6iROCRKce-39HEhDPUaYFyMn0U5e9ug@mail.gmail.com  

commit   : 79697d039f567cd52d844077244fb85df10dce19    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 May 2019 19:59:59 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 May 2019 19:59:59 -0400    

This adds two more items that should have been included in the  
beginning.  
  
Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20190508203204.GA25482@telsasoft.com  

commit   : 81ddfa2e4d9350eb68f28cde8ae6a7e0b39ef2ac    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 May 2019 19:27:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 May 2019 19:27:03 -0400    

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

commit   : 508300e2e141a9fd87758ce01374c5b0597986fd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 May 2019 08:18:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 May 2019 08:18:46 +0900    

This improves the user experience when it comes to restrict several  
flavors of REINDEX CONCURRENTLY.  First, for INDEX, remove a restriction  
on shared relations as we already check after catalog relations.  Then,  
for TABLE, add a proper error message when attempting to run the command  
on system catalogs.  The code path of CREATE INDEX CONCURRENTLY already  
complains about that, but if a REINDEX is issued then then the error  
generated is confusing.  
  
While on it, add more tests to check restrictions on catalog indexes and  
on toast table/index for catalogs.  Some error messages are improved,  
with wording suggestion coming from Tom Lane.  
  
Reported-by: Tom Lane  
Author: Michael Paquier  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/23694.1556806002@sss.pgh.pa.us  

commit   : 24c19e9f66863d83009a370604e40b1eaa71bcdd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 May 2019 16:52:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 May 2019 16:52:48 -0400    

create_merge_append_plan failed to honor the CP_EXACT_TLIST flag:  
it would generate the expected targetlist but then it felt free to  
add resjunk sort targets to it.  This demonstrably leads to assertion  
failures in v11 and HEAD, and it's probably just accidental that we  
don't see the same in older branches.  I've not looked into whether  
there would be any real-world consequences in non-assert builds.  
In HEAD, create_append_plan has sprouted the same problem, so fix  
that too (although we do not have any test cases that seem able to  
reach that bug).  This is an oversight in commit 3fc6e2d7f which  
invented the CP_EXACT_TLIST flag, so back-patch to 9.6 where that  
came in.  
  
convert_subquery_pathkeys would create pathkeys for subquery output  
values if they match any EquivalenceClass known in the outer query  
and are available in the subquery's syntactic targetlist.  However,  
the second part of that condition is wrong, because such values might  
not appear in the subquery relation's reltarget list, which would  
mean that they couldn't be accessed above the level of the subquery  
scan.  We must check that they appear in the reltarget list, instead.  
This can lead to dropping knowledge about the subquery's sort  
ordering, but I believe it's okay, because any sort key that the  
outer query actually has any interest in would appear in the  
reltarget list.  
  
This second issue is of very long standing, but right now there's no  
evidence that it causes observable problems before 9.6, so I refrained  
from back-patching further than that.  We can revisit that choice if  
somebody finds a way to make it cause problems in older branches.  
(Developing useful test cases for these issues is really problematic;  
fixing convert_subquery_pathkeys removes the only known way to exhibit  
the create_merge_append_plan bug, and neither of the test cases added  
by this patch causes a problem in all branches, even when considering  
the issues separately.)  
  
The second issue explains bug #15795 from Suresh Kumar R ("could not  
find pathkey item to sort" with nested DISTINCT queries).  I stumbled  
across the first issue while investigating that.  
  
Discussion: https://postgr.es/m/15795-fadb56c8e44ee73c@postgresql.org  

commit   : 64084d6857b1d8ac05ae46f658b6c244aa6ab591    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 May 2019 16:44:27 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 9 May 2019 16:44:27 -0400    

Adjustments requested by reviewers.  
  
Reported-by: Amit Kapila, Thomas Munro, Andrew Gierth, Amit Langote, Oleg Bartunov, Michael Paquier, Alvaro Herrera, Tatsuo Ishii  
  
Discussion: https://postgr.es/m/20190506233029.ozwged67i7s4qd6c@momjian.us  

commit   : a0be05bab062eff16eafce3df73b3df453a694f4    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 9 May 2019 19:50:15 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 9 May 2019 19:50:15 +0900    

In commit d50d172e51, which added support for LIMIT/OFFSET pushdown in  
postgres_fdw, a new struct was introduced as the extra parameter of  
GetForeignUpperPaths() set for UPPERREL_FINAL, but I forgot to update  
the documentation to mention that.  
  
Author: Etsuro Fujita  
Discussion: https://postgr.es/m/CAPmGK17uSXQDe31oRb-z1nYyT6vVzkstZkA3_Wbq38U92b9BmQ%40mail.gmail.com  

commit   : edbcbe277d795ecc339b0e4fa29bae42ce1a7be9    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 9 May 2019 18:39:23 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 9 May 2019 18:39:23 +0900    

In commit 7012b132d0, which added support for aggregate pushdown in  
postgres_fdw, the expense of evaluating the final scan/join target  
computed by make_group_input_target() was not accounted for at all in  
costing aggregate pushdown paths with local statistics.  The right fix  
for this would be to have a separate upper stage to adjust the final  
scan/join relation (see comments for apply_scanjoin_target_to_paths());  
but for now, fix by adding the tlist eval cost when costing aggregate  
pushdown paths with local statistics.  
  
Apply this to HEAD only to avoid destabilizing existing plan choices.  
  
Author: Etsuro Fujita  
Reviewed-By: Antonin Houska  
Discussion: https://postgr.es/m/5C66A056.60007%40lab.ntt.co.jp  

commit   : 47a338cfcd67139a1f91892b080934fcfc3aea03    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 9 May 2019 19:11:46 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 9 May 2019 19:11:46 +1200    

Commit bb16aba50 broke the code that maintains SxactGlobalXmin.  It  
could get stuck when a well-timed READ ONLY transaction runs.  If  
SxactGlobalXmin stops advancing, transactions on the  
FinishedSerializableTransactions queue are never cleaned up, so  
resources are effectively leaked.  Revert that hunk of the commit.  
  
Also revert another similar hunk that was probably harmless, but  
unnecessary and unjustified, relating to the DOOMED flag in case of  
RO_SAFE early release.  
  
Author: Thomas Munro  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/16170.1557251214%40sss.pgh.pa.us  

commit   : cd805f46d857291b26ba6eb491ce11b6e0fc9ad3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 May 2019 09:15:59 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 May 2019 09:15:59 +0200    

So it picks up strings in pg_log_* calls.  This was forgotten when it  
was added to all other relevant subdirectories.  

commit   : 02daece4ab4cd85b80d04469056e5b631918c9d6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 May 2019 09:14:37 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 May 2019 09:14:37 +0200    

commit   : 2d7d946cd323ce1c1d3f3ef0e5f2f41591afc1b9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 May 2019 23:27:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 May 2019 23:27:29 -0400    

The right way for IsCatalogRelation/Class to behave is to return true  
for OIDs less than FirstBootstrapObjectId (not FirstNormalObjectId),  
without any of the ad-hoc fooling around with schema membership.  
  
The previous code was wrong because (1) it claimed that  
information_schema tables were not catalog relations but their toast  
tables were, which is silly; and (2) if you dropped and recreated  
information_schema, which is a supported operation, the behavior  
changed.  That's even sillier.  With this definition, "catalog  
relations" are exactly the ones traceable to the postgres.bki data,  
which seems like what we want.  
  
With this simplification, we don't actually need access to the pg_class  
tuple to identify a catalog relation; we only need its OID.  Hence,  
replace IsCatalogClass with "IsCatalogRelationOid(oid)".  But keep  
IsCatalogRelation as a convenience function.  
  
This allows fixing some arguably-wrong semantics in contrib/sepgsql and  
ReindexRelationConcurrently, which were using an IsSystemNamespace test  
where what they really should be using is IsCatalogRelationOid.  The  
previous coding failed to protect toast tables of system catalogs, and  
also was not on board with the general principle that user-created tables  
do not become catalogs just by virtue of being renamed into pg_catalog.  
We can also get rid of a messy hack in ReindexMultipleTables.  
  
While we're at it, also rename IsSystemNamespace to IsCatalogNamespace,  
because the previous name invited confusion with the more expansive  
semantics used by IsSystemRelation/Class.  
  
Also improve the comments in catalog.c.  
  
There are a few remaining places in replication-related code that are  
special-casing OIDs below FirstNormalObjectId.  I'm inclined to think  
those are wrong too, and if there should be any special case it should  
just extend to FirstBootstrapObjectId.  But first we need to debate  
whether a FOR ALL TABLES publication should include information_schema.  
  
Discussion: https://postgr.es/m/21697.1557092753@sss.pgh.pa.us  
Discussion: https://postgr.es/m/15150.1557257111@sss.pgh.pa.us  

commit   : 3ae3c18b362817f9412c380539f1a16c7abb79c9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 9 May 2019 10:29:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 9 May 2019 10:29:10 +0900    

When running a batch of VACUUM or ANALYZE commands on a given database,  
there were cases where it is possible to have vacuumdb not report an  
error where it actually should, leading to incorrect status results.  
  
Author: Julien Rouhaud  
Reviewed-by: Amit Kapila, Michael Paquier  
Discussion: https://postgr.es/m/CAOBaU_ZuTwz7CtqLYJ1Ouuh272bTQPLN8b1bAPk0bCBm4PDMTQ@mail.gmail.com  
Backpatch-through: 9.5  

commit   : d95e36dc384e3068ae2db909c228b1800737b18d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 8 May 2019 12:47:20 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 8 May 2019 12:47:20 -0700    

Commit dd299df8189, which added suffix truncation to nbtree, simplified  
the WAL record format used by page splits.  It became necessary to  
explicitly WAL-log the new high key for the left half of a split in all  
cases, which relieved the REDO routine from having to reconstruct a new  
high key for the left page by copying the first item from the right  
page.  Remove a comment that referred to the previous practice.  

commit   : 61639816b870347677e6e6945604e0d9da1837ca    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 8 May 2019 13:16:54 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 8 May 2019 13:16:54 -0400    

Some messages related to foreign servers were reporting the server name  
without quotes, or not at all; our style is to have all names be quoted,  
and the server name already appears quoted in a few other messages, so  
just add quotes and make them all consistent.  
  
Remove an extra "s" in other messages (typos introduced by myself in  
f56f8f8da6af).  

commit   : df631ebc737e9d9cdf8d0691969d404f1bd584a4    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 May 2019 01:35:13 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 May 2019 01:35:13 +0900    

Previously it's documented that use of replication functions is  
restricted to superusers. This is true for the functions which  
use replication origin, but not for pg_logicl_emit_message() and  
functions which use replication slot. For example, not only  
superusers but also users with REPLICATION privilege is allowed  
to use the functions for replication slot. This commit fixes  
the documentation for the privileges required for those replication  
functions.  
  
Back-patch to 9.4 (all supported versions).  
  
Author: Matsumura Ryo  
Discussion: https://postgr.es/m/03040DFF97E6E54E88D3BFEE5F5480F74ABA6E16@G01JPEXMBYT04  

commit   : add85ead4ab969c1e31d64f4476c2335856f4aa9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 May 2019 14:15:01 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 May 2019 14:15:01 +0200    

REINDEX CONCURRENTLY locks tables with ShareUpdateExclusiveLock rather  
than the ShareLock used by a plain REINDEX.  However,  
RangeVarCallbackForReindexIndex() was not updated for that and still  
used the ShareLock only.  This would lead to lock upgrades later,  
leading to possible deadlocks.  
  
Reported-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/20190430151735.wi52sxjvxsjvaxxt%40alap3.anarazel.de  

commit   : 8efe710d9c84502b3e6a9487937bccf881f56d9c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 6 May 2019 15:02:41 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 6 May 2019 15:02:41 +1200    

Commit c0985099, later adjusted by commit 4ab02e81, probed 0.0.0.0  
in addition to 127.0.0.1, for the benefit of Windows build farm  
animals.  It isn't really useful on Unix systems, and turned out to  
be a bit inconvenient to users of some corporate firewall software.  
Switch back to probing just 127.0.0.1 on non-Windows systems.  
  
Back-patch to 9.6, like the earlier changes.  
  
Discussion: https://postgr.es/m/CA%2BhUKG%2B21EPwfgs4m%2BtqyRtbVqkOUvP8QQ8sWk9%2Bh55Aub1H3A%40mail.gmail.com  

commit   : 098344be663f5fc0ad166e7a9e1cd37721ee34d9    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 8 May 2019 21:14:14 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 8 May 2019 21:14:14 +1200    

Reported-by: Vik Fearing  

commit   : b7434dc007252d7a5e5f7f85700bd7400b1db201    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 8 May 2019 16:49:09 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 8 May 2019 16:49:09 +0900    

commit   : 256be1050cbbf90b1e44d11c8ed10f98255aa27d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 May 2019 09:32:34 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 May 2019 09:32:34 +0300    

The flat file mechanism was removed in PostgreSQL 9.0.  

commit   : d65b5ccad626e1942c862e8a70f56ad7ee7a8003    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 7 May 2019 21:42:12 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 7 May 2019 21:42:12 -0700    

It is no longer possible under any circumstances for nbtree code to  
reconstruct a strict lower bound key (parent page's pivot tuple key) for  
a right sibling page by retrieving the first item in the right sibling  
page.  

commit   : e5f978631722bb3cac42f0eb6e65e947e0f088ec    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 8 May 2019 01:55:31 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 8 May 2019 01:55:31 +0300    

Reported-by: Tom Lane  
Discussion: https://postgr.es/m/14305.1557268259%40sss.pgh.pa.us  

commit   : 53ae0b16d6f60a15427e081091b2b81e36e674ee    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 30 Apr 2019 01:12:05 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 30 Apr 2019 01:12:05 +0300    

Word "singleton" is hard for user understanding, especially taking into account  
there is only one place it's used in the docs and there is even no definition.  
Use more evident wording instead.  
  
Discussion: https://postgr.es/m/23737.1556550645%40sss.pgh.pa.us  

commit   : 29ceacc3f93720d3ebb7e7e999f8b7fe9622389c    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 23 Apr 2019 17:43:09 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 23 Apr 2019 17:43:09 +0300    

This commit contains multiple improvements to error reporting in jsonpath  
including but not limited to getting rid of following things:  
  
 * definition of error messages in macros,  
 * errdetail() when valueable information could fit to errmsg(),  
 * word "singleton" which is not properly explained anywhere,  
 * line breaks in error messages.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/14890.1555523005%40sss.pgh.pa.us  
Author: Alexander Korotkov  
Reviewed-by: Tom Lane  

commit   : b84dbc8eb80b43e554891c459a19969d9fbdefe5    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 May 2019 02:10:33 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 May 2019 02:10:33 +0900    

This commit adds new parameter to VACUUM command, TRUNCATE,  
which specifies that VACUUM should attempt to truncate off  
any empty pages at the end of the table and allow the disk space  
for the truncated pages to be returned to the operating system.  
  
This parameter, if specified, overrides the vacuum_truncate  
reloption. If neither the reloption nor the VACUUM option is  
used, the default is true, as before.  
  
Author: Fujii Masao  
Reviewed-by: Julien Rouhaud, Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoD+qtrSDL=GSma4Wd3kLYLeRC0hPna-YAdkDeV4z156vg@mail.gmail.com  

commit   : 98719af6c2e30d538cd05cfe044f58ba4067b52b    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 7 May 2019 18:26:09 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 7 May 2019 18:26:09 +0200    

Author: Daniel Gustafsson <daniel@yesql.se>  

commit   : 8d0ddccec6366a2851da7d350b33659203aa644b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 May 2019 11:41:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 May 2019 11:41:37 -0400    

On a 64-bit machine, if you set track_activity_query_size and  
max_connections such that their product exceeds 1GB, shared memory  
setup will still succeed (given enough RAM), but attempts to read  
pg_stat_activity fail with "invalid memory alloc request size".  
Work around that by using MemoryContextAllocHuge to allocate the  
local copy of the activity strings.  Using the "huge" API costs us  
nothing extra in normal cases, and it seems better than throwing  
an error and/or explaining to people why they can't do this.  
  
This situation seems insanely profligate today, but who knows what  
people will consider normal in ten or twenty years?  So let's fix it  
in HEAD but not worry about a back-patch.  
  
Per report from James Tomson.  
  
Discussion: https://postgr.es/m/1CFDCCD6-B268-48D8-85C8-400D2790B2C3@pushd.com  

commit   : b753bc0c84e51c200ec7de6cefb6f689d13fef62    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 7 May 2019 15:29:39 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 7 May 2019 15:29:39 +0200    

The SQL keywords table in the documentation had until now been  
generated by some ad hoc scripting outside the source tree once for  
each major release.  This changes it to an automated process.  
  
We have the PostgreSQL keywords available in a parseable format in  
parser/kwlist.h.  For the relevant SQL standard versions, keep the  
keyword lists in new text files.  A new script  
generate-keywords-table.pl pulls it all together and produces a  
DocBook table.  
  
The final output in the documentation should be identical after this  
change.  
  
Discussion: https://www.postgresql.org/message-id/flat/07daeadd-8c82-0d95-5e19-e350502cb749%402ndquadrant.com  

commit   : 7db0cde6b58eef2ba0c70437324cbc7622230320    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 7 May 2019 09:30:24 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 7 May 2019 09:30:24 +0530    

This feature was using a process local map to track the first few blocks  
in the relation.  The map was reset each time we get the block with enough  
freespace.  It was discussed that it would be better to track this map on  
a per-relation basis in relcache and then invalidate the same whenever  
vacuum frees up some space in the page or when FSM is created.  The new  
design would be better both in terms of API design and performance.  
  
List of commits reverted, in reverse chronological order:  
  
06c8a5090e  Improve code comments in b0eaa4c51b.  
13e8643bfc  During pg_upgrade, conditionally skip transfer of FSMs.  
6f918159a9  Add more tests for FSM.  
9c32e4c350  Clear the local map when not used.  
29d108cdec  Update the documentation for FSM behavior..  
08ecdfe7e5  Make FSM test portable.  
b0eaa4c51b  Avoid creation of the free space map for small heap relations.  
  
Discussion: https://postgr.es/m/20190416180452.3pm6uegx54iitbt5@alap3.anarazel.de  

commit   : af82f95abb23a56d18fd009ef9eca68ef803a041    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 7 May 2019 09:39:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 7 May 2019 09:39:39 +0900    

This code was broken as of 582edc3, and is most likely not used anymore.  
Note that pg_dump supports servers down to 8.0, and psql has code to  
support servers down to 7.4.  
  
Author: Julien Rouhaud  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/CAOBaU_Y5y=zo3+2gf+2NJC1pvMYPcbRXoQaPXx=U7+C8Qh4CzQ@mail.gmail.com  

commit   : bdf595adbca195fa54a909c74a5233ebc30641a1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 6 May 2019 19:02:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 6 May 2019 19:02:34 -0400    

Still needs text markup, links, word wrap, and indenting.  

commit   : a1ec7402e9a0392f95bc79542af0efcd5c6e7929    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 6 May 2019 12:23:49 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 6 May 2019 12:23:49 -0400    

... and fallout (from branches 10, 11 and master).  The change was  
ill-considered, and it broke a few normal use cases; since we don't have  
time to fix it, we'll try again after this week's minor releases.  
  
Reported-by: Rushabh Lathia  
Discussion: https://postgr.es/m/CAGPqQf0iQV=PPOv2Btog9J9AwOQp6HmuVd6SbGTR_v3Zp2XT1w@mail.gmail.com  

commit   : 91248608a61d5504f8ac46534136de9b3717fed2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 May 2019 21:44:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 May 2019 21:44:24 +0900    

This adds extra tests for the error message generated for partition  
tuple routing in the executor, using more than three levels of  
partitioning including partitioned tables with no partitions.  These  
tests have been added to fix CVE-2019-10129 on REL_11_STABLE.  HEAD has  
no active bugs in this area, but it lacked coverage.  
  
Author: Michael Paquier  
Reviewed-by: Noah Misch  
Security: CVE-2019-10129  

commit   : a0905056fd6b0927dd33f185adc9e7503515fc0d    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 6 May 2019 11:54:32 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 6 May 2019 11:54:32 +0100    

In examine_variable() and examine_simple_variable(), when checking the  
user's table and column privileges to determine whether to grant  
access to the pg_statistic data, use checkAsUser for the privilege  
checks, if it's set. This will be the case if we're accessing the  
table via a view, to indicate that we should perform privilege checks  
as the view owner rather than the current user.  
  
This change makes this planner check consistent with the check in the  
executor, so the planner will be able to make use of statistics if the  
table is accessible via the view. This fixes a performance regression  
introduced by commit e2d4ef8de8, which affects queries against  
non-security barrier views in the case where the user doesn't have  
privileges on the underlying table, but the view owner does.  
  
Note that it continues to provide the same safeguards controlling  
access to pg_statistic for direct table access (in which case  
checkAsUser won't be set) and for security barrier views, because of  
the nearby checks on rte->security_barrier and rte->securityQuals.  
  
Back-patch to all supported branches because e2d4ef8de8 was.  
  
Dean Rasheed, reviewed by Jonathan Katz and Stephen Frost.  

commit   : 1aebfbea83c4a3e1a0aba4b0910135dc5a45666c    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 6 May 2019 11:38:43 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 6 May 2019 11:38:43 +0100    

In commit e2d4ef8de8, security checks were added to prevent  
user-supplied operators from running over data from pg_statistic  
unless the user has table or column privileges on the table, or the  
operator is leakproof. For a table with RLS, however, checking for  
table or column privileges is insufficient, since that does not  
guarantee that the user has permission to view all of the column's  
data.  
  
Fix this by also checking for securityQuals on the RTE, and insisting  
that the operator be leakproof if there are any. Thus the  
leakproofness check will only be skipped if there are no securityQuals  
and the user has table or column privileges on the table -- i.e., only  
if we know that the user has access to all the data in the column.  
  
Back-patch to 9.5 where RLS was added.  
  
Dean Rasheed, reviewed by Jonathan Katz and Stephen Frost.  
  
Security: CVE-2019-10130  

commit   : bd5e8b627bae9e394352a388d2ad30465eafea2c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 May 2019 17:06:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 May 2019 17:06:53 -0400    

Noticed while reviewing nearby code.  Given all the disclaimers about  
this not being meant as user-facing code, I wonder whether we should  
make these non-translatable?  But in any case there's little excuse  
for them not to be good English.  

commit   : 9691aa72e2a7fb146ac759e1f8a8b04962128cc0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 May 2019 13:10:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 May 2019 13:10:07 -0400