PostgreSQL 12.0 (upcoming) commit log

commit   : fc16778873d081b07930d642622ee0cf22c3f9b7    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 13 Sep 2019 18:16:40 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 13 Sep 2019 18:16:40 +0900    

Author: Shenhao Wang  
Discussion: https://postgr.es/m/63580B24E208E3429D94153A03C68E0901AA8002D5@G08CNEXMBPEKD02.g08.fujitsu.local  

commit   : 3b6b54f178d7539354064727cca9b4ff2eca0fce    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 15:45:08 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 15:45:08 -0700    

Include newitemoff in rmgr desc output for nbtree page split records.  
In passing, correct an obsolete comment that claimed that newitemoff is  
only logged for _L variant nbtree page split WAL records.  
  
Both issues were oversights in commit 2c03216d831, which revamped the  
WAL format.  
  
Author: Peter Geoghegan  
Backpatch: 9.5-, where the WAL format was revamped.  

commit   : 7f1f72c44400e6fef3436b05f1ad0f6bacd03d96    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Sep 2019 18:29:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Sep 2019 18:29:17 -0400    

Since WITH CHECK OPTION was introduced, ExecInitModifyTable has  
initialized WCO expressions with the wrong plan node as parent -- that is,  
it passed its input subplan not the ModifyTable node itself.  Up to now  
we thought this was harmless, but bug #16006 from Vinay Banakar shows it's  
not: if the input node is a SubqueryScan then ExecInitWholeRowVar can get  
confused into doing the wrong thing.  (The fact that ExecInitWholeRowVar  
contains such logic is certainly a horrid kluge that doesn't deserve to  
live, but figuring out another way to do that is a task for some other day.)  
  
Andres had already noticed the wrong-parent mistake and fixed it in commit  
148e632c0, but not being aware of any user-visible consequences, he quite  
reasonably didn't back-patch.  This patch is simply a back-patch of  
148e632c0, plus addition of a test case based on bug #16006.  I also added  
the test case to v12/HEAD, even though the bug is already fixed there.  
  
Back-patch to all supported branches.  9.4 lacks RLS policies so the  
new test case doesn't work there, but I'm pretty sure a test could be  
devised based on using a whole-row Var in a plain WITH CHECK OPTION  
condition.  (I lack the cycles to do so myself, though.)  
  
Andres Freund and Tom Lane  
  
Discussion: https://postgr.es/m/16006-99290d2e4642cbd5@postgresql.org  
Discussion: https://postgr.es/m/20181205225213.hiwa3kgoxeybqcqv@alap3.anarazel.de  

commit   : 614cdeaa8908f69ab0b97b688e9785147575c01f    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 09:59:16 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 09:59:16 -0700    

Make the function prototype order consistent with the definition order  
in nbtinsert.c.  

commit   : 1b9becd43ccb7d48243882c021738c60d32c55aa    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 09:51:27 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 09:51:27 -0700    

commit   : bc98e1ea64627183746ecffcb957db147038134e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 Sep 2019 10:34:50 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 Sep 2019 10:34:50 -0300    

Authored by Tom Lane, after a gripe from James Coleman.  
  
Discussion: https://postgr.es/m/CAAaqYe9GD__4Crm=ddz+-XXcNhfY_V5gFYdLdmkFNq=2VHO56Q@mail.gmail.com  

commit   : 9b3c8f07ff3f7938696723405dc9c7b43dde4252    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 11 Sep 2019 10:25:49 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 11 Sep 2019 10:25:49 +0530    

The example used to explain 'Looping Through Query Results' uses  
pseudo-materialized views.  Replace it with a more up-to-date example  
which does the same thing with actual materialized views, which have  
been available since PostgreSQL 9.3.  
  
In the passing, change '%' as format specifier instead of '%s' as is used  
in other examples in plpgsql.sgml.  
  
Reported-by: Ian Barwick  
Author: Ian Barwick  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/9a70d393-7904-4918-c97c-649f6d114b6a@2ndquadrant.com  

commit   : ddbd5d8731619ad3ab47ce325e8605422297a613    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Sep 2019 15:06:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Sep 2019 15:06:00 +0900    

Flags of t_infomask and t_infomask2 for each tuple are already included  
in the information returned by heap_page_items as integers, and we  
lacked a way to make that information human-readable.  
  
Per discussion, the function includes an option which controls if  
combined flags should be decomposed or not.  The default is false, to  
not decompose combined flags.  
  
The module is bumped to version 1.8.  
  
Author: Craig Ringer, Sawada Masahiko  
Reviewed-by: Peter Geoghegan, Robert Haas, Álvaro Herrera, Moon Insung,  
Amit Kapila, Michael Paquier, Tomas Vondra  
Discussion: https://postgr.es/m/CAMsr+YEY7jeaXOb+oX+RhDyOFuTMdmHjGsBxL=igCm03J0go9Q@mail.gmail.com  

commit   : aafe2762b152ffd4cb839d2a01df6cfcc3c6df6c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Sep 2019 10:35:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Sep 2019 10:35:13 +0900    

This adds tests to cover more code paths to ignore backslash commands in  
false branches when using \if|\elif|\else, and improves the coverage of  
\elif.  
  
Author: Fabien Coelho  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1908281618520.28828@lancre  

commit   : 9a86f03b4e8c8f16eca7faebcb4a46330e431102    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Sep 2019 11:43:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Sep 2019 11:43:01 -0400    

This is a second try at what commit 57431a911 tried to do, namely,  
launch the syslogger before we open postmaster sockets so that our  
messages about the sockets end up in the syslogger files.  That  
commit fell foul of a bunch of subtle issues caused by trying to  
launch a postmaster child process before creating shared memory.  
Rather than messing with that interaction, let's postpone opening  
the sockets till after we launch the syslogger.  
  
This would not have been terribly safe before commit 7de19fbc0,  
because we relied on socket opening to detect whether any competing  
postmasters were using the same port number.  But now that we choose  
IPC keys without regard to the port number, there's no interaction  
to worry about.  
  
Also delay creation of the external PID file (if requested) till after  
the sockets are open, since external code could plausibly be relying  
on that ordering of events.  And postpone most of the work of  
RemovePgTempFiles() so that that potentially-slow processing still  
happens after we make the external PID file.  We have to be a bit  
careful about that last though: as noted in the discussion subsequent to  
bug #15804, EXEC_BACKEND builds still have to clear the parameter-file  
temp dir before launching the syslogger.  
  
Patch by me; thanks to Michael Paquier for review/testing.  
  
Discussion: https://postgr.es/m/15804-3721117bf40fb654@postgresql.org  

commit   : 75f46eaee20c38b2a04f569e8a5fed4f63091bd3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 11 Sep 2019 10:15:23 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 11 Sep 2019 10:15:23 -0300    

The previous wording was a bit too terse, too vague on the subject of  
'host' and 'hostaddr' in connection specifications, which has caused  
people to waste time trying to conform to rules because of  
misunderstanding the whole thing; this small change should make things  
clearer.  
  
Author: Robert Haas, stemming from Fabien Coelho's complaints  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1808201323020.13832@lancre  

commit   : 8a0deae8d9b6861265cf4ebf25a9e4385f4c7672    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Sep 2019 15:17:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Sep 2019 15:17:35 +0900    

Procedures are supported since v11 and \dfp can be used since this  
version, but it was not mentioned as a supported option in the  
description of describeFunctions() which handles \df in psql.  
  
Extracted from a larger patch.  
  
Author: Fabien Coelho  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1908281618520.28828@lancre  

commit   : 9d6e1ec5ceed1b7871fc2afd68898f0e876b60b9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Sep 2019 11:07:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Sep 2019 11:07:18 +0900    

Depending on the system used, t/*.pl may not be expanded into a list of  
tests which can be consumed by prove when attempting to run TAP tests on  
a given path.  Fix that by using glob() directly in the script, to make  
sure that a complete list of tests is provided.  This has not proved to  
be an issue with MSVC as the list was properly expanded, but it is on  
Linux with perl's system().  
  
This is extracted from a larger patch.  
  
Author: Tom Lane  
Discussion: https://postgr.es/m/6628.1567958876@sss.pgh.pa.us  
Backpatch-through: 9.4  

commit   : d06215d03b50c264a0f31e335b895ee1b6753e68    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 10 Sep 2019 20:09:27 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 10 Sep 2019 20:09:27 +0200    

When building statistics, we need to decide how many rows to sample and  
how accurate the resulting statistics should be. Until now, it was not  
possible to explicitly define statistics target for extended statistics  
objects, the value was always computed from the per-attribute targets  
with a fallback to the system-wide default statistics target.  
  
That's a bit inconvenient, as it ties together the statistics target set  
for per-column and extended statistics. In some cases it may be useful  
to require larger sample / higher accuracy for extended statics (or the  
other way around), but with this approach that's not possible.  
  
So this commit introduces a new command, allowing to specify statistics  
target for individual extended statistics objects, overriding the value  
derived from per-attribute targets (and the system default).  
  
  ALTER STATISTICS stat_name SET STATISTICS target_value;  
  
When determining statistics target for an extended statistics object we  
first look at this explicitly set value. When this value is -1, we fall  
back to the old formula, looking at the per-attribute targets first and  
then the system default. This means the behavior is backwards compatible  
with older PostgreSQL releases.  
  
Author: Tomas Vondra  
Discussion: https://postgr.es/m/20190618213357.vli3i23vpkset2xd@development  
Reviewed-by: Kirk Jamison, Dean Rasheed  

commit   : bca6e64354a2b8ed56751eb12bbf9429490c0811    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Sep 2019 18:15:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Sep 2019 18:15:17 -0400    

Up to now, async.c scanned its whole array of per-backend state  
whenever it needed to find listening backends.  That's expensive  
if MaxBackends is large, so extend the data structure with list  
links that thread the active entries together.  
  
A downside of this change is that asyncQueueUnregister (unregister  
a listening backend at backend exit) now requires exclusive not shared  
lock, and it can take awhile if there are many other listening  
backends.  We could improve the latter issue by using a doubly- not  
singly-linked list, but it's probably not worth the storage space;  
typical usage patterns for LISTEN/NOTIFY have fairly long-lived  
listeners.  
  
In return for that, Exec_ListenPreCommit (initially register a  
listening backend), SignalBackends, and asyncQueueAdvanceTail  
get significantly faster when MaxBackends is much larger than  
the number of listening backends.  If most of the potential  
backend slots are listening, we don't win, but that's a case  
where the actual interprocess-signal overhead is going to swamp  
these considerations anyway.  
  
Martijn van Oosterhout, hacked a bit more by me  
  
Discussion: https://postgr.es/m/CADWG95vtRBFDdrx1JdT1_9nhOFw48KaeTev6F_LtDQAFVpSPhA@mail.gmail.com  

commit   : 0afc0a7841889c6221fd47430e72f4fe570833f4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 Sep 2019 17:56:11 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 Sep 2019 17:56:11 -0300    

As originally coded, the script would fail on Windows 10 and Python 3  
because stdout would not be switched to UTF-8 only for Python 2.  This  
patch makes that apply to both versions.  
  
Also add python 2 compatibility markers so that we know what to remove  
once we drop support for that.  Also use a "with" clause to ensure file  
descriptor is closed promptly.  
  
Author: Hugh Ranalli, Ramanarayana  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/CAKm4Xs7_61XMyOWmHs3n0mmkS0O4S0pvfWk=7cQ5P0gs177f7A@mail.gmail.com  
Discussion: https://postgr.es/m/15548-cef1b3f8de190d4f@postgresql.org  

commit   : b438e7e7a1c58e0c20b5f46e73cbd713e8033c69    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 Sep 2019 12:13:29 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 Sep 2019 12:13:29 -0300    

There was some duplicate code to run SHOW transaction_read_only to  
determine whether the server is read-write or read-only.  Reduce it by  
adding another state to the state machine.  
  
Author: Hari Babu Kommi  
Reviewed-by: Takayuki Tsunakawa, Álvaro Herrera  
Discussion: https://postgr.es/m/CAJrrPGe_qgdbbN+yBgEVpd+YLHXXjTruzk6RmTMhqrFig+32ag@mail.gmail.com  

commit   : 55d015bde05311cbaaf16424e3aa05c37946cd8a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Sep 2019 11:41:19 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Sep 2019 11:41:19 -0700    

Assert that _bt_binsrch() binary searches with scantid set in insertion  
scankey cannot be performed on leaf pages.  Leaf-level binary searches  
where scantid is set must use _bt_binsrch_insert() instead.  
  
_bt_binsrch_insert() is likely to have additional responsibilities in  
the future, such as searching within GIN-style posting lists using  
scantid.  It seems like a good idea to tighten things up now.  

commit   : 3146f5257f16d34c95163974f42a13d99141b977    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Sep 2019 14:21:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Sep 2019 14:21:40 -0400    

Don't just assume that the next port is free; it might not be, or  
if we're really unlucky it might even be out of the TCP range.  
Do it honestly with two get_free_port() calls instead.  
  
This is surely a pretty low-probability problem, but I think it  
explains a buildfarm failure seen today, so let's fix it.  
  
Back-patch to v11 where this script was added.  
  
Discussion: https://postgr.es/m/25124.1568052346@sss.pgh.pa.us  

commit   : 73ff3a0abbbcb2c623731b88f2d1334bc67e5820    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Sep 2019 08:56:33 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Sep 2019 08:56:33 -0400    

Modern versions of msys2 have changed the treatment of "cmd /c" so that  
the runtime will try to convert the switch to a native file path. This  
patch adds a setting to inhibit that behaviour.  
  
Discussion: https://postgr.es/m/3227042f-cfcc-745a-57dd-fb8c471f8ddf@2ndQuadrant.com  
  
Backpatch to all live branches.  

commit   : 27cc7cd2bc8a5e8efc8279bc5d2a8ae42fd8ad33    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 5 Sep 2019 13:00:20 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 5 Sep 2019 13:00:20 -0700    

In ad0bda5d24ea I changed the EvalPlanQual machinery to store  
substitution tuples in slot, instead of using plain HeapTuples. The  
main motivation for that was that using HeapTuples will be inefficient  
for future tableams.  But it turns out that that conversion was buggy  
for non-locking rowmarks - the wrong tuple descriptor was used to  
create the slot.  
  
As a secondary issue 5db6df0c0 changed ExecLockRows() to begin EPQ  
earlier, to allow to fetch the locked rows directly into the EPQ  
slots, instead of having to copy tuples around. Unfortunately, as Tom  
complained, that forces some expensive initialization to happen  
earlier.  
  
As a third issue, the test coverage for EPQ was clearly insufficient.  
  
Fixing the first issue is unfortunately not trivial: Non-locked row  
marks were fetched at the start of EPQ, and we don't have the type  
information for the rowmarks available at that point. While we could  
change that, it's not easy. It might be worthwhile to change that at  
some point, but to fix this bug, it seems better to delay fetching  
non-locking rowmarks when they're actually needed, rather than  
eagerly. They're referenced at most once, and in cases where EPQ  
fails, might never be referenced. Fetching them when needed also  
increases locality a bit.  
  
To be able to fetch rowmarks during execution, rather than  
initialization, we need to be able to access the active EPQState, as  
that contains necessary data. To do so move EPQ related data from  
EState to EPQState, and, only for EStates creates as part of EPQ,  
reference the associated EPQState from EState.  
  
To fix the second issue, change EPQ initialization to allow use of  
EvalPlanQualSlot() to be used before EvalPlanQualBegin() (but  
obviously still requiring EvalPlanQualInit() to have been done).  
  
As these changes made struct EState harder to understand, e.g. by  
adding multiple EStates, significantly reorder the members, and add a  
lot more comments.  
  
Also add a few more EPQ tests, including one that fails for the first  
issue above. More is needed.  
  
Reported-By: yi huang  
Author: Andres Freund  
Reviewed-By: Tom Lane  
Discussion:  
    https://postgr.es/m/CAHU7rYZo_C4ULsAx_LAj8az9zqgrD8WDd4hTegDTMM1LMqrBsg@mail.gmail.com  
    https://postgr.es/m/24530.1562686693@sss.pgh.pa.us  
Backpatch: 12-, where the EPQ changes were introduced  

commit   : 7e04160390464cd39690d36054e0ac5e4f1bf227    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 9 Sep 2019 13:50:12 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 9 Sep 2019 13:50:12 +0300    

f2e40380 introduces support of non-key attributes in GiST indexes.  Then if  
get_index_column_opclass() is asked by gistproperty() to get an opclass of  
non-key column, it returns garbage past oidvector value.  This commit fixes  
that by making get_index_column_opclass() return InvalidOid in this case.  
  
Discussion: https://postgr.es/m/20190902231948.GA5343%40alvherre.pgsql  
Author: Nikita Glukhov, Alexander Korotkov  
Backpatch-through: 12  

commit   : 89b160c32045dd85cc6f9ae6248e34a72931ac67    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Sep 2019 10:30:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Sep 2019 10:30:22 +0200    

Tweak the tests so that we're not just testing the default setting of  
transaction_read_only.  
  
Reported-by: fn ln <emuser20140816@gmail.com>  

commit   : 1192e3fb54ce57f57399490d70af617ebc12605c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Sep 2019 17:00:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Sep 2019 17:00:29 -0400    

Some of these are quite old, but that doesn't make them not bugs.  
We'd rather report a failure via elog than SIGSEGV.  
  
While at it, uniformly spell the error check as !RelationIsValid(rel)  
rather than a bare rel == NULL test.  The machine code is the same  
but it seems better to be consistent.  
  
Coverity complained about this today, not sure why, because the  
mistake is in fact old.  

commit   : 02f90879e75b3d4ccdba1ec7c3cad6af08dff77d    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 8 Sep 2019 21:13:40 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 8 Sep 2019 21:13:40 +0300    

In order to implement NULL LAST semantic GiST previously assumed distance to  
the NULL value to be Inf.  However, our distance functions can return Inf and  
NaN for non-null values.  In such cases, NULL LAST semantic appears to be  
broken.  This commit fixes that by introducing separate array of null flags for  
distances.  
  
Backpatch to all supported versions.  
  
Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com  
Author: Alexander Korotkov  
Backpatch-through: 9.4  

commit   : e5d8f3596100da0d38a38513c69e803b7fe7041a    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 8 Sep 2019 21:07:30 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 8 Sep 2019 21:07:30 +0300    

Previously plain float comparison was used in GiST pairing heap.  Such  
comparison doesn't provide proper ordering for value sets containing Inf and Nan  
values.  This commit fixes that by usage of float8_cmp_internal().  Note, there  
is remaining problem with NULL distances, which are represented as Inf in  
pairing heap.  It would be fixes in subsequent commit.  
  
Backpatch to all supported versions.  
  
Reported-by: Andrey Borodin  
Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com  
Author: Alexander Korotkov  
Reviewed-by: Heikki Linnakangas  
Backpatch-through: 9.4  

commit   : 862ef372d6b23629f93d4afc123ddd7d172501ac    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 16:11:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 16:11:21 +0200    

When using COMMIT AND CHAIN or ROLLBACK AND CHAIN not in an explicit  
transaction block, the previous implementation would leave a  
transaction block active in the ROLLBACK case but not the COMMIT case.  
To fix for now, error out when using these commands not in an explicit  
transaction block.  This restriction could be lifted if a sensible  
definition and implementation is found.  
  
Bug: #15977  
Author: fn ln <emuser20140816@gmail.com>  
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>  

commit   : 0e777462121bd5b892c1621903d1953a49437290    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 11:10:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 11:10:49 +0200    

commit   : 8e929a4667a1f4f97c5447f54b8176b0ee15aa7d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 10:26:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 10:26:35 +0200    

Note: Following existing practice, titles of formalpara and step are  
not titlecased.  

commit   : db438318997b75f4b40c61258da56384039fa43f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Sep 2019 19:03:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Sep 2019 19:03:11 -0400    

Commit 6f6b99d13 stuck an INFO message into the fast path for  
checking partition constraints, for no very good reason except  
that it made it easy for the regression tests to verify that  
that path was taken.  Assorted later patches did likewise,  
increasing the unsuppressable-chatter level from ALTER TABLE  
even more.  This isn't good for the user experience, so let's  
drop these messages down to DEBUG1 where they belong.  So as  
not to have a loss of test coverage, create a TAP test that  
runs the relevant queries with client_min_messages = DEBUG1  
and greps for the expected messages.  
  
This testing method is a bit brute-force --- in particular,  
it duplicates the execution of a fair amount of the core  
create_table and alter_table tests.  We experimented with  
other solutions, but running any significant amount of  
standard testing with client_min_messages = DEBUG1 seems  
to have a lot of output-stability pitfalls, cf commits  
bbb96c370 and 5655565c0.  Possibly at some point we'll look  
into whether we can reduce the amount of test duplication.  
  
Backpatch into v12, because some of these messages are new  
in v12 and we don't really want to ship it that way.  
  
Sergei Kornilov  
  
Discussion: https://postgr.es/m/81911511895540@web58j.yandex.ru  
Discussion: https://postgr.es/m/4859321552643736@myt5-02b80404fd9e.qloud-c.yandex.net  

commit   : ca70bdaefea5188066b3c2a6eaaaa1cb8cb8ce06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Sep 2019 14:21:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Sep 2019 14:21:59 -0400    

As a result of some long-ago quick hacks, the SIMILAR TO operator  
and the corresponding flavor of substring() interpreted "ESCAPE NULL"  
as selecting the default escape character '\'.  This is both  
surprising and not per spec: the standard is clear that these  
functions should return NULL for NULL input.  
  
Additionally, because of inconsistency of the strictness markings  
of 3-argument substring() and similar_escape(), the planner could not  
inline the SQL definition of substring(), resulting in a substantial  
performance penalty compared to the underlying POSIX substring()  
function.  
  
The simplest fix for this would be to change the strictness marking  
of similar_escape(), but if we do that we risk breaking existing views  
that depend on that function.  Hence, leave similar_escape() as-is  
as a compatibility function, and instead invent a new function  
similar_to_escape() that comes in two strict variants.  
  
There are a couple of other behaviors in this area that are also  
not per spec, but they are documented and seem generally at least  
as sane as the spec's definition, so leave them alone.  But improve  
the documentation to describe them fully.  
  
Patch by me; thanks to Álvaro Herrera and Andrew Gierth for review  
and discussion.  
  
Discussion: https://postgr.es/m/14047.1557708214@sss.pgh.pa.us  

commit   : c5bc7050aff1d1bba6532377fe37b351581661a8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 16:12:28 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 16:12:28 +0200    

commit   : 021da890bcc129a9a1a4d996304cf437553f0937    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 22:19:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 22:19:53 +0200    

commit   : c57dbc19896cb5a15e53099765c64517afdbab14    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 22:16:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 22:16:58 +0200    

commit   : 8e5ce1c3f837a8b9a5210b7224cb5e5ac3bfc751    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 6 Sep 2019 15:47:23 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 6 Sep 2019 15:47:23 -0400    

The test for SysV support currently involves looking for the perl  
modules IPC::SharedMem and IPC::SysV. However, the perl on msys2 has  
these modules but the tests fail. Therefore, force skipping the tests on  
Windows platforms unconditionally.  
  
Discussion: https://postgr.es/m/176e86ba-1a46-9d8c-5ae4-9865a463b411@2ndQuadrant.com  

commit   : 71a01086603cc3a27c0d6ae60228aeb13c32d359    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Sep 2019 11:24:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Sep 2019 11:24:36 -0400    

We don't consider that building with MinGW is deprecated,  
so adjust some places that gave that impression.  
Per discussion with Peter Eisentraut.  
  
Discussion: https://postgr.es/m/4a023388-8652-fea0-a0b4-35ad5e734e9a@2ndquadrant.com  

commit   : bd124996ef0d655f96a7d4df79611707091f1585    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Sep 2019 10:38:51 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Sep 2019 10:38:51 -0400    

This moves much of the non-heap-specific logic from toast_delete and  
toast_insert_or_update into a helper functions accessible via a new  
header, toast_helper.h.  Using the functions in this module, a table  
AM can implement creation and deletion of TOAST table rows with  
much less code duplication than was possible heretofore.  Some  
table AMs won't want to use the TOAST logic at all, but for those  
that do this will make that easier.  
  
Patch by me, reviewed and tested by Prabhat Sabu, Thomas Munro,  
Andres Freund, and Álvaro Herrera.  
  
Discussion: http://postgr.es/m/CA+TgmoZv-=2iWM4jcw5ZhJeL18HF96+W1yJeYrnGMYdkFFnEpQ@mail.gmail.com  

commit   : 286af0ce12117bc673b97df6228d1a666594d247    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Sep 2019 08:22:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Sep 2019 08:22:32 -0400    

The old code didn't differentiate between a read error and a  
concurrent truncation. fread reports both of these by returning 0;  
you have to use feof() or ferror() to distinguish between them,  
which this code did not do.  
  
It might be a better idea to use read() rather than fread() here,  
so that we can display a less-generic error message, but I'm not  
sure that would qualify as a back-patchable bug fix, so just do  
this much for now.  
  
Jeevan Chalke, reviewed by Jeevan Ladhe and by me.  
  
Discussion: http://postgr.es/m/CA+TgmobG4ywMzL5oQq2a8YKp8x2p3p1LOMMcGqpS7aekT9+ETA@mail.gmail.com  

commit   : 5599f40d259a275d3202b10aa6ffb9a36fd8a940    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 09:15:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 09:15:35 +0200    

The term "ccache" is overloaded.  Let's be more clear, in case someone  
other than a Kerberos wizard has to read this code.  

commit   : 946647f845d0b0762656a8e07055f501c4b29688    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 6 Sep 2019 14:27:25 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 6 Sep 2019 14:27:25 +0900    

Previously even if postmaster died and WaitLatch() woke up with that event  
while pg_promote() was waiting for the standby promotion to finish,  
pg_promote() did nothing special and kept waiting until timeout occurred.  
This could cause a busy loop.  
  
This patch make pg_promote() return false immediately when postmaster  
dies, to avoid such a busy loop.  
  
Back-patch to v12 where pg_promote() was added.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CAHGQGwEs9ROgSp+QF+YdDU+xP8W=CY1k-_Ov-d_Z3JY+to3eXA@mail.gmail.com  

commit   : fc8cb94bf451cd810ae5b1c1f90b977277247625    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Sep 2019 14:00:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Sep 2019 14:00:13 +0900    

Doing the switch reduces the footprint of "progname" in both utilities  
for the messages produced.  This also cleans up a couple of  
inconsistencies in the message formats.  
  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera, Peter Eisentraut  
Discussion: https://postgr.es/m/20190820012819.GA8326@paquier.xyz  

commit   : 7de19fbc0b1a9172d0907017302b32846b2887b9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Sep 2019 13:31:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Sep 2019 13:31:41 -0400    

This approach provides a much tighter binding between a data directory  
and the associated SysV shared memory block (and SysV or named-POSIX  
semaphores, if we're using those).  Key collisions are still possible,  
but only between data directories stored on different filesystems,  
so the situation should be negligible in practice.  More importantly,  
restarting the postmaster with a different port number no longer  
risks failing to identify a relevant shared memory block, even when  
postmaster.pid has been removed.  A standalone backend is likewise  
much more certain to detect conflicting leftover backends.  
  
(In the longer term, we might now think about deprecating the port as  
a cluster-wide value, so that one postmaster could support sockets  
with varying port numbers.  But that's for another day.)  
  
The hazards fixed here apply only on Unix systems; our Windows code  
paths already use identifiers derived from the data directory path  
name rather than the port.  
  
src/test/recovery/t/017_shm.pl, which intends to test key-collision  
cases, has been substantially rewritten since it can no longer use  
two postmasters with identical port numbers to trigger the case.  
Instead, use Perl's IPC::SharedMem module to create a conflicting  
shmem segment directly.  The test script will be skipped if that  
module is not available.  (This means that some older buildfarm  
members won't run it, but I don't think that that results in any  
meaningful coverage loss.)  
  
Patch by me; thanks to Noah Misch and Peter Eisentraut for discussion  
and review.  
  
Discussion: https://postgr.es/m/16908.1557521200@sss.pgh.pa.us  

commit   : 8b94dab06617ef80a0901ab103ebd8754427ef5a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 8 Jul 2019 11:58:05 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 8 Jul 2019 11:58:05 -0400    

detoast.c/h contain functions required to detoast a datum, partially  
or completely, plus a few other utility functions for examining the  
size of toasted datums.  
  
toast_internals.c/h contain functions that are used internally to the  
TOAST subsystem but which (mostly) do not need to be accessed from  
outside.  
  
heaptoast.c/h contains code that is intrinsically specific to the  
heap AM, either because it operates on HeapTuples or is based on the  
layout of a heap page.  
  
detoast.c and toast_internals.c are placed in  
src/backend/access/common rather than src/backend/access/heap.  At  
present, both files still have dependencies on the heap, but that will  
be improved in a future commit.  
  
Patch by me, reviewed and tested by Prabhat Sabu, Thomas Munro,  
Andres Freund, and Álvaro Herrera.  
  
Discussion: http://postgr.es/m/CA+TgmoZv-=2iWM4jcw5ZhJeL18HF96+W1yJeYrnGMYdkFFnEpQ@mail.gmail.com  

commit   : 74a308cf5221f491776fcdb4dc36eb61678dbc6f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 5 Sep 2019 08:15:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 5 Sep 2019 08:15:58 +0200    

Use the explicit_bzero() function in places where it is important that  
security information such as passwords is cleared from memory.  There  
might be other places where it could be useful; this is just an  
initial collection.  
  
For platforms that don't have explicit_bzero(), provide various  
fallback implementations.  (explicit_bzero() itself isn't standard,  
but as Linux/glibc, FreeBSD, and OpenBSD have it, it's the most common  
spelling, so it makes sense to make that the invocation point.)  
  
Discussion: https://www.postgresql.org/message-id/flat/42d26bde-5d5b-c90d-87ae-6cab875f73be%402ndquadrant.com  

commit   : ae060a52b2881ea842f596fa78b8d09f9a91b149    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Sep 2019 15:46:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Sep 2019 15:46:37 +0900    

The logic ending progress reporting for a backend entry introduced by  
b6fb647 causes callers of pgstat_progress_end_command() to do some extra  
work when track_activities is enabled as the process fields are reset in  
the backend entry even if no command were started for reporting.  
  
This resets the fields only if a command is registered for progress  
reporting, and only if track_activities is enabled.  
  
Author: Masahiho Sawada  
Discussion: https://postgr.es/m/CAD21AoCry_vJ0E-m5oxJXGL3pnos-xYGCzF95rK5Bbi3Uf-rpA@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 522baf14847a7e4cc97c49c7b1c28d21bc33921f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Sep 2019 13:21:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Sep 2019 13:21:11 +0900    

Since the addition of fsync requests in bc34223 to make base backup data  
consistent on disk once pg_basebackup finishes, each tablespace tar file  
is individually flushed once completed, with an additional flush of the  
parent directory when the base backup finishes.  While holding a  
connection to the server, a fsync request taking a long time may cause a  
failure of the base backup, which is annoying for any integration.  A  
recent example of breakage can involve tcp_user_timeout, but  
wal_sender_timeout can cause similar problems.  
  
While reviewing the code, there was a second issue causing too many  
fsync requests to be done for the same WAL data.  As recursive fsyncs  
are done at the end of the backup for both the plain and tar formats  
from the base target directory where everything is written, it is fine  
to disable fsyncs when fetching or streaming WAL.  
  
Reported-by: Ryohei Takahashi  
Author: Michael Paquier  
Reviewed-by: Ryohei Takahashi  
Discussion: https://postgr.es/m/OSBPR01MB4550DAE2F8C9502894A45AAB82BE0@OSBPR01MB4550.jpnprd01.prod.outlook.com  
Backpatch-through: 10  

commit   : 25dcc9d35dfeb027047ebaea9b27cda1eaa9b393    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 3 Sep 2019 17:41:43 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 3 Sep 2019 17:41:43 -0400    

This function is only used by xlogreader.c itself, so there's no need to  
export it.  It was introduced by commit 3b02ea4f0780 with the apparent  
intention that it could be used externally, but I couldn't find any  
external code calling it.  
  
I (Álvaro) couldn't resist the urge to sort nearby function prototypes  
properly while at it.  
  
Author: Antonin Houska  
Discussion: https://postgr.es/m/14984.1554998742@spoje.net  

commit   : fe66125974c58cc749ba441ff53e72216c819da0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 3 Sep 2019 14:47:29 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 3 Sep 2019 14:47:29 -0400    

The message was included as a parameter when this function was added in  
dcb2bda9b704, but I don't think it has ever served any useful purpose.  
Let's stop spreading it pointlessly.  
  
Reviewed by Amit Langote and Peter Eisentraut.  
  
Discussion: https://postgr.es/m/20190806224728.GA17233@alvherre.pgsql  

commit   : 10f55448965f9af3a62070dce840c5c701561630    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 14:25:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 14:25:26 +0200    

Clarify in the help output and documentation that -n, -t etc. take a  
"pattern" rather than a "schema" or "table" etc.  This was especially  
confusing now that the new pg_dumpall --exclude-database option was  
documented with "pattern" and the others not, even though they all  
behave the same.  
  
Discussion: https://www.postgresql.org/message-id/flat/b85f3fa1-b350-38d1-1893-4f7911bd7310%402ndquadrant.com  

commit   : bde8c2d319ab3ebaf9f07e5511e1142a38bab0e0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 11:59:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 11:59:36 +0200    

Document that the tablespace sizes are in units of kilobytes.  Make  
the pg_basebackup source code a bit clearer about this, too.  
  
Reviewed-by: Magnus Hagander <magnus@hagander.net>  

commit   : 1d7a6e3eb45946db86d6d1776c55323740d955b0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 08:26:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 08:26:55 +0200    

The read() return was not checking for errors, the write() return was  
not checking for short writes.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/5de61b6b-8be9-7771-0048-860328efe027%402ndquadrant.com  

commit   : 396e4afdbcbfd3398415f1a0a29668d6a24a2ddd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 08:26:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 08:26:55 +0200    

This avoids getting a  
  
    Could not read from file ...: Success.  
  
for a short read or write (since errno is not set in that case).  
Instead, report a more specific error messages.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/5de61b6b-8be9-7771-0048-860328efe027%402ndquadrant.com  

commit   : 4e72a8e11e3440b10a10c8de4be2f6664ec41115    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Sep 2019 13:03:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Sep 2019 13:03:29 +0900    

"kB" or "kilobyte" is used in the documentation.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/32BA3AF7-37E9-4334-A226-98B844ADCC4E@yesql.se  

commit   : 3a54eb1a383411765deb66e6081568ae6f8d9132    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Sep 2019 12:30:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Sep 2019 12:30:53 +0900    

The leak happens in str_tolower, str_toupper and str_initcap, which are  
used in several places including their equivalent SQL-level functions,  
and can only be triggered when using an ICU-provided collation when  
converting the input string.  
  
b615920 fixed a similar leak.  Backpatch down 10 where ICU collations  
have been introduced.  
  
Author: Konstantin Knizhnik  
Discussion: https://postgr.es/m/94c0ad0a-cbc2-e4a3-7829-2bdeaf9146db@postgrespro.ru  
Backpatch-through: 10  

commit   : f63a5ead9d04467e1c1847bd5e3d87c4dca6cd35    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Sep 2019 16:10:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Sep 2019 16:10:37 -0400    

In what seems like a fit of misplaced optimization,  
ExtractReplicaIdentity() accessed the relation's replica-identity  
index without taking any lock on it.  Usually, the surrounding query  
already holds some lock so this is safe enough ... but in the case  
of a previously-planned delete, there might be no existing lock.  
Given a suitable test case, this is exposed in v12 and HEAD by an  
assertion added by commit b04aeb0a0.  
  
The whole thing's rather poorly thought out anyway; rather than  
looking directly at the index, we should use the index-attributes  
bitmap that's held by the parent table's relcache entry, as the  
caller functions do.  This is more consistent and likely a bit  
faster, since it avoids a cache lookup.  Hence, change to doing it  
that way.  
  
While at it, rather than blithely assuming that the identity  
columns are non-null (with catastrophic results if that's wrong),  
add assertion checks that they aren't null.  Possibly those should  
be actual test-and-elog, but I'll leave it like this for now.  
  
In principle, this is a bug that's been there since this code was  
introduced (in 9.4).  In practice, the risk seems quite low, since  
we do have a lock on the index's parent table, so concurrent  
changes to the index's catalog entries seem unlikely.  Given the  
precedent that commit 9c703c169 wasn't back-patched, I won't risk  
back-patching this further than v12.  
  
Per report from Hadi Moshayedi.  
  
Discussion: https://postgr.es/m/CAK=1=Wrek44Ese1V7LjKiQS-Nd-5LgLi_5_CskGbpggKEf3tKQ@mail.gmail.com  

commit   : aef36238587c95934185d29ec94e970796f477d8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Sep 2019 14:02:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Sep 2019 14:02:45 -0400    

After an unexpected connection loss and successful reconnection,  
psql neglected to resynchronize its internal state about the server,  
such as server version.  Ordinarily we'd be reconnecting to the same  
server and so this isn't really necessary, but there are scenarios  
where we do need to update --- one example is where we have a list  
of possible connection targets and they're not all alike.  
  
Define "resynchronize" as including connection_warnings(), so that  
this case acts the same as \connect.  This seems useful; for example,  
if the server version did change, the user might wish to know that.  
An attuned user might also notice that the new connection isn't  
SSL-encrypted, for example, though this approach isn't especially  
in-your-face about such changes.  Although this part is a behavioral  
change, it only affects interactive sessions, so it should not break  
any applications.  
  
Also, in do_connect, make sure that we desynchronize correctly when  
abandoning an old connection in non-interactive mode.  
  
These problems evidently are the result of people patching only one  
of the two places where psql deals with connection changes, so insert  
some cross-referencing comments in hopes of forestalling future bugs  
of the same ilk.  
  
Lastly, in Windows builds, issue codepage mismatch warnings only at  
startup, not during reconnections.  psql's codepage can't change  
during a reconnect, so complaining about it again seems like useless  
noise.  
  
Peter Billen and Tom Lane.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAMTXbE8e6U=EBQfNSe01Ej17CBStGiudMAGSOPaw-ALxM-5jXg@mail.gmail.com  

commit   : 6fcc40b1d4b91471f667fdf3ebe9665fbab95849    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 2 Sep 2019 13:37:57 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 2 Sep 2019 13:37:57 -0400    

This module was pretty much undocumented.  Fix that.  
  
Inspired by a preliminary patch sent by Ramanarayana, heavily updated by  
Andrew Dunstan, and reviewed by Michael Paquier.  
  
Discussion: https://postgr.es/m/CAF6A77G_WJTwBV9SBxCnQfZB09hm1p1O3stZ6eE5QiYd=X84Jg@mail.gmail.com  

commit   : 7dedfd22b79822b7f4210e6255b672ea82db6678    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Sep 2019 09:38:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Sep 2019 09:38:23 +0900    

Similarly to the signed versions added in 4d6ad31, this adds a set of  
inline functions for overflow checks with unsigned integers, including  
uint16, uint32 and uint64.  This relies on compiler built-in overflow  
checks by default if available.  The behavior of unsigned integers is  
well-defined so the fallback implementations checks are simple for  
additions and subtractions.  Multiplications avoid division-based checks  
which are expensive if possible, still this can happen for uint64 if  
128-bit integers are not available.  
  
While on it, the code in common/int.h is reorganized to avoid too many  
duplicated comments.  The new macros will be used in a follow-up patch.  
  
All thanks to Andres Freund for the input provided.  
  
Author: Fabien Coelho, Michael Paquier  
Discussion: https://postgr.es/m/20190830073423.GB2354@paquier.xyz  

commit   : 36515e4f14fc1b22787a54d5de45b1e6b5e6cd9c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 1 Sep 2019 23:19:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 1 Sep 2019 23:19:51 +0200    

Fix a warning about unused variable on Windows when using OpenSSL.  

commit   : 756349c87b853f83c21726c2029f840643485f7f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Aug 2019 14:05:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Aug 2019 14:05:32 -0400    

These have been there a long time, but their format was never explained  
in the docs.  Per complaint from Yusuke Egashira.  
  
Discussion: https://postgr.es/m/848B1649C8A6274AA527C4472CA11EDD5FC70CBE@G01JPEXMBYT02  

commit   : b61a5e6a1f8d4d9e0bfe5d26bebfbb0687353c08    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Aug 2019 13:37:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Aug 2019 13:37:10 -0400    

The comment describing the string format was a lie.  Make it agree with  
reality, add/improve some other comments, fix coding style for loops with  
empty bodies.  Also add an Assert that we counted parameters correctly,  
because the spread-out logic for that looks pretty fragile.  
  
No actual bugs fixed here, so no need to back-patch.  
  
Discussion: https://postgr.es/m/848B1649C8A6274AA527C4472CA11EDD5FC70CBE@G01JPEXMBYT02  

commit   : 137b03b862c21b90a86732120d0c98480daf22de    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Aug 2019 15:44:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Aug 2019 15:44:00 -0400    

The list of configure options has grown long, and there was next  
to no organization to it, never mind any indication of which options  
were interesting to most people.  Break it into several sub-sections  
to provide a bit of structure, and add some introductory text where  
it seems helpful to point people to particular options.  
  
I failed to resist the temptation to do a small amount of  
word-smithing on some of the option descriptions, too.  
But mostly this is reorganization and addition of intro text.  
  
Discussion: https://postgr.es/m/6384.1559917369@sss.pgh.pa.us  

commit   : 76c2af92666ea46bf893680e96079ecdc4e0e45d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Aug 2019 13:02:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Aug 2019 13:02:35 -0400    

Section 16.2 pointed to platform-specific FAQ files that we removed  
way back in 8.4.  Section 16.7 contained a bunch of information about  
AIX and HPUX bugs that were squashed decades ago, plus discussions of  
old compiler versions that are certainly moot now that we require C99  
support.  Since we're obviously not maintaining this stuff carefully,  
just remove it.  The HPUX sub-section seems like it can go away  
entirely, since everything it said that was still applicable was  
redundant with material elsewhere in the chapter.  
  
In passing, I couldn't resist the temptation to do a small amount  
of copy-editing on nearby text.  
  
Back-patch to v12, since this stuff is surely obsolete in any  
branch that requires C99.  
  
Discussion: https://postgr.es/m/15538.1567042743@sss.pgh.pa.us  

commit   : 9684e426954921e8b2bfa367f9e6a4cbbf4ce5ff    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 29 Aug 2019 16:19:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 29 Aug 2019 16:19:35 +0200    

Fix up oid2name, pg_upgrade, and pgbench to error out on too many  
command-line arguments.  This makes it match the behavior of other  
PostgreSQL programs.  
  
Author: Peter Eisentraut, Ibrar Ahmed  
Discussion: https://www.postgresql.org/message-id/flat/f2554627-04e7-383a-ef01-ab99bb6a291c%402ndquadrant.com  

commit   : 317b3d7ae271eca64d49c9c0fddccc3b1e2cb1f6    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 29 Aug 2019 18:45:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 29 Aug 2019 18:45:00 +0900    

commit   : 744c848dce64fd55970fcf7e9039008cbff2627e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Aug 2019 12:59:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Aug 2019 12:59:47 -0400    

commit   : bde7493d10898831100a0c6c233a5f3030bfcecd    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 28 Aug 2019 12:55:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 28 Aug 2019 12:55:33 +0300    

The comment did not match what the code actually did for integers with  
the 43rd bit set. You get an integer like that, if you have a posting  
list with two adjacent TIDs that are more than 2^31 blocks apart.  
According to the comment, we would store that in 6 bytes, with no  
continuation bit on the 6th byte, but in reality, the code encodes it  
using 7 bytes, with a continuation bit on the 6th byte as normal.  
  
The decoding routine also handled these 7-byte integers correctly, except  
for an overflow check that assumed that one integer needs at most 6 bytes.  
Fix the overflow check, and fix the comment to match what the code  
actually does. Also fix the comment that claimed that there are 17 unused  
bits in the 64-bit representation of an item pointer. In reality, there  
are 64-32-11=21.  
  
Fitting any item pointer into max 6 bytes was an important property when  
this was written, because in the old pre-9.4 format, item pointers were  
stored as plain arrays, with 6 bytes for every item pointer. The maximum  
of 6 bytes per integer in the new format guaranteed that we could convert  
any page from the old format to the new format after upgrade, so that the  
new format was never larger than the old format. But we hardly need to  
worry about that anymore, and running into that problem during upgrade,  
where an item pointer is expanded from 6 to 7 bytes such that the data  
doesn't fit on a page anymore, is implausible in practice anyway.  
  
Backpatch to all supported versions.  
  
This also includes a little test module to test these large distances  
between item pointers, without requiring a 16 TB table. It is not  
backpatched, I'm including it more for the benefit of future development  
of new posting list formats.  
  
Discussion: https://www.postgresql.org/message-id/33bfc20a-5c86-f50c-f5a5-58e9925d05ff%40iki.fi  
Reviewed-by: Masahiko Sawada, Alexander Korotkov  

commit   : 720b59b55b84c8a346098cdbf3d34c7e554b0bf5    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 28 Aug 2019 13:37:03 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 28 Aug 2019 13:37:03 +1200    

RelationAllowsEarlyPruning() performed a catalog scan, but is used  
in two contexts where that was a bad idea:  
  
1.  In heap_page_prune_opt(), which runs very frequently in some large  
    scans.  This caused major performance problems in a field report  
    that was easy to reproduce.  
  
2.  In TestForOldSnapshot(), which runs while we hold a buffer content  
    lock.  It's not clear if this was guaranteed to be free of buffer  
    deadlock risk.  
  
The check was introduced in commit 2cc41acd8 and defended against a  
real problem: 9.6's hash indexes have no page LSN and so we can't  
allow early pruning (ie the snapshot-too-old feature).  We can remove  
the check from all later releases though: hash indexes are now logged,  
and there is no way to create UNLOGGED indexes on regular logged  
tables.  
  
If a future release allows such a combination, it might need to put  
a similar check in place, but it'll need some more thought.  
  
Back-patch to 10.  
  
Author: Thomas Munro  
Reviewed-by: Tom Lane, who spotted the second problem  
Discussion: https://postgr.es/m/CA%2BhUKGKT8oTkp5jw_U4p0S-7UG9zsvtw_M47Y285bER6a2gD%2Bg%40mail.gmail.com  
Discussion: https://postgr.es/m/CAA4eK1%2BWy%2BN4eE5zPm765h68LrkWc3Biu_8rzzi%2BOYX4j%2BiHRw%40mail.gmail.com  

commit   : 80d0e5ba3fe03890831b425e85d10150e226239e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Aug 2019 12:28:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Aug 2019 12:28:16 +0900    

check_float4_val() checks after underflow and overflow of values  
converted from float8 to float4, but there has never been any regression  
tests for that.  This brings the coverage of float.h to 100%.  
  
Author: Movead Li  
Discussion: https://postgr.es/m/20190822174636998766188@highgo.ca  

commit   : be182e4f9e899a531094bee83b14fd434e52f7cb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Aug 2019 11:47:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Aug 2019 11:47:35 +0900    

In this case, the transfer uses a libpq connection, which is subject to  
the timeout parameters set at system level, and this can make the rewind  
operation suddenly canceled which is not good for automation.  One  
workaround to such issues would be to use PGOPTIONS to enforce the  
wanted timeout parameters, but that's annoying, and for example pg_dump,  
which can run potentially long-running queries disables all types of  
timeouts.  
  
lock_timeout and statement_timeout are the ones which can cause problems  
now.  Note that pg_rewind does not use transactions, so disabling  
idle_in_transaction_session_timeout is optional, but it feels safer to  
do so for the future.  
  
This is back-patched down to 9.5.  idle_in_transaction_session_timeout  
is only present since 9.6.  
  
Author: Alexander Kukushkin  
Discussion: https://postgr.es/m/CAFh8B=krcVXksxiwVQh1SoY+ziJ-JC=6FcuoBL3yce_40Es5_g@mail.gmail.com  
Backpatch-through: 9.5  

commit   : b1907d6882205319822c7452ce6b5e71ee2867be    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 19:49:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 19:49:09 -0400    

Commit a4327296d taught pg_regress proper to do this, but  
missed the opportunity to do likewise in the isolationtester  
and ecpg variants of pg_regress.  Seems like this might be  
helpful for tracking down issues exposed by those tests.  

commit   : 458f01e254e0f0b1ccab8e4589aa8495781a933a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 18:03:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 18:03:09 -0400    

Give it an explanatory para like the other default roles have.  
Don't imply that it can send any signal whatever.  
  
In passing, reorder the table entries and explanatory paras  
for the default roles into some semblance of consistency.  
  
Ian Barwick, tweaked a bit by me.  
  
Discussion: https://postgr.es/m/89907e32-76f3-7282-a89c-ea19c722fe5d@2ndquadrant.com  

commit   : c9bd7f4f2b0fc3b8291914a45cbf2a5270877ee6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 17:24:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 17:24:13 -0400    

Turns out that returning "unrecognized signal" is confusing.  
Make it explicit that the platform lacks any support for signal names.  
(At least of the machines in the buildfarm, only HPUX lacks it.)  
  
Back-patch to v12 where we invented this function.  
  
Discussion: https://postgr.es/m/3067.1566870481@sss.pgh.pa.us  

commit   : b8b3a276d453f5d561341021c93ec05b158f4c65    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 27 Aug 2019 14:01:43 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 27 Aug 2019 14:01:43 -0700    

Commit efada2b8e92, which made the nbtree page deletion algorithm more  
robust, removed the concept of a half-dead internal page.  Remove a  
comment about half dead parent pages that was overlooked.  

commit   : da1b51ecc52ffdb3f8fb1cda1e15dc60ff00cd11    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 16:37:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 16:37:21 -0400    

Section 4.2.7 says that unless otherwise specified, built-in  
aggregates ignore rows in which any input is null.  This is  
not true of the JSON aggregates, but it wasn't documented.  
Fix that.  
  
Of the other entries in table 9.55, some were explicit about  
ignoring nulls, and some weren't; for consistency and  
self-contained-ness, make them all say it explicitly.  
  
Per bug #15884 from Tim Möhlmann.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/15884-c32d848f787fcae3@postgresql.org  

commit   : d4b2425441b7ab298300142d64bb8020d38b290f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 15:14:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 15:14:55 -0400    

Daniel Gustafsson  
  
Discussion: https://postgr.es/m/F2FB03F2-B112-4E51-842E-12C50DCA2F4A@yesql.se  

commit   : 6e42130568ad28bed857948f5a3192dbf01624dc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 14:44:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 14:44:26 -0400    

An empty file name or subdirectory name leads join_path_components() to  
just produce the parent directory name, which leads to weird failures or  
recursive inclusions.  Let's throw a specific error for that.  It takes  
only slightly more code to detect all-blank names, so do so.  
  
Also, detect direct recursion, ie a file calling itself.  As coded  
this will also detect recursion via "include_dir '.'", which is  
perhaps more likely than explicitly including the file itself.  
  
Detecting indirect recursion would require API changes for guc-file.l  
functions, which seems not worth it since extensions might call them.  
The nesting depth limit will catch such cases eventually, just not  
with such an on-point error message.  
  
In passing, adjust the example usages in postgresql.conf.sample  
to perhaps eliminate the problem at the source: there's no reason  
for the examples to suggest that an empty value is valid.  
  
Per a trouble report from Brent Bates.  Back-patch to 9.5; the  
issue is old, but the code in 9.4 is enough different that the  
patch doesn't apply easily, and it doesn't seem worth the trouble  
to fix there.  
  
Ian Barwick and Tom Lane  
  
Discussion: https://postgr.es/m/8c8bcbca-3bd9-dc6e-8986-04a5abdef142@2ndquadrant.com  

commit   : 9acda731184c1ebdf99172cbb19d0404b7eebc37    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 27 Aug 2019 09:11:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 27 Aug 2019 09:11:31 +0900    

FD_SETSIZE needs to be declared before winsock2.h, or it is possible to  
run into buffer overflow issues when using --jobs.  This is similar to  
pgbench's solution done in a23c641.  
  
This has been introduced by 71d84ef, and older versions have been using  
the default value of FD_SETSIZE, defined at 64.  
  
Per buildfarm member jacana, but this impacts all Windows animals  
running the TAP tests.  I have reproduced the failure locally to check  
the patch.  
  
Author: Michael Paquier  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/20190826054000.GE7005@paquier.xyz  
Backpatch-through: 9.5  

commit   : fb57f40eec503d637bf01c298f5cb2472f0d4fdb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Aug 2019 17:02:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Aug 2019 17:02:52 -0400    

If a test case tried to set an invalid value of synchronous_standby_names,  
the test script didn't detect that, which seems like a bad idea.  
Noticed while testing a proposed patch that broke some of these  
test cases.  

commit   : ee3278239550ff0ec9df72dd798a480c82c2b723    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Aug 2019 15:59:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Aug 2019 15:59:44 -0400    

A report from Alvaro Herrera shows that if we're in PM_STARTUP  
state, and we spawn a dead_end child to reject some incoming  
connection request, and that child dies with an unexpected exit  
code, the postmaster does not respond well.  We correctly send  
SIGQUIT to the startup process, but then:  
  
* if the startup process exits with nonzero exit code, as expected,  
we thought that that indicated a crash and aborted startup.  
  
* if the startup process exits with zero exit code, which is possible  
due to the inherent race condition, we'd advance to PM_RUN state  
which is fine --- but the code forgot that AbortStartTime would be  
nonzero in this situation.  We'd either die on the Asserts saying  
that it was zero, or perhaps misbehave later on.  (A quick look  
suggests that the only misbehavior might be busy-waiting due to  
DetermineSleepTime doing the wrong thing.)  
  
To fix the first point, adjust the state-machine logic to recognize  
that a nonzero exit code is expected after sending SIGQUIT, and have  
it transition to a state where we can restart the startup process.  
To fix the second point, change the Asserts to clear the variable  
rather than just claiming it should be clear already.  
  
Perhaps we could improve this further by not treating a crash of  
a dead_end child as a reason for panic'ing the database.  However,  
since those child processes are connected to shared memory, that  
seems a bit risky.  There are few good reasons for a dead_end child  
to report failure anyway (the cause of this in Alvaro's report is  
quite unclear).  On balance, therefore, a minimal fix seems best.  
  
This is an oversight in commit 45811be94.  While that was back-patched,  
I'm hesitant to back-patch this change.  The lack of reasons for a  
dead_end child to fail suggests that the case should be very rare in  
the field, which squares with the lack of reports; so it seems like  
this might not be worth the risk of introducing new issues.  In any  
case we can let it bake awhile in HEAD before considering a back-patch.  
  
Discussion: https://postgr.es/m/20190615160950.GA31378@alvherre.pgsql  

commit   : 348778ddbc75eddaa7f9c7ce5b6adad8ada564e4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Aug 2019 14:32:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Aug 2019 14:32:40 -0400    

Incompletely quoting an API spec does nobody any good.  Noted by  
Paul Jungwirth.  Looks like the discrepancy was my fault originally :-(  
  
Discussion: https://postgr.es/m/CA+renyU_J8TU_d3Kr0PkuOgFbpypextendu7a+_d5NOfVdvDeA@mail.gmail.com  

commit   : f2690338814738967d75cc1e35cc1cfac1a40710    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Aug 2019 19:04:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Aug 2019 19:04:35 +0200    

In cc8d41511721d25d557fc02a46c053c0a602fed0, the arguments of  
warn_or_exit_horribly() were changed but this was not updated.  

commit   : c62b84437f52f0e23924268938916e90b8e5b9e6    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 26 Aug 2019 08:11:27 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 26 Aug 2019 08:11:27 -0400    

Previously 'uname -r' on Msys2 reported a kernele release starting with  
2. The latest version starts with 3. In commit 1638623f we specifically  
looked for one starting with 2. This is now changed to look for any  
digit between 2 and 9.  
  
backpatch to release 10.  

commit   : acb96eb7d294a003a9392cdd445630ef137d9918    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 26 Aug 2019 07:44:34 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 26 Aug 2019 07:44:34 -0400    

On msys2, 'uname -s' reports a string starting MSYS instead on MINGW  
as happens on msys1. Treat these both the same way. This reverts  
608a710195a4b in favor of a more general solution.  
  
Backpatch to all live branches.  

commit   : 71d84efba714db3b8a330a54be15c4d385719ad6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Aug 2019 11:14:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Aug 2019 11:14:18 +0900    

When trying to use a high number of jobs, vacuumdb (and more recently  
reindexdb) has only checked for a maximum number of jobs used, causing  
confusing failures when running out of file descriptors when the jobs  
open connections to Postgres.  This commit changes the error handling so  
as we do not check anymore for a maximum number of allowed jobs when  
parsing the option value with FD_SETSIZE, but check instead if a file  
descriptor is within the supported range when opening the connections  
for the jobs so as this is detected at the earliest time possible.  
  
Also, improve the error message to give a hint about the number of jobs  
recommended, using a wording given by the reviewers of the patch.  
  
Reported-by: Andres Freund  
Author: Michael Paquier  
Reviewed-by: Andres Freund, Álvaro Herrera, Tom Lane  
Discussion: https://postgr.es/m/20190818001858.ho3ev4z57fqhs7a5@alap3.anarazel.de  
Backpatch-through: 9.5  

commit   : 6338fa3e715ad1cb12e0760bf73ffc2a906098ea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Aug 2019 15:04:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Aug 2019 15:04:04 -0400    

POSIX permits getopt() to advance optind beyond argc when the last  
argv entry is an option that requires an argument and hasn't got one.  
It seems that no major platforms actually do that, but musl does,  
so that something like "psql -f" would crash with that libc.  
Add a check that optind is in range before trying to look at the  
possibly-bogus option.  
  
Report and fix by Quentin Rameau.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/20190825100617.GA6087@fifth.space  

commit   : faee5a12ecf13190d7ca11d6dcc7078e494f46ca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Aug 2019 12:14:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Aug 2019 12:14:50 -0400    

We were setting extra_float_digits = 0 to avoid platform-dependent  
output in this test, but that's still able to expose platform-specific  
roundoff behavior in some new test cases added by commit a3d284485,  
as reported by Peter Eisentraut.  Reduce it to -1 to hide that.  
  
(Over in geometry.sql, we're using -3, which is an ancient decision  
dating to 337f73b1b.  I wonder whether that's overkill now.  But  
there's probably little value in trying to change it.)  
  
Back-patch to v12 where a3d284485 came in; there's no evidence that  
we have any platform-dependent issues here before that.  
  
Discussion: https://postgr.es/m/15551268-e224-aa46-084a-124b64095ee3@2ndquadrant.com  

commit   : f493d98c167321e5d5c17dd7d795721045a81c97    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 25 Aug 2019 13:54:48 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 25 Aug 2019 13:54:48 +1200    

Bleeding-edge LLVM has stopped supplying replacements for various  
C++14 library features, for people on older C++ versions.  Since we're  
not ready to require C++14 yet, just use plain old new instead of  
make_unique.  As revealed by buildfarm animal seawasp.  
  
Back-patch to 11.  
  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/CA%2BhUKGJWG7unNqmkxg7nC5o3o-0p2XP6co4r%3D9epqYMm8UY4Mw%40mail.gmail.com  

commit   : 06fdc4e4d33c40dbf886565336574da5566878f4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Aug 2019 12:34:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Aug 2019 12:34:37 +0900    

989d23b has caused its tests to be broken as the module defines unused  
steps, turning the buildfarm red.  

commit   : 867d25ccb4c7f290d08c720622ecaae4afd1dc3f    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 23 Aug 2019 20:24:49 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 23 Aug 2019 20:24:49 -0700    

The Postgres approach to coupling locks during an ascent of the tree is  
slightly different to the approach taken by Lehman and Yao.  Add a new  
paragraph to the "Differences to the Lehman & Yao algorithm" section of  
the nbtree README that explains the similarities and differences.  

commit   : 989d23b04beac0c26f44c379b04ac781eaa4265e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Aug 2019 11:45:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Aug 2019 11:45:05 +0900    

This is useful for developers to find out if an isolation spec is  
over-engineered or if it needs more work by warning at the end of a  
test run if a step is not used, generating a failure with extra diffs.  
  
While on it, clean up all the specs which include steps not used in any  
permutations to simplify them.  
  
Author: Michael Paquier  
Reviewed-by: Asim Praveen, Melanie Plageman  
Discussion: https://postgr.es/m/20190819080820.GG18166@paquier.xyz  

commit   : 9903338b5ea59093d77cfe50ec0b1c22d4a7d843    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Aug 2019 11:35:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Aug 2019 11:35:43 +0900    

The original purpose of the dry-run mode is to be able to print all the  
possible permutations from a spec file, but it has become less useful  
since isolation tests has improved regarding deadlock detection as one  
step not wanted by the author could block indefinitely now (originally  
the step blocked would have been detected rather quickly).  Per  
discussion, let's remove it.  
  
Author: Michael Paquier  
Reviewed-by: Asim Praveen, Melanie Plageman  
Discussion: https://postgr.es/m/20190819080820.GG18166@paquier.xyz  

commit   : 292ae8af79b4f1b09a327d39e80ef70943a28194    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Aug 2019 20:41:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Aug 2019 20:41:06 +0900    

This adds a section for heap-related functions.  These were previously  
mixed with functions having a more general purpose, leading to  
confusion.  While on it, add a query example for fsm_page_contents.  
  
Backpatch down to 10, where b5e3942 introduced the subsections for  
function types in pageinspect documentation.  
  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoDyM7E1+cK3-aWejxKTGC-wVVP2B+RnJhN6inXyeRmqzw@mail.gmail.com  
Backpatch-through: 10  

commit   : 21e60fa8fe296355dca96c451fb13119cc0e6bd2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Aug 2019 15:36:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Aug 2019 15:36:30 +0200    

T612 has been fully supported since the major window function  
enhancements in PostgreSQL 11, but it wasn't updated at the time.  

commit   : a00c53b0cbf06dd6c01f5a1d55ebe21310a250af    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Aug 2019 10:17:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Aug 2019 10:17:30 +0200    

There were some minor differences that didn't seem necessary.  
  
Discussion: https://www.postgresql.org/message-id/flat/86b67eef-bb26-c97d-3e35-64f1fbd4f9fe%402ndquadrant.com  

commit   : 37093766b2f489128564774995f02d4e7d00dccd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Aug 2019 09:58:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Aug 2019 09:58:45 +0900    

The "Express" flavor of Visual Studio exists up to 2017, and the  
documentation referred to "Express" for Visual Studio 2019.  
  
Author: Takuma Hoshiai  
Discussion: https://postgr.es/m/20190820120231.f905542e685140258ca73d82@sraoss.co.jp  
Backpatch-through: 9.4  

commit   : 091bd6befcb71feb58b1478e1b976c85ae504822    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 21 Aug 2019 13:50:27 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 21 Aug 2019 13:50:27 -0700    

Adjust the struct comment that describes how page splits use their  
descent stack to cascade up the tree from the leaf level.  
  
In passing, fix up some unrelated nbtree comments that had typos or were  
obsolete.  

commit   : c45643d618e35ec2fe91438df15abd4f3c0d85ca    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Aug 2019 21:33:05 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Aug 2019 21:33:05 +0200    

crypt() hasn't been needed since crypt detection was removed from  
PostgreSQL, so these configure checks are not necessary.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/21f88934-f00c-27f6-a9d8-7ea06d317781%402ndquadrant.com  

commit   : 8f75e8e44609335e6bdd73123284682235f242a2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Aug 2019 11:12:44 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Aug 2019 11:12:44 -0400    

In early development patches, "replication origins" were called "identifiers";  
almost everything was renamed, but these references to the old terminology  
went unnoticed.  
  
Reported-by: Craig Ringer  

commit   : bbd93667bde56d3900add55479759f33d20ece1e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Aug 2019 10:43:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Aug 2019 10:43:23 -0400    

Using pg_pltemplate as test data was probably not very forward-looking,  
considering we've had many discussions around removing that catalog  
altogether.  Use a nearby temp table instead, to make these two test  
scripts more self-contained.  This is a better test case anyway, since  
it exercises the scenario where the entries in the anyarray column  
actually vary in type intra-query.  

commit   : 3f0f99125e5c0fd704de3c07abe691ebefc51a50    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Aug 2019 11:46:37 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Aug 2019 11:46:37 +0200    

Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>  
Discussion: https://www.postgresql.org/message-id/flat/E393EC88-377F-4C59-A67A-69F2A38D17C7@yesql.se  

commit   : db1f28917bac5e008dcb2653a54e73d2d0571e06    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 20 Aug 2019 22:25:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 20 Aug 2019 22:25:58 +0200    

Correct the comment for read_any_attr().  Give a clearer error message  
when parsing at the end of the string, when the client-final-message  
does not contain a "p" attribute (for some reason).  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/2fb8a15b-de35-682d-a77b-edcc9c52fa12%402ndquadrant.com  

commit   : f8cf524da15ec4d8fad26aeff44af9928d30eb3d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Aug 2019 16:04:09 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Aug 2019 16:04:09 -0400    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/20190819072244.GE18166@paquier.xyz  

commit   : 56f8f9624ba050c7c47dd97547b7fafb866f2bdd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Aug 2019 16:10:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Aug 2019 16:10:20 +0900    

FD_SETSIZE is included in sys/select.h per POSIX, and this header  
inclusion has been moved to scripts_parallel.c as of 5f38403 without  
moving the variable, causing a compilation failure on recent versions of  
OpenBSD (6.6 was the version used in the report).  
  
In order to take care of the failure, move FD_SETSIZE directly to  
scripts_parallel.c with a wrapper controlling the maximum number of  
parallel slots supported, based on a suggestion by Andres Freund.  
  
While on it, reduce the maximum number to be less than FD_SETSIZE,  
leaving some room for stdin, stdout and such as they consume some file  
descriptors.  
  
The buildfarm did not complain about that, as it happens to only be  
an issue on recent versions of OpenBSD and there is no coverage in this  
area.  51c3e9f fixed a similar set of issues.  
  
Bug: #15964  
Reported-by: Sean Farrell  
Discussion: https://postgr.es/m/15964-c1753bdfed722e04@postgresql.org  

commit   : 0431a787469265776eeb9a472beb3457d2990edb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Aug 2019 12:36:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Aug 2019 12:36:31 +0900    

This has been found during its translation.  
  
Author: Liudmila Mantrova  
Discussion: https://postgr.es/m/CAEkD-mDJHV3bhgezu3MUafJLoAKsOOT86+wHukKU8_NeiJYhLQ@mail.gmail.com  
Backpatch-through: 12  

commit   : e136a0d8ca31d1c94b3f2868ae0e735b8d9ff12f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Aug 2019 18:00:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Aug 2019 18:00:57 -0400    

If the record argument is NULL and has no declared type more concrete  
than RECORD, we can't extract useful information about the desired  
rowtype from it.  In this case, see if we're in FROM with an AS clause,  
and if so extract the needed rowtype info from AS.  
  
It worked like this before v11, but commit 37a795a60 removed the  
behavior, reasoning that it was undocumented, inefficient, and utterly  
not self-consistent.  If you want to take type info from an AS clause,  
you should be using the json_to_record() family of functions not the  
json_populate_record() family.  Also, it was already the case that  
the "populate" functions would fail for a null-valued RECORD input  
(with an unfriendly "record type has not been registered" error)  
when there wasn't an AS clause at hand, and it wasn't obvious that  
that behavior wasn't OK when there was one.  However, it emerges  
that some people were depending on this to work, and indeed the  
rather off-point error message you got if you left off AS encouraged  
slapping on AS without switching to the json_to_record() family.  
  
Hence, put back the fallback behavior of looking for AS.  While at it,  
improve the run-time error you get when there's no place to obtain type  
info; we can do a lot better than "record type has not been registered".  
(We can't, unfortunately, easily improve the parse-time error message  
that leads people down this path in the first place.)  
  
While at it, I refactored the code a bit to avoid duplicating the  
same logic in several different places.  
  
Per bug #15940 from Jaroslav Sivy.  Back-patch to v11 where the  
current coding came in.  (The pre-v11 deficiencies in this area  
aren't regressions, so we'll leave those branches alone.)  
  
Patch by me, based on preliminary analysis by Dmitry Dolgov.  
  
Discussion: https://postgr.es/m/15940-2ab76dc58ffb85b6@postgresql.org  

commit   : 4c01a1110388661d8752fee35e9c5614aa4a2d32    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 19 Aug 2019 12:51:38 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 19 Aug 2019 12:51:38 -0700    

Necessary after fb3b098f. That previously escaped notice, because all  
including sites already include fmgr.h some other way.  
  
Reported-By: Tom Lane  
Author: Andres Freund  
Discussion: https://postgr.es/m/17463.1566153454@sss.pgh.pa.us  

commit   : 55ea109188474dae22d90f743d7189a8bdf94d49    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Aug 2019 14:22:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Aug 2019 14:22:56 -0400    

We already had "cpluspluscheck", which served the dual purposes of  
verifying that headers compile standalone and that they compile as C++.  
However, C++ compilers don't have the exact same set of error conditions  
as C compilers, so this doesn't really prove that a header will compile  
standalone as C.  
  
Hence, add a second script that's largely similar but runs the C  
compiler not C++.  
  
Also add a bit more documentation than the none-at-all we had before.  
  
Discussion: https://postgr.es/m/14803.1566175851@sss.pgh.pa.us  

commit   : a12079109686e75c833b0b04925af8cb2fa011c0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Aug 2019 13:17:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Aug 2019 13:17:02 -0400    

IANA tzcode release 2019b adds an option that tells zic not to emit  
the old 32-bit section of the timezone files, and to skip some other  
space-wasting hacks needed for compatibility with old timezone client  
libraries.  Since we only expect our own code to use the timezone data  
we install, and our code is up-to-date with 2019b, there's no apparent  
reason not to generate the smallest possible files.  
  
Unfortunately, while the individual zone files do get significantly  
smaller in many cases, they were not that big to begin with; which  
means that no real space savings ensues on filesystems that don't  
optimize small files.  (For instance, on ext4 with 4K block size,  
"du" says the installed timezone tree is the same size as before.)  
Still, it seems worth making the change, if only because this is  
presumably the wave of the future.  At the very least, we'll save  
some cycles while reading a zone file.  
  
But given the marginal value and the fact that this is a new code  
path, it doesn't seem worth the risk of back-patching this change  
into stable branches.  Hence, unlike most of our timezone-related  
changes, apply to HEAD only.  
  
Discussion: https://postgr.es/m/24998.1563403327@sss.pgh.pa.us  

commit   : 28b6ec1df64775db6d6eb47655141cda1240d901    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 19 Aug 2019 12:05:38 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 19 Aug 2019 12:05:38 -0400    

Author: Jürgen Purtz  
Discussion: https://postgr.es/m/c6027f7a-78ea-8453-0837-09903ba5fd9b@purtz.de  

commit   : a407012c07844b5d81012d6960c4b2ec11d6af9c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Aug 2019 10:30:47 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Aug 2019 10:30:47 +0200    

In a vpath build, we need to point to the source directory to allow  
FOP to find the images.  

commit   : 71851e9ab7ac8409fabc6f64273149aa71fa29f5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Aug 2019 16:33:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Aug 2019 16:33:24 +0900    

Oversight in 7bdc655.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/5da8e325-c665-da95-21e0-c8a99ea61fbf@gmail.com  

commit   : c96581abe418a3bf64b643aa4e27091d1eaea1c1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Aug 2019 16:21:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Aug 2019 16:21:39 +0900    

This fixes various typos in docs and comments, and removes some orphaned  
definitions.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/5da8e325-c665-da95-21e0-c8a99ea61fbf@gmail.com  

commit   : 927f34ce8a215c8b254136f710cca9ca4da1352c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 19:27:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 19:27:23 -0400    

Prefix inet_net_ntop and sibling routines with "pg_" to ensure that  
they aren't mistaken for C-library functions.  This fixes warnings  
from cpluspluscheck on some platforms, and should help reduce reader  
confusion everywhere, since our functions aren't exactly interchangeable  
with the library versions (they may have different ideas about address  
family codes).  
  
This shouldn't be fixing any actual bugs, unless somebody's linker  
is misbehaving, so no need to back-patch.  
  
Discussion: https://postgr.es/m/20518.1559494394@sss.pgh.pa.us  

commit   : 232720be9b6412ec2b6bee405299bcbbbe700f0b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 19:01:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 19:01:40 -0400    

Remove use of "register" keyword in hashfn.c.  It's obsolescent  
according to recent C++ compilers, and no modern C compiler pays  
much attention to it either.  
  
Also fix one cosmetic warning about signed vs unsigned comparison.  
  
Discussion: https://postgr.es/m/20518.1559494394@sss.pgh.pa.us  

commit   : 5f110933e1145ad40116cf3c67a454cb6cb71cc2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 18:01:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 18:01:01 -0400    

Needs libpq-fe.h for references to PGConn.  
  
Discussion: https://postgr.es/m/17463.1566153454@sss.pgh.pa.us  

commit   : 5c66e99178c2f72042034cceb6bc4902650a2608    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 17:51:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 17:51:35 -0400    

This has to have <time.h>, or the references to "struct tm" don't  
mean what they should.  
  
We have some other recently-introduced issues of the same ilk,  
but this one seems old.  No backpatch though, as it's only a  
latent problem for most purposes.  

commit   : 4d4c66addfd4da51b0e4be456d6109bea4539fac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 17:11:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 17:11:57 -0400    

If a table inherits from multiple unrelated parents, we must disallow  
changing the type of a column inherited from multiple such parents, else  
it would be out of step with the other parents.  However, it's possible  
for the column to ultimately be inherited from just one common ancestor,  
in which case a change starting from that ancestor should still be  
allowed.  (I would not be excited about preserving that option, were  
it not that we have regression test cases exercising it already ...)  
  
It's slightly annoying that this patch looks different from the logic  
with the same end goal in renameatt(), and more annoying that it  
requires an extra syscache lookup to make the test.  However, the  
recursion logic is quite different in the two functions, and a  
back-patched bug fix is no place to be trying to unify them.  
  
Per report from Manuel Rigger.  Back-patch to 9.5.  The bug exists in  
9.4 too (and doubtless much further back); but the way the recursion  
is done in 9.4 is a good bit different, so that substantial refactoring  
would be needed to fix it in 9.4.  I'm disinclined to do that, or risk  
introducing new bugs, for a bug that has escaped notice for this long.  
  
Discussion: https://postgr.es/m/CA+u7OA4qogDv9rz1HAb-ADxttXYPqQdUdPY_yd4kCzywNxRQXA@mail.gmail.com  

commit   : 7e78c872dd5b0f53bbeed90c2b6e610c14e9be4b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 18 Aug 2019 06:53:28 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 18 Aug 2019 06:53:28 +0200    

commit   : 9be4ce4fa33594e035eb421894247e5af61393ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 Aug 2019 18:15:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 Aug 2019 18:15:38 -0400    

This test failed fairly reproducibly on some CLOBBER_CACHE_ALWAYS  
buildfarm animals.  The cause seems to be that if a parallel worker  
is slow enough to reach its lock wait, it may not be released by  
the first deadlock check run, and then later deadlock checks might  
decide to unblock the d2 session instead of the d1 session, leaving  
us in an undetected deadlock state (since the isolationtester client  
is waiting for d1 to complete first).  
  
Fix by introducing an additional lock wait at the end of the d2a1  
step, ensuring that the deadlock checker will recognize that d1  
has to be unblocked before d2a1 completes.  
  
Also reduce max_parallel_workers_per_gather to 3 in this test.  With the  
default max_worker_processes value, we were only getting one parallel  
worker for the d2a1 step, which is not the case I hoped to test.  We  
should get 3 for d1a2 and 2 for d2a1, as the code stands; and maybe 3  
for d2a1 if somebody figures out why the last parallel worker slot isn't  
free already.  
  
Discussion: https://postgr.es/m/22195.1566077308@sss.pgh.pa.us  

commit   : d78d452bc5ac46a970e4fca2b31f3d533815c39a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 17 Aug 2019 12:36:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 17 Aug 2019 12:36:30 +0200    

If an assertion expression contained a macro, the failed assertion  
message would print the expanded macro, which is usually unhelpful and  
confusing.  Restructure the Assert macros to not expand any macros  
when constructing the failure message.  
  
This also fixes that the existing output for Assert et al. shows  
the *inverted* condition, which is also confusing and not how  
assertions usually work.  
  
Discussion: https://www.postgresql.org/message-id/flat/6c68efe3-117a-dcc1-73d4-18ba1ec532e2%402ndquadrant.com  

commit   : f7db0ac7d5b6ba9728616a1cc36288cb4f817e66    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 15:24:22 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 15:24:22 -0700    

Reported-By: Heikki Linnakangas  
Author: Michael Paquier  
Discussion: https://postgr.es/m/d6ffbebb-a0d2-181c-811d-b029b2225ed7@iki.fi  
Backpatch: 12-, where pluggable table access methods were introduced  

commit   : 00a5c4c17b76b2d68fab70ec0be0960590a3a7fe    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 15:19:50 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 15:19:50 -0700    

commit   : fb3b098fe88441f9531a5169008ea17eac01301f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 10:35:31 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 10:35:31 -0700    

Most of the fmgr.h includes were obsoleted by 352a24a1f9d6f7d4abb1. A  
few others can be obsoleted using the underlying struct type in an  
implementation detail.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190803193733.g3l3x3o42uv4qj7l@alap3.anarazel.de  

commit   : 6a04d345fd8094058f08344af93022566222733a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 10:33:30 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 10:33:30 -0700    

For most uses of acl.h the details of how "Acl" internally looks like  
are irrelevant. It might make sense to move a lot of the  
implementation details into a separate header at a later point.  
  
The main motivation of this change is to avoid including fmgr.h (via  
array.h, which needs it for exposed structs) in a lot of files that  
otherwise don't need it. A subsequent commit will remove the fmgr.h  
include from a lot of files.  
  
Directly include utils/array.h and utils/expandeddatum.h from the  
files that need them, but previously included them indirectly, via  
acl.h.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190803193733.g3l3x3o42uv4qj7l@alap3.anarazel.de  

commit   : 0ae2dc4db2ae9940ab2bb1e4f4c0ff27f09f8aae    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 10:16:42 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 10:16:42 -0700    

These aren't needed after 352a24a1f9d6. The remaining prototypes are  
not defined on the SQL level.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190803193733.g3l3x3o42uv4qj7l@alap3.anarazel.de  

commit   : 076e9d42099d092475ea9eaa2902ba101a27a585    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 16 Aug 2019 14:35:55 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 16 Aug 2019 14:35:55 +0900    

These seem to be leftovers from the original partitionwise-join patch,  
perhaps.  
  
Discussion: https://postgr.es/m/CAPmGK145YiMTPRnvev1dLz8na_-0aZ=Xyqn8f2QsJFBUTObNow@mail.gmail.com  

commit   : 1ced082b95b339e49fc3d9f15474f816e7a9cfb1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 20:04:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 20:04:19 -0400    

This is a variant of the problem fixed in commit 25b692568, which  
unfortunately we failed to detect at the time.  If an update trigger  
returns the "old" tuple, as it's entitled to do, then a subsequent  
iteration of the loop in ExecBRUpdateTriggers would have "oldtuple"  
equal to "trigtuple" and would fail to notice that it shouldn't  
free that.  
  
In addition to fixing the code, extend the test case added by  
25b692568 so that it covers multiple-trigger-iterations cases.  
  
This problem does not manifest in v12/HEAD, as a result of the  
relevant code having been largely rewritten for slotification.  
However, include the test case into v12/HEAD anyway, since this  
is clearly an area that someone could break again in future.  
  
Per report from Piotr Gabriel Kosinski.  Back-patch into all  
supported branches, since the bug seems quite old.  
  
Diagnosis and code fix by Thomas Munro, test case by me.  
  
Discussion: https://postgr.es/m/CAFMLSdP0rd7LqC3j-H6Fh51FYSt5A10DDh-3=W4PPc4LLUQ8YQ@mail.gmail.com  

commit   : fe9b7b2fe5973309c0a5f7d9240dde91aeeb94aa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 15:21:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 15:21:47 -0400    

Commit 4b93f5799 rearranged things in plpgsql to make it cope better with  
composite types changing underneath it intra-session.  However, I failed to  
consider the case of a composite type being dropped and recreated entirely.  
In my defense, the previous coding didn't consider that possibility at all  
either --- but it would accidentally work so long as you didn't change the  
type's field list, because the built-at-compile-time list of component  
variables would then still match the type's new definition.  The new  
coding, however, occasionally tries to re-look-up the type by OID, and  
then fails to find the dropped type.  
  
To fix this, we need to save the TypeName struct, and then redo the type  
OID lookup from that.  Of course that's expensive, so we don't want to do  
it every time we need the type OID.  This can be fixed in the same way that  
4b93f5799 dealt with changes to composite types' definitions: keep an eye  
on the type's typcache entry to see if its tupledesc has been invalidated.  
(Perhaps, at some point, this mechanism should be generalized so it can  
work for non-composite types too; but for now, plpgsql only tries to  
cope with intra-session redefinitions of composites.)  
  
I'm slightly hesitant to back-patch this into v11, because it changes  
the contents of struct PLpgSQL_type as well as the signature of  
plpgsql_build_datatype(), so in principle it could break code that is  
poking into the innards of plpgsql.  However, the only popular extension  
of that ilk is pldebugger, and it doesn't seem to be affected.  Since  
this is a regression for people who were relying on the old behavior,  
it seems worth taking the small risk of causing compatibility issues.  
  
Per bug #15913 from Daniel Fiori.  Back-patch to v11 where 4b93f5799  
came in.  
  
Discussion: https://postgr.es/m/15913-a7e112e16dedcffc@postgresql.org  

commit   : bb5ae8f6c4161e1742a90f27b697eeb14812e65f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 12:22:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 12:22:12 -0400    

Previously, async.c got rid of duplicate notifications by scanning  
the list of pending events to compare each one to the proposed new  
event.  This works okay for very small numbers of distinct events,  
but degrades as O(N^2) for many events.  We can improve matters by  
using a hash table to probe for duplicates.  So as not to add a  
lot of overhead for the simple cases that the code did handle well  
before, create the hash table only once a (sub)transaction has  
queued more than 16 distinct notify events.  
  
A downside is that we now have to do per-event work to propagate  
a successful subtransaction's notify events up to its parent.  
(But this isn't significant unless the subtransaction had many  
events, in which case the O(N^2) behavior would have been in  
play already, so we still come out ahead.)  
  
We can make some lemonade out of this lemon, though: since we must  
examine each event anyway, it's now possible to de-duplicate events  
fully, rather than skipping that for events merged up from  
subtransactions.  Hence, remove the old weasel wording in notify.sgml  
about whether de-duplication happens or not, and adjust the test  
case in async-notify.spec that exhibited the old behavior.  
  
While at it, rearrange the definition of struct Notification to make  
it more compact and require just one palloc per event, rather than  
two or three.  This saves space when there are a lot of events,  
in fact more than enough to buy back the space needed for the hash  
table.  
  
Patch by me, based on discussions around a different patch  
submitted by Filip Rembiałkowski.  
  
Discussion: https://postgr.es/m/17822.1564186806@sss.pgh.pa.us  

commit   : 45aaaa42fefad6e2f164647e373346a5a4123dad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 11:14:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 11:14:26 -0400    

Clarify what external tools can do to this file, and add a bit  
of detail about what ALTER SYSTEM itself does.  
  
Discussion: https://postgr.es/m/aed6cc9f-98f3-2693-ac81-52bb0052307e@2ndquadrant.com  

commit   : f1bf619acdff15b88b5729f8de6df4eed609b3a0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Aug 2019 15:09:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Aug 2019 15:09:19 -0400    

ALTER SYSTEM itself normally won't make duplicate entries (although  
up till this patch, it was possible to confuse it by writing case  
variants of a GUC's name).  However, if some external tool has appended  
entries to the file, that could result in duplicate entries for a single  
GUC name.  In such a situation, ALTER SYSTEM did exactly the wrong thing,  
because it replaced or removed only the first matching entry, leaving  
the later one(s) still there and hence still determining the active value.  
  
This patch fixes that by making ALTER SYSTEM sweep through the file and  
remove all matching entries, then (if not ALTER SYSTEM RESET) append the  
new setting to the end.  This means entries will be in order of last  
setting rather than first setting, but that shouldn't hurt anything.  
  
Also, make the comparisons case-insensitive so that the right things  
happen if you do, say, ALTER SYSTEM SET "TimeZone" = 'whatever'.  
  
This has been broken since ALTER SYSTEM was invented, so back-patch  
to all supported branches.  
  
Ian Barwick, with minor mods by me  
  
Discussion: https://postgr.es/m/aed6cc9f-98f3-2693-ac81-52bb0052307e@2ndquadrant.com  

commit   : 9c02cf56614366769682bb8b3f4e9eecf8f237c4    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 14 Aug 2019 11:32:35 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 14 Aug 2019 11:32:35 -0700    

The initial value of the nbtree stack downlink block number field  
recorded during an initial descent of the tree wasn't actually used.  
Both _bt_getstackbuf() callers overwrote the value with their own value.  
  
Remove the block number field from the stack struct, and add a child  
block number argument to _bt_getstackbuf() in its place.  This makes the  
overall design of _bt_getstackbuf() clearer.  
  
Author: Peter Geoghegan  
Reviewed-By: Anastasia Lubennikova  
Discussion: https://postgr.es/m/CAH2-Wzmx+UbXt2YNOUCZ-a04VdXU=S=OHuAuD7Z8uQq-PXTYUg@mail.gmail.com  

commit   : fded4773eb60541c6e7dbcf09c9bcb1cd36a063b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Aug 2019 06:50:47 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Aug 2019 06:50:47 +0200    

The method of passing LC_COLLATE and LC_CTYPE to the backend during  
initdb is obsolete as of 61d967498802ab86d8897cb3c61740d7e9d712f6.  
This can all be removed.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/eeaf2f99-a1a6-8aca-3f43-9ab0b2fb112a%402ndquadrant.com  

commit   : 96e7e1bc08919ceb34d95140834f0db94266da2e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Aug 2019 13:37:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Aug 2019 13:37:48 +0900    

This is a fix similar to 2d7d67cc, where slight plan alteration can  
cause a random failure of this regression test because of an incorect  
tuple ordering, except that this one involves lookups of pg_type.  
Similarly to the other case, add ORDER BY clauses to ensure the output  
order.  
  
The failure has been seen at least once on buildfarm member skink.  
  
Reported-by: Thomas Munro  
Discussion: https://postgr.es/m/CA+hUKGLjR9ZBvhXcr9b-NSBHPw9aRgbjyzGE+kqLsT4vwX+nkQ@mail.gmail.com  
Backpatch-through: 12  

commit   : 68ef887842ff716097bbb1bad86a40bb62247061    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 13 Aug 2019 17:16:44 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 13 Aug 2019 17:16:44 -0700    

Commit d2086b08b02 removed almost all cases where nbtree must release a  
read buffer lock and acquire a write buffer lock instead, so remaining  
cases in which that's still necessary are not notable enough to appear  
in the nbtree README.  
  
More importantly, holding on to a buffer pin in cases where nbtree must  
trade a read lock for a write lock is very unlikely to save any I/O.  
This seems to have been a long overlooked throwback to a time when  
nbtree cared about write-ordering dependencies, and performed  
synchronous buffer writes.  It hasn't worked that way in many years.  

commit   : 31d43710fb069a5c2be6ec1dbc9fa7261cf9feff    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Aug 2019 16:57:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Aug 2019 16:57:58 -0400    

Commit 07b39083c inserted an unconditional reference to pg_opfamily,  
which of course fails on servers predating that catalog.  Fortunately,  
the case it's trying to solve can't occur on such old servers (AFAIK).  
Hence, just skip the additional code when the source predates 8.3.  
  
Per bug #15955 from sly.  Back-patch to all supported branches,  
like the previous patch.  
  
Discussion: https://postgr.es/m/15955-1daa2e676e903d87@postgresql.org  

commit   : af0ba49809b57203d87702b315b64f1fd53c728d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 13 Aug 2019 11:54:26 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 13 Aug 2019 11:54:26 -0700    

Use the PageIndexTupleOverwrite() bufpage.c routine within nbtree  
instead of deleting a tuple and re-inserting its replacement.  This  
makes the intent of affected code slightly clearer.  It also makes  
CREATE INDEX slightly faster, since there is no longer a need to shift  
every leaf page's line pointer array back and forth during index builds.  
  
Author: Peter Geoghegan, Anastasia Lubennikova  
Reviewed-By: Anastasia Lubennikova  
Discussion: https://postgr.es/m/CAH2-Wz=Zk=B9+Vwm376WuO7YTjFc2SSskifQm4Nme3RRRPtOSQ@mail.gmail.com  

commit   : 815ef2f568c754dcb539cca574f1982317d74db6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 13 Aug 2019 10:26:04 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 13 Aug 2019 10:26:04 -0400    

We only need to invoke constraint exclusion on partitioned tables when  
they are a partition, and they themselves contain a default partition;  
it's not necessary otherwise, and it's expensive, so avoid it.  Also, we  
were trying once for each clause separately, but we can do it for all  
the clauses at once.  
  
While at it, centralize setting of RelOptInfo->partition_qual instead of  
computing it in slightly different ways in different places.  
  
Per complaints from Simon Riggs about 4e85642d935e; reviewed by Yuzuko  
Hosoya, Kyotaro Horiguchi.  
  
Author: Amit Langote.  I (Álvaro) again mangled the patch somewhat.  
Discussion: https://postgr.es/m/CANP8+j+tMCY=nEcQeqQam85=uopLBtX-2vHiLD2bbp7iQQUKpA@mail.gmail.com  

commit   : 416c75cf38fbf58f4589fb27b520b64092a7ceff    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 13 Aug 2019 08:38:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 13 Aug 2019 08:38:21 +0200    

This moves us to the latest minor version of DocBook 4.  It requires  
no markup changes.  

commit   : 66bde49d96a9ddacc49dcbdf1b47b5bd6e31ead5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Aug 2019 13:53:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Aug 2019 13:53:41 +0900    

This addresses some issues with unnecessary code comments, fixes various  
typos in docs and comments, and removes some orphaned structures and  
definitions.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/9aabc775-5494-b372-8bcb-4dfc0bd37c68@gmail.com  

commit   : 2d7d67cc74d0f59e76464bd5009bc74f1591018e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Aug 2019 10:55:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Aug 2019 10:55:19 +0900    

This test case could fail because of an incorrect result ordering when  
looking up at pg_class entries.  This commit adds an ORDER BY to the  
culprit query.  The cause of the failure was likely caused by a plan  
switch.  By default, the planner would likely choose an index-only scan  
or an index scan, but even a small change in the startup cost could have  
caused a bitmap heap scan to be chosen, causing the failure.  
  
While on it, switch some filtering quals to a regular expression as per  
an idea of Tom Lane.  As previously shaped, the quals would have  
selected any relations whose name begins with "temp".  And that could  
cause failures if another test running in parallel began to use similar  
relation names.  
  
Per report from buildfarm member anole, though the failure was very  
rare.  This test has been introduced by 319a810, so backpatch down to  
v10.  
  
Discussion: https://postgr.es/m/20190807132422.GC15695@paquier.xyz  
Backpatch-through: 10  

commit   : 6754fe65a4c68c1e3b179080ab62c2f3ff6d877c    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 12 Aug 2019 15:21:32 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 12 Aug 2019 15:21:32 -0700    

contrib/amcheck failed to consider the possibility that unlogged  
relations will not have any main relation fork files when running in hot  
standby mode.  This led to low-level "can't happen" errors that complain  
about the absence of a relfilenode file.  
  
To fix, simply skip verification of unlogged index relations during  
recovery.  In passing, add a direct check for the presence of a main  
fork just before verification proper begins, so that we cleanly verify  
the presence of the main relation fork file.  
  
Author: Andrey Borodin, Peter Geoghegan  
Reported-By: Andrey Borodin  
Diagnosed-By: Andrey Borodin  
Discussion: https://postgr.es/m/DA9B33AC-53CB-4643-96D4-7A0BBC037FA1@yandex-team.ru  
Backpatch: 10-, where amcheck was introduced.  

commit   : 03c811a483b243952874d8e2b3f0c2e3793bc952    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Aug 2019 13:15:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Aug 2019 13:15:47 -0400    

As coded, the ICU-collation path in pattern_char_isalpha() failed  
to consider regular ASCII letters to be case-varying.  This led to  
like_fixed_prefix treating too much of an ILIKE pattern as being a  
fixed prefix, so that indexscans derived from an ILIKE clause might  
miss entries that they should find.  
  
Per bug #15892 from James Inform.  This is an oversight in the original  
ICU patch (commit eccfef81e), so back-patch to v10 where that came in.  
  
Discussion: https://postgr.es/m/15892-e5d2bea3e8a04a1b@postgresql.org  

commit   : 3c926587b5928795e54dfea65c712a604f63cdeb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Aug 2019 11:58:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Aug 2019 11:58:35 -0400    

Now that list_nth is O(1), there's no good reason to maintain a  
separate array of RTE pointers rather than indexing into  
estate->es_range_table.  Deleting the array doesn't save all that  
much either; but just on cleanliness grounds, it's better not to  
have duplicate representations of the identical information.  
  
Discussion: https://postgr.es/m/14960.1565384592@sss.pgh.pa.us  

commit   : 5ee190f8ec37c1bbfb3061e18304e155d600bc8e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Aug 2019 11:20:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Aug 2019 11:20:18 -0400    

In the wake of commit 1cff1b95a, the result of list_concat no longer  
shares the ListCells of the second input.  Therefore, we can replace  
"list_concat(x, list_copy(y))" with just "list_concat(x, y)".  
  
To improve call sites that were list_copy'ing the first argument,  
or both arguments, invent "list_concat_copy()" which produces a new  
list sharing no ListCells with either input.  (This is a bit faster  
than "list_concat(list_copy(x), y)" because it makes the result list  
the right size to start with.)  
  
In call sites that were not list_copy'ing the second argument, the new  
semantics mean that we are usually leaking the second List's storage,  
since typically there is no remaining pointer to it.  We considered  
inventing another list_copy variant that would list_free the second  
input, but concluded that for most call sites it isn't worth worrying  
about, given the relative compactness of the new List representation.  
(Note that in cases where such leakage would happen, the old code  
already leaked the second List's header; so we're only discussing  
the size of the leak not whether there is one.  I did adjust two or  
three places that had been troubling to free that header so that  
they manually free the whole second List.)  
  
Patch by me; thanks to David Rowley for review.  
  
Discussion: https://postgr.es/m/11587.1550975080@sss.pgh.pa.us  

commit   : 251c8e39bc6b0a3ff1620d9ac10888a7660e6b88    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 12 Aug 2019 06:19:19 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 12 Aug 2019 06:19:19 +0300    

Take into account pg_server_to_any() may return input string "as is".  
  
Reported-by: Andrew Dunstan, Thomas Munro  
Discussion: https://postgr.es/m/0ed83a33-d900-466a-880a-70ef456c721f%402ndQuadrant.com  
Author: Alexander Korotkov, Thomas Munro  
Backpatch-through: 12  

commit   : b43f7c117e667fb51df36ca62e6c86054b0f8d03    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Aug 2019 18:55:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Aug 2019 18:55:32 -0400    

This reverts much of commit f03a9ca4366d064d89b7cf7ed75d4e43f2ed0667,  
but leaves the relpages/reltuples probe in select_parallel.sql.  
The pg_stat_all_tables probes are unstable enough to be annoying,  
and it no longer seems likely that they will teach us anything more  
about the underlying problem.  I'd still like some more confirmation  
though that the observed plan instability is caused by VACUUM leaving  
relpages/reltuples as zero for one of these tables.  
  
Discussion: https://postgr.es/m/CA+hUKG+0CxrKRWRMf5ymN3gm+BECHna2B-q1w8onKBep4HasUw@mail.gmail.com  

commit   : d54ceb9e176152f930e60709e07c636e8e5414f5    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 11 Aug 2019 22:54:53 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 11 Aug 2019 22:54:53 +0300    

We have implemented jsonpath string comparison using default database locale.  
However, standard requires us to compare Unicode codepoints.  This commit  
implements that, but for performance reasons we still use per-byte comparison  
for "==" operator.  Thus, for consistency other comparison operators do per-byte  
comparison if Unicode codepoints appear to be equal.  
  
In some edge cases, when same Unicode codepoints have different binary  
representations in database encoding, we diverge standard to achieve better  
performance of "==" operator.  In future to implement strict standard  
conformance, we can do normalization of input JSON strings.  
  
Original patch was written by Nikita Glukhov, rewritten by me.  
  
Reported-by: Markus Winand  
Discussion: https://postgr.es/m/8B7FA3B4-328D-43D7-95A8-37B8891B8C78%40winand.at  
Author: Nikita Glukhov, Alexander Korotkov  
Backpatch-through: 12  

commit   : cabe0f298ea7efade11d8171c617e668934d0d09    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Aug 2019 11:30:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Aug 2019 11:30:11 -0400    

This failed with either "tuple already updated by self" or "duplicate  
key value violates unique constraint", depending on whether the table  
had previously been analyzed or not.  The reason is that ANALYZE tried  
to insert or update the same pg_statistic rows twice, and there was no  
CommandCounterIncrement between.  So add one.  The same case works fine  
outside a transaction block, because then there's a whole transaction  
boundary between, as a consequence of the way VACUUM works.  
  
This issue has been latent all along, but the problem was unreachable  
before commit 11d8d72c2 added the ability to specify multiple tables  
in ANALYZE.  We could, perhaps, alternatively fix it by adding code to  
de-duplicate the list of VacuumRelations --- but that would add a  
lot of overhead to work around dumb commands, so it's not attractive.  
  
Per bug #15946 from Yaroslav Schekin.  Back-patch to v11.  
  
(Note: in v11 I also back-patched the test added by commit 23224563d;  
otherwise the problem doesn't manifest in the test I added, because  
"vactst" is empty when the tests for multiple ANALYZE targets are  
reached.  That seems like not a very good thing anyway, so I did this  
rather than rethinking the choice of test case.)  
  
Discussion: https://postgr.es/m/15946-5c7570a2884a26cf@postgresql.org  

commit   : d8cd68c8d472292ef8943a765bd1c69c0d4d61d8    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 9 Aug 2019 17:06:45 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 9 Aug 2019 17:06:45 -0700    

Rename the "tupindex" field from tuplesort.c's SortTuple struct to  
"srctape", since it can only ever be used to store a source/input tape  
number when merging external sort runs.  This has been the case since  
commit 8b304b8b72b, which removed replacement selection sort from  
tuplesort.c.  

commit   : 0662eb6219f1f4bafc1916a0bf2813cdc58e5eca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Aug 2019 13:20:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Aug 2019 13:20:28 -0400    

Not much to be said here: commit 9fdb675fc should have checked  
constisnull, didn't.  
  
Per report from Piotr Włodarczyk.  Back-patch to v11 where  
bug was introduced.  
  
Discussion: https://postgr.es/m/CAP-dhMr+vRpwizEYjUjsiZ1vwqpohTm+3Pbdt6Pr7FEgPq9R0Q@mail.gmail.com  

commit   : 1661a4050593a472c369a6660ffec05b6b837c57    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Aug 2019 12:33:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Aug 2019 12:33:43 -0400    

Merge setup_append_rel_array into setup_simple_rel_arrays.  There's no  
particularly good reason to keep them separate, and it's inconsistent  
with the lack of separation in expand_planner_arrays.  The only apparent  
benefit was that the fast path for trivial queries in query_planner()  
doesn't need to set up the append_rel_array; but all we're saving there  
is an if-test and NULL assignment, which surely ought to be negligible.  
  
Also improve some obsolete comments.  
  
Discussion: https://postgr.es/m/17220.1565301350@sss.pgh.pa.us  

commit   : b8f2da0ac5a24f669c8d320c58646759b8fc69a5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 9 Aug 2019 11:05:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 9 Aug 2019 11:05:14 +0900    

b654714 has reworked the way trailing CR/LF characters are removed from  
strings.  This commit introduces a new routine in common/string.c and  
refactors the code so as the logic is in a single place, mostly.  
  
Author: Michael Paquier  
Reviewed-by: Bruce Momjian  
Discussion: https://postgr.es/m/20190801031820.GF29334@paquier.xyz  

commit   : 28b901f73a3924187988bfaac57d20e422a432c3    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 8 Aug 2019 13:20:44 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 8 Aug 2019 13:20:44 -0700    

READTUP() routines do not and cannot use the resettable "tuplecontext"  
memory context, since it is deleted when merging begins.  Update an  
obsolete comment that claimed otherwise.  This was an oversight in  
commit e94568ecc10.  
  
In passing, fix an unrelated tuplesort typo.  

commit   : 956451e8bc9face2241d9a785e0d236a92f8e210    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 8 Aug 2019 16:03:14 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 8 Aug 2019 16:03:14 -0400    

Reviewed by Tom Lane and Amit Langote  
Discussion: https://postgr.es/m/20190806222735.GA9535@alvherre.pgsql  

commit   : 15077ab63f29fd85ff519d1c456fda614774d28b    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 8 Aug 2019 14:57:48 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 8 Aug 2019 14:57:48 -0400    

openssl doesn't like lower case subject attribute names. Error observed  
in buildfarm results.  
  
Backpatch to release 11.  

commit   : 43211c2a02f39d6568496168413dc00e0399dc2e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 8 Aug 2019 08:47:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 8 Aug 2019 08:47:55 +0200    

I left PG_CMD_PUTS around even though it could be handled by  
PG_CMD_PRINTF since PG_CMD_PUTS is sometimes called with non-literal  
arguments, and so that would create a potential problem if such a  
string contained percent signs.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  

commit   : e94cd0a8eb831d3ad756ad5f1e69b05392038355    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Aug 2019 18:09:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Aug 2019 18:09:28 -0400    

VACUUM's reference page had this text, but ANALYZE's didn't.  That's  
a clear oversight given that section 5.7 explicitly delegates the  
responsibility to define permissions requirements to the individual  
commands' man pages.  
  
Per gripe from Isaac Morland.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAMsGm5fp3oBUs-2iRfii0iEO=fZuJALVyM2zJLhNTjG34gpAVQ@mail.gmail.com  

commit   : e1f4c481b995d0f4ef9570aaf9638fe06bc5d742    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Aug 2019 16:55:31 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Aug 2019 16:55:31 -0400    

This include was probably copied from tuplestore.c, but it's not needed.  
  
Extracted from a larger patch submitted by vignesh C <vignesh21@gmail.com>  
  
Discussion: https://postgr.es/m/CALDaNm1B9naPDTm3ox1m_yZvOm3KA5S4kZQSWWAeLHAQ=3gV1Q@mail.gmail.com  

commit   : 12afc7145c03c212f26fea3a99e016da6a1c919c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Aug 2019 12:27:47 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Aug 2019 12:27:47 -0400    

Discussion: https://postgr.es/m/20190806222735.GA9535@alvherre.pgsql  

commit   : 4e85642d935eb13341584df7776eb76585d45819    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Aug 2019 12:21:22 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Aug 2019 12:21:22 -0400    

We were applying constraint exclusion on the partition constraint when  
generating pruning steps for a clause, but only for the rather  
restricted situation of them being boolean OR operators; however it is  
possible to have differently shaped clauses that also benefit from  
constraint exclusion.  This applies particularly to the default  
partition since their constraints are in essence a long list of OR'ed  
subclauses ... but it applies to other cases too.  So in certain cases  
we're scanning partitions that we don't need to.  
  
Remove the specialized code in OR clauses, and add a generally  
applicable test of the clause refuting the partition constraint; mark  
the whole pruning operation as contradictory if it hits.  
  
This has the unwanted side-effect of testing some (most? all?)  
constraints more than once if constraint_exclusion=on.  That seems  
unavoidable as far as I can tell without some additional work, but  
that's not the recommended setting for that parameter anyway.  
However, because this imposes additional processing cost for all  
queries using partitioned tables, I decided not to backpatch this  
change.  
  
Author: Amit Langote, Yuzuko Hosoya, Álvaro Herrera  
Reviewers: Shawn Wang, Thibaut Madeleine, Yoshikazu Imai, Kyotaro  
Horiguchi; they were also uncredited reviewers for commit 489247b0e615.  
Discussion: https://postgr.es/m/9bb31dfe-b0d0-53f3-3ea6-e64b811424cf@lab.ntt.co.jp  

commit   : 1f33f211bc531d257f84fefb9208dd43e8718972    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 7 Aug 2019 16:06:45 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 7 Aug 2019 16:06:45 +0300    

Discussion: https://postgr.es/m/8B7FA3B4-328D-43D7-95A8-37B8891B8C78%40winand.at  
Author: Markus Winand  
Backpatch-through: 12  

commit   : 68343b4ad75305391b38f4b42734dc07f2fe7ee2    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 7 Aug 2019 19:05:17 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 7 Aug 2019 19:05:17 +0900    

commit   : 1169fcf129f41762fa8a2d82b52eabd788b3a4de    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 Aug 2019 12:40:49 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 Aug 2019 12:40:49 +0300    

In serializable mode, heap_hot_search_buffer() incorrectly acquired a  
predicate lock on the root tuple, not the returned tuple that satisfied  
the visibility checks. As explained in README-SSI, the predicate lock does  
not need to be copied or extended to other tuple versions, but for that to  
work, the correct, visible, tuple version must be locked in the first  
place.  
  
The original SSI commit had this bug in it, but it was fixed back in 2013,  
in commit 81fbbfe335. But unfortunately, it was reintroduced a few months  
later in commit b89e151054. Wising up from that, add a regression test  
to cover this, so that it doesn't get reintroduced again. Also, move the  
code that sets 't_self', so that it happens at the same time that the  
other HeapTuple fields are set, to make it more clear that all the code in  
the loop operate on the "current" tuple in the chain, not the root tuple.  
  
Bug spotted by Andres Freund, analysis and original fix by Thomas Munro,  
test case and some additional changes to the fix by Heikki Linnakangas.  
Backpatch to all supported versions (9.4).  
  
Discussion: https://www.postgresql.org/message-id/20190731210630.nqhszuktygwftjty%40alap3.anarazel.de  

commit   : 64579be64a3811d08ea7ccf92b1a443d76b96412    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Aug 2019 18:16:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Aug 2019 18:16:31 +0900    

When parsing a timetz string with a dynamic timezone abbreviation or a  
timezone not specified, it was possible to generate incorrect timestamps  
based on a date which uses some non-initialized variables if the input  
string did not specify fully a date to parse.  This is already checked  
when a full timezone spec is included in the input string, but the two  
other cases mentioned above missed the same checks.  
  
This gets fixed by generating an error as this input is invalid, or in  
short when a date is not fully specified.  
  
Valgrind was complaining about this problem.  
  
Bug: #15910  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/15910-2eba5106b9aa0c61@postgresql.org  
Backpatch-through: 9.4  

commit   : 75c1921cd6c868c5995b88113b4463a4830b9a27    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Aug 2019 10:28:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Aug 2019 10:28:16 +0900    

As of now, logical decoding of a multi-insert has been scanning all  
xl_multi_insert_tuple entries only if XLH_INSERT_CONTAINS_NEW_TUPLE was  
getting set in the record.  This is not an issue on HEAD as multi-insert  
records are not used for system catalogs, but the logical decoding logic  
includes all the code necessary to handle that properly, except that the  
code missed to iterate correctly over all xl_multi_insert_tuple entries  
when the flag is not set.  Hence, when trying to use multi-insert for  
system catalogs, an assertion would be triggered.  
  
An upcoming patch is going to make use of multi-insert for system  
catalogs, and this fixes the logic to make sure that all entries are  
scanned correctly without softening the existing assertions.  
  
Reported-by: Daniel Gustafsson  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/CBFFD532-C033-49EB-9A5A-F67EAEE9EB0B@yesql.se  

commit   : efc77cf5f1deb96a5233c04d287ead01ee7b260d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Aug 2019 18:04:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Aug 2019 18:04:51 -0400    

contrib/intarray considers "arraycol <@ constant-array" to be indexable,  
but its GiST opclass code fails to reliably find index entries for empty  
array values (which of course should trivially match such queries).  
This is because the test condition to see whether we should descend  
through a non-leaf node is wrong.  
  
Unfortunately, empty array entries could be anywhere in the index,  
as these index opclasses are currently designed.  So there's no way  
to fix this except by lobotomizing <@ indexscans to scan the whole  
index ... which is what this patch does.  That's pretty unfortunate:  
the performance is now actually worse than a seqscan, in most cases.  
We'd be better off to remove <@ from the GiST opclasses entirely,  
and perhaps a future non-back-patchable patch will do so.  
  
In the meantime, applications whose performance is adversely impacted  
have a couple of options.  They could switch to a GIN index, which  
doesn't have this bug, or they could replace "arraycol <@ constant-array"  
with "arraycol <@ constant-array AND arraycol && constant-array".  
That will provide about the same performance as before, and it will find  
all non-empty subsets of the given constant-array, which is all that  
could reliably be expected of the query before.  
  
While at it, add some more regression test cases to improve code  
coverage of contrib/intarray.  
  
In passing, adjust resize_intArrayType so that when it's returning an  
empty array, it uses construct_empty_array for that rather than  
cowboy hacking on the input array.  While the hack produces an array  
that looks valid for most purposes, it isn't bitwise equal to empty  
arrays produced by other code paths, which could have subtle odd  
effects.  I don't think this code path is performance-critical  
enough to justify such shortcuts.  (Back-patch this part only as far  
as v11; before commit 01783ac36 we were not careful about this in  
other intarray code paths either.)  
  
Back-patch the <@ fixes to all supported versions, since this was  
broken from day one.  
  
Patch by me; thanks to Alexander Korotkov for review.  
  
Discussion: https://postgr.es/m/458.1565114141@sss.pgh.pa.us  

commit   : 4ecd05cb771313d8e4d4007ec02408e5f18de5d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Aug 2019 17:08:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Aug 2019 17:08:07 -0400    

src/test/kerberos and src/test/ldap try to run private authentication  
servers, which of course might fail.  The logs from these servers  
were being dropped into the tmp_check/ subdirectory, but they should  
be put in tmp_check/log/, because the buildfarm will only capture  
log files in that subdirectory.  Without the log output there's  
little hope of diagnosing buildfarm failures related to these servers.  
  
Backpatch to v11 where these test suites were added.  
  
Discussion: https://postgr.es/m/16017.1565047605@sss.pgh.pa.us  

commit   : 940c8b01b071b777ed56c086c383e054fbd0456e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 6 Aug 2019 18:11:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 6 Aug 2019 18:11:02 +0900    

Author: Amit Langote  
Discussion: https://postgr.es/m/CA+HiwqFhZ6ABoz-i=JZ5wMMyz-orx4asjR0og9qBtgEwOww6Yg@mail.gmail.com  

commit   : 98eab30b93d52a114bd65e154cda3402d0630667    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 5 Aug 2019 11:47:34 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 5 Aug 2019 11:47:34 -0700    

Commit a6417078 established a new project policy around OID assignment:  
new patches are encouraged to choose a random OID in the 8000..9999  
range when a manually-assigned OID is required (if multiple OIDs are  
required, a consecutive block of OIDs starting from the random point  
should be used).  Catalog entries added by committed patches that use  
OIDs from this "unstable" range are renumbered after feature freeze.  
This practice minimizes OID collisions among concurrently-developed  
patches.  
  
Show a specific random OID suggestion when the unused_oids script is  
run.  This makes it easy for patch authors to use a random OID from the  
unstable range, per the new policy.  
  
Author: Julien Rouhaud, Peter Geoghegan  
Reviewed-By: Tom Lane  
Discussion: https://postgr.es/m/CAH2-WzkkRs2ScmuBQ7xWi7xzp7fC1B3w0Nt8X+n4rBw5k+Z=zA@mail.gmail.com  

commit   : 4766dce0dd1a1a26db253dfc81773a2c55cd2555    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Aug 2019 11:20:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Aug 2019 11:20:21 -0400    

Commit bf6c614a2 rearranged the lookup of the comparison operators  
needed in a hashed subplan, and in so doing, broke the cross-type  
case: it caused the original LHS-vs-RHS operator to be used to compare  
hash table entries too (which of course are all of the RHS type).  
This leads to C functions being passed a Datum that is not of the  
type they expect, with the usual hazards of crashes and unauthorized  
server memory disclosure.  
  
For the set of hashable cross-type operators present in v11 core  
Postgres, this bug is nearly harmless on 64-bit machines, which  
may explain why it escaped earlier detection.  But it is a live  
security hazard on 32-bit machines; and of course there may be  
extensions that add more hashable cross-type operators, which  
would increase the risk.  
  
Reported by Andreas Seltenreich.  Back-patch to v11 where the  
problem came in.  
  
Security: CVE-2019-10209  

commit   : ffa2d37e5fbd1243f918f622113d6e371667e5a0    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 5 Aug 2019 07:48:41 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 5 Aug 2019 07:48:41 -0700    

Commit aa27977fe21a7dfa4da4376ad66ae37cb8f0d0b5 introduced this  
restriction for pg_temp.function_name(arg); do likewise for types  
created in temporary schemas.  Programs that this breaks should add  
"pg_temp." schema qualification or switch to arg::type_name syntax.  
Back-patch to 9.4 (all supported versions).  
  
Reviewed by Tom Lane.  Reported by Tom Lane.  
  
Security: CVE-2019-10208  

commit   : a76cfba663ceab79b891cc81a5f941051755b3b0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Aug 2019 15:35:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Aug 2019 15:35:16 +0900    

Those data types use parsing and/or calculation wrapper routines which  
can generate some generic error messages in the event of a failure.  The  
caller of these routines can also pass a pointer variable settable by  
the routine to track if an error has happened, letting the caller decide  
what to do in the event of an error and what error message to generate.  
  
Those routines have been slacking the initialization of the tracking  
flag, which can be confusing when reading the code, so add some  
safeguards against calls of these parsing routines which could lead to a  
dubious result.  
  
The LSN parsing gains an assertion to make sure that the tracking flag  
is set, while numeric and float paths initialize the flag to a saner  
state.  
  
Author: Jeevan Ladhe  
Reviewed-by: Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/CAOgcT0NOM9oR0Hag_3VpyW0uF3iCU=BDUFSPfk9JrWXRcWQHqw@mail.gmail.com  

commit   : 05ba8370b8e4b5c8f3dd51986b9fdeb43fed5610    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Aug 2019 14:27:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Aug 2019 14:27:20 +0900    

OWNER_TO was used for the completion, which is not a supported grammar,  
but OWNER TO is.  
  
This error has been introduced by d37b816, so backpatch down to 9.6.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/7ab243e0-116d-3e44-d120-76b3df7abefd@gmail.com  
Backpatch-through: 9.6  

commit   : 8548ddc61b5858b6466e69f66a6b1a7ea9daef06    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Aug 2019 12:14:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Aug 2019 12:14:58 +0900    

This addresses more issues with code comments, variable names and  
unreferenced variables.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/7ab243e0-116d-3e44-d120-76b3df7abefd@gmail.com  

commit   : 75506195da81d75597a4025b72f8367e6c45f60d    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Aug 2019 20:29:00 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Aug 2019 20:29:00 +0200    

This reverts commit 88bdbd3f746049834ae3cc972e6e650586ec3c9d.  
  
As committed, statement sampling used the existing duration threshold  
(log_min_duration_statement) when decide which statements to sample.  
The issue is that even the longest statements are subject to sampling,  
and so may not end up logged. An improvement was proposed, introducing  
a second duration threshold, but it would not be backwards compatible.  
So we've decided to revert this feature - the separate threshold should  
be part of the feature itself.  
  
Discussion: https://postgr.es/m/CAFj8pRDS8tQ3Wviw9%3DAvODyUciPSrGeMhJi_WPE%2BEB8%2B4gLL-Q%40mail.gmail.com  

commit   : 4f9ed8f3c5ef0034c98dd34549f85d8c72aab9ad    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Aug 2019 20:19:54 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Aug 2019 20:19:54 +0200    

This reverts commit 9dc122585551516309c9362e673effdbf3bd79bd.  
  
As committed, statement sampling used the existing duration threshold  
(log_min_duration_statement) when decide which statements to sample.  
The issue is that even the longest statements are subject to sampling,  
and so may not end up logged. An improvement was proposed, introducing  
a second duration threshold, but it would not be backwards compatible.  
So we've decided to revert this feature - the separate threshold should  
be part of the feature itself.  
  
Discussion: https://postgr.es/m/CAFj8pRDS8tQ3Wviw9%3DAvODyUciPSrGeMhJi_WPE%2BEB8%2B4gLL-Q%40mail.gmail.com  

commit   : e0f5048851ff88a53630a0c121a1cd15f6a2f1cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Aug 2019 14:05:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Aug 2019 14:05:34 -0400    

Perl has multiple internal representations of "undef", and just  
testing for SvTYPE(x) == SVt_NULL doesn't recognize all of them,  
leading to "cannot transform this Perl type to jsonb" errors.  
Use the approved test SvOK() instead.  
  
Report and patch by Ivan Panchenko.  Back-patch to v11 where  
this module was added.  
  
Discussion: https://postgr.es/m/1564783533.324795401@f193.i.mail.ru  

commit   : 803466b6ffaa2e5b94d8ce4d7fffa8185f2a0184    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Aug 2019 13:07:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Aug 2019 13:07:12 -0400    

src/test/kerberos and src/test/ldap need to run a private authentication  
server of the relevant type, for which they need a free TCP port.  
They were just picking a random port number in 48K-64K, which works  
except when something's already using the particular port.  Notably,  
the probability of failure rises dramatically if one simply runs those  
tests in a tight loop, because each test cycle leaves behind a bunch of  
high ports that are transiently in TIME_WAIT state.  
  
To fix, split out the code that PostgresNode.pm already had for  
identifying a free TCP port number, so that it can be invoked to choose  
a port for the KDC or LDAP server.  This isn't 100% bulletproof, since  
conceivably something else on the machine could grab the port between  
the time we check and the time we actually start the server.  But that's  
a pretty short window, so in practice this should be good enough.  
  
Back-patch to v11 where these test suites were added.  
  
Patch by me, reviewed by Andrew Dunstan.  
  
Discussion: https://postgr.es/m/3397.1564872168@sss.pgh.pa.us  

commit   : 489247b0e615592111226297a0564e11616361a5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 4 Aug 2019 11:18:45 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 4 Aug 2019 11:18:45 -0400    

When querying a partitioned table containing a default partition, we  
were wrongly deciding to include it in the scan too early in the  
process, failing to exclude it in some cases.  If we reinterpret the  
PruneStepResult.scan_default flag slightly, we can do a better job at  
detecting that it can be excluded.  The change is that we avoid setting  
the flag for that pruning step unless the step absolutely requires the  
default partition to be scanned (in contrast with the previous  
arrangement, which was to set it unless the step was able to prune it).  
So get_matching_partitions() must explicitly check the partition that  
each returned bound value corresponds to in order to determine whether  
the default one needs to be included, rather than relying on the flag  
from the final step result.  
  
Author: Yuzuko Hosoya <hosoya.yuzuko@lab.ntt.co.jp>  
Reviewed-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>  
Discussion: https://postgr.es/m/00e601d4ca86$932b8bc0$b982a340$@lab.ntt.co.jp  

commit   : 69edf4f8802247209e77f69e089799b3d83c13a4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 4 Aug 2019 11:18:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 4 Aug 2019 11:18:57 +0900    

This portion of the code got forgotten in 7cce159 which has introduced a  
new routine to build this node, and this finishes the unification of the  
places where IndexInfo is initialized.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20190801041322.GA3435@paquier.xyz  

commit   : 2abd7ae9b20bcd810d4f19d28aefb97048813825    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Aug 2019 00:02:46 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Aug 2019 00:02:46 -0700    

In 5f32b29c1819 I changed the creation of HashState.hashkeys to  
actually use HashState as the parent (instead of HashJoinState, which  
was incorrect, as they were executed below HashState), to fix the  
problem of hashkeys expressions otherwise relying on slot types  
appropriate for HashJoinState, rather than HashState as would be  
correct. That reliance was only introduced in 12, which is why it  
previously worked to use HashJoinState as the parent (although I'd be  
unsurprised if there were problematic cases).  
  
Unfortunately that's not a sufficient solution, because before this  
commit, the to-be-hashed expressions referenced inner/outer as  
appropriate for the HashJoin, not Hash. That didn't have obvious bad  
consequences, because the slots containing the tuples were put into  
ecxt_innertuple when hashing a tuple for HashState (even though Hash  
doesn't have an inner plan).  
  
There are less common cases where this can cause visible problems  
however (rather than just confusion when inspecting such executor  
trees). E.g. "ERROR: bogus varno: 65000", when explaining queries  
containing a HashJoin where the subsidiary Hash node's hash keys  
reference a subplan. While normally hashkeys aren't displayed by  
EXPLAIN, if one of those expressions references a subplan, that  
subplan may be printed as part of the Hash node - which then failed  
because an inner plan was referenced, and Hash doesn't have that.  
  
It seems quite possible that there's other broken cases, too.  
  
Fix the problem by properly splitting the expression for the HashJoin  
and Hash nodes at plan time, and have them reference the proper  
subsidiary node. While other workarounds are possible, fixing this  
correctly seems easy enough. It was a pretty ugly hack to have  
ExecInitHashJoin put the expression into the already initialized  
HashState, in the first place.  
  
I decided to not just split inner/outer hashkeys inside  
make_hashjoin(), but also to separate out hashoperators and  
hashcollations at plan time. Otherwise we would have ended up having  
two very similar loops, one at plan time and the other during executor  
startup. The work seems to more appropriately belong to plan time,  
anyway.  
  
Reported-By: Nikita Glukhov, Alexander Korotkov  
Author: Andres Freund  
Reviewed-By: Tom Lane, in an earlier version  
Discussion: https://postgr.es/m/CAPpHfdvGVegF_TKKRiBrSmatJL2dR9uwFCuR+teQ_8tEXU8mxg@mail.gmail.com  
Backpatch: 12-  

commit   : a9f301df0e76c38d4544477c1b3e5e29d57904e6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Aug 2019 09:51:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Aug 2019 09:51:12 +0900    

This fixes one warning generated by GCC and present in the test case  
array part of ECPG.  This likely got missed in past fixes like 3a4b891  
because the compilation of those tests is not done by default.  
  
Reported-by: Sergei Kornilov  
Discussion: https://postgr.es/m/14951331562847675@sas2-a1efad875d04.qloud-c.yandex.net  

commit   : 6ae4e8eae78e0781633f7b40a1b5cc189bc40923    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 1 Aug 2019 14:52:43 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 1 Aug 2019 14:52:43 -0700    

Add _lookup_hash and _insert_hash functions for callers that have  
already calculated the hash value of the key.  
  
The immediate use case is for hash algorithms that write to disk in  
partitions. The hash value can be calculated once, used to perform a  
lookup, used to select the partition, then written to the partition  
along with the tuple. When the tuple is read back, the hash value does  
not need to be recalculated.  
  
Author: Jeff Davis  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/48abe675e1330f0c264ab2fe0d4ff23eb244f9ef.camel%40j-davis.com  

commit   : 7266d0997dd2a0632da38a594c78e25ff21df67e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Aug 2019 18:50:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Aug 2019 18:50:22 -0400    

This allows simplification of the plan tree in some common usage  
patterns: we can get rid of a join to the function RTE.  
  
In principle we could pull up any immutable expression, but restricting  
it to Consts avoids the risk that multiple evaluations of the expression  
might cost more than we can save.  (Possibly this could be improved in  
future --- but we've more or less promised people that putting a function  
in FROM guarantees single evaluation, so we'd have to tread carefully.)  
  
To do this, we need to rearrange when eval_const_expressions()  
happens for expressions in function RTEs.  I moved it to  
inline_set_returning_functions(), which already has to iterate over  
every function RTE, and in consequence renamed that function to  
preprocess_function_rtes().  A useful consequence is that  
inline_set_returning_function() no longer has to do this for itself,  
simplifying that code.  
  
In passing, break out pull_up_simple_subquery's code that knows where  
everything that needs pullup_replace_vars() processing is, so that  
the new pull_up_constant_function() routine can share it.  We'd  
gotten away with one-and-a-half copies of that code so far, since  
pull_up_simple_values() could assume that a lot of cases didn't apply  
to it --- but I don't think pull_up_constant_function() can make any  
simplifying assumptions.  Might as well make pull_up_simple_values()  
use it too.  
  
(Possibly this refactoring should go further: maybe we could share  
some of the code to fill in the pullup_replace_vars_context struct?  
For now, I left it that the callers fill that completely.)  
  
Note: the one existing test case that this patch changes has to be  
changed because inlining its function RTEs would destroy the point  
of the test, namely to check join order.  
  
Alexander Kuzmenkov and Aleksandr Parfenov, reviewed by  
Antonin Houska and Anastasia Lubennikova, and whacked around  
some more by me  
  
Discussion: https://postgr.es/m/402356c32eeb93d4fed01f66d6c7fe2d@postgrespro.ru  

commit   : a8d6a95eb992e942838e41029537564d81c4a50e    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 1 Aug 2019 12:29:19 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 1 Aug 2019 12:29:19 -0700    

Oversight in commit 71dcd743.  

commit   : 71dcd7438664d81235c72337cbbbfa780f7a0630    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 1 Aug 2019 09:34:14 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 1 Aug 2019 09:34:14 -0700    

Add sort support for inet, including support for abbreviated keys.  
Testing has shown that this reduces the time taken to sort medium to  
large inet/cidr inputs by ~50-60% in realistic cases.  
  
Author: Brandur Leach  
Reviewed-By: Peter Geoghegan, Edmund Horner  
Discussion: https://postgr.es/m/CABR_9B-PQ8o2MZNJ88wo6r-NxW2EFG70M96Wmcgf99G6HUQ3sw@mail.gmail.com  

commit   : da9456d22a7697ef2c5ba9dd1402d948b2ec7f09    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Aug 2019 11:50:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Aug 2019 11:50:00 -0400    

Commit a1c1af2a1 added logic in the deadlock checker to handle lock  
grouping, but it was very poorly tested, as evidenced by the bug  
fixed in 3420851a2.  Add a test case that exercises that a bit better  
(and catches the bug --- if you revert 3420851a2, this will hang).  
  
Since it's pretty hard to get parallel workers to take exclusive  
regular locks that their parents don't already have, this test operates  
by creating a deadlock among advisory locks taken in parallel workers.  
To make that happen, we must override the parallel-safety labeling of  
the advisory-lock functions, which we do by putting them in mislabeled,  
non-inlinable wrapper functions.  
  
We also have to remove the redundant PreventAdvisoryLocksInParallelMode  
checks in lockfuncs.c.  That seems fine though; if some user accidentally  
does what this test is intentionally doing, not much harm will ensue.  
(If there are any remaining bugs that are reachable that way, they're  
probably reachable in other ways too.)  
  
Discussion: https://postgr.es/m/3243.1564437314@sss.pgh.pa.us  

commit   : 4886da8327507dddd830786b0c7aaa9cfc480b4b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Aug 2019 11:36:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Aug 2019 11:36:21 -0400    

There seems no good reason not to allow a parallel leader to execute  
these functions.  (The workers still can't, though.  Although the code  
would work, any such lock would go away at worker exit, which is not  
the documented behavior of advisory locks.)  
  
Discussion: https://postgr.es/m/11847.1564496844@sss.pgh.pa.us  

commit   : fd6ec93bf890314ac694dc8a7f3c45702ecc1bbd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Aug 2019 11:05:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Aug 2019 11:05:08 +0200    

In some cases we have elog(ERROR) while corruption is certain and we  
can give a clear error code ERRCODE_DATA_CORRUPTED or  
ERRCODE_INDEX_CORRUPTED.  
  
Author: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://www.postgresql.org/message-id/flat/25F6C686-6442-4A6B-BAF8-A6F7B84B16DE@yandex-team.ru  

commit   : b2a3d706b8d76b9d65e953942fc1ccafe892f692    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 1 Aug 2019 09:37:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 1 Aug 2019 09:37:28 +0900    

When piling up loading of modules using check_password_hook_type,  
loading passwordcheck would remove any trace of a previously-loaded  
hook.  Unloading the module would also cause previous hooks to be  
entirely gone.  
  
Reported-by: Rafael Castro  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/15932-78f48f9ef166778c@postgresql.org  
Backpatch-through: 9.4  

commit   : 07b39083c2aca003c4b1f289d7dc2368b5e2297a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Jul 2019 15:42:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Jul 2019 15:42:49 -0400    

Since pg_dump doesn't treat the member operators and functions of operator  
classes/families (that is, the pg_amop and pg_amproc entries, not the  
underlying operators/functions) as separate dumpable objects, it missed  
their dependency information.  I think this was safe when the code was  
designed, because the default object sorting rule emits operators and  
functions before opclasses, and there were no dependency types that could  
mess that up.  However, the introduction of range types in 9.2 broke it:  
now a type can have a dependency on an opclass, allowing dependency rules  
to push the opclass before the type and hence before custom operators.  
Lacking any information showing that it shouldn't do so, pg_dump emitted  
the objects in the wrong order.  
  
Fix by teaching getDependencies() to translate pg_depend entries for  
pg_amop/amproc rows to look like dependencies for their parent opfamily.  
  
I added a regression test for this in HEAD/v12, but not further back;  
life is too short to fight with 002_pg_dump.pl.  
  
Per bug #15934 from Tom Gottfried.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/15934-58b8c8ab7a09ea15@postgresql.org  

commit   : f140007050a2ba874b85c4578d8417828f4b64b6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 31 Jul 2019 09:42:15 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 31 Jul 2019 09:42:15 +0200    

The tests collate.icu.utf8 and collate.linux.utf8 were previously only  
run when explicitly selected via EXTRA_TESTS.  They require a UTF8  
database, because the error messages in the expected files refer to  
that, and they use some non-ASCII characters in the tests.  Since  
users can select any locale and encoding for the regression test run,  
it was not possible to include these tests automatically.  
  
To fix, use psql's \if facility to check various prerequisites such as  
platform and the server encoding and quit the tests at the very  
beginning if the configuration is not adequate.  We then need to  
maintain alternative expected files for these tests, but they are very  
tiny and never need to change after this.  
  
These two tests are now run automatically as part of the regression  
tests.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/052295c2-a2e1-9a21-bd36-8fbff8686cf3%402ndquadrant.com  

commit   : 870b1d6800cc2173ab672449047efbc30bdc1b57    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 31 Jul 2019 00:05:21 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 31 Jul 2019 00:05:21 -0700    

These were introduced by pgindent due to fixe to broken  
indentation (c.f. 8255c7a5eeba8). Previously the mis-indentation of  
function prototypes was creatively used to reduce indentation in a few  
places.  
  
As that formatting only exists in master and REL_12_STABLE, it seems  
better to fix it in both, rather than having some odd indentation in  
v12 that somebody might copy for future patches or such.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190728013754.jwcbe5nfyt3533vx@alap3.anarazel.de  
Backpatch: 12-  

commit   : 6384e87be28ee8d69ef11e49413b115506a3c6d3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 30 Jul 2019 18:29:55 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 30 Jul 2019 18:29:55 -0700    

Author: Andres Freund  

commit   : 652a8947d981db0367bcff5b123545eba0049878    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 31 Jul 2019 10:18:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 31 Jul 2019 10:18:29 +0900    

int_name has never been used for digest lookups since its introduction  
in e94dd6a.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/386C26CB-628B-4A4C-8879-D8BF190F2C77@yesql.se  

commit   : a29834beb1deeb0aa06742dd77ba1d21b444ca44    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jul 2019 21:43:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jul 2019 21:43:27 +0300    

The rd_amcache allows an index AM to cache arbitrary information in a  
relcache entry. This commit moves the cleanup of rd_amcache so that it  
can also be used by table AMs. Nothing takes advantage of that yet, but  
I'm sure it'll come handy for anyone writing new table AMs.  
  
Backpatch to v12, where table AM interface was introduced.  
  
Reviewed-by: Julien Rouhaud  

commit   : d8b094dabb0fa16388340ca823d0a38285d2d6ce    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jul 2019 21:14:14 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jul 2019 21:14:14 +0300    

This has been wrong ever since pg_rewind was added. The if-branch just  
above this, where we print the same error with an extra message supplied  
by XLogReadRecord() got this right, but the variable name was wrong in the  
else-branch. As a consequence, the error printed the WAL position as  
0/0 if there was an error reading a WAL file.  
  
Backpatch to 9.5, where pg_rewind was added.  

commit   : 14ef15a22246ca17c949e7a9d1abe14c8874d743    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 30 Jul 2019 19:17:12 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 30 Jul 2019 19:17:12 +0200    

When performing ANALYZE on inheritance trees, we collect two samples for  
each relation - one for the relation alone, and one for the inheritance  
subtree (relation and its child relations). And then we build statistics  
on each sample, so for each relation we get two sets of statistics.  
  
For regular (per-column) statistics this works fine, because the catalog  
includes a flag differentiating statistics built from those two samples.  
But we don't have such flag in the extended statistics catalogs, and we  
ended up updating the same row twice, triggering this error:  
  
  ERROR:  tuple already updated by self  
  
The simplest solution is to disable extended statistics on inheritance  
trees, which is what this commit is doing. In the future we may need to  
do something similar to per-column statistics, but that requires adding a  
flag to the catalog - and that's not backpatchable. Moreover, the current  
selectivity estimation code only works with individual relations, so  
building statistics on inheritance trees would be pointless anyway.  
  
Author: Tomas Vondra  
Backpatch-to: 10-  
Discussion: https://postgr.es/m/20190618231233.GA27470@telsasoft.com  
Reported-by: Justin Pryzby  

commit   : 04cf0bfc90dfae89a794d2bdd88fe3b8e313798e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 30 Jul 2019 10:54:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 30 Jul 2019 10:54:48 +0900    

When building a list of relations for a parallel processing of a schema  
or a database (or just a single-entry list for the non-parallel case  
with the database name), the list is allocated and built on-the-fly for  
each database processed, leaking after one database-level reindex is  
done.  This accumulates leaks when processing all databases, and could  
become a visible issue with thousands of relations.  
  
This is fixed by introducing a new routine in simple_list.c to free all  
the elements in a simple list made of strings or OIDs.  The header of  
the list may be using a variable declaration or an allocated pointer,  
so we don't have a routine to free this part to keep the interface  
simple.  
  
Per report from coverity for an issue introduced by 5ab892c, and  
valgrind complains about the leak as well.  The idea to introduce a new  
routine in simple_list.c is from Tom Lane.  
  
Author: Michael Paquier  
Reviewed-by: Tom Lane  

commit   : 3420851a2c2d2ac49b8ba53ccec5d02aa1e6a272    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jul 2019 18:49:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jul 2019 18:49:04 -0400    

A "break" statement erroneously left behind by commit a1c1af2a1  
caused TopoSort to do the wrong thing if a lock's wait list  
contained multiple members of the same locking group.  
  
Because parallel workers don't normally need any locks not already  
taken by their leader, this is very hard --- maybe impossible ---  
to hit in production.  Still, if it did happen, the queries involved  
in an otherwise-resolvable deadlock would block until canceled.  
  
In addition to removing the bogus "break", add an Assert showing  
that the conflicting uses of the beforeConstraints[] array (for both  
counts and flags) don't overlap, and add some commentary explaining  
why not; because it's not obvious without explanation, IMHO.  
  
Original report and patch from Rui Hai Jiang; additional assert  
and commentary by me.  Back-patch to 9.6 where the bug came in.  
  
Discussion: https://postgr.es/m/CAEri+mLd3bpHLyW+a9pSe1y=aEkeuJpwBSwvo-+m4n7-ceRmXw@mail.gmail.com  

commit   : 1e2fddfa33d3c7cc93ca3ee0f32852699bd3e012    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 29 Jul 2019 07:41:06 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 29 Jul 2019 07:41:06 +0200    

It is not safe to simply report an fsync error and continue.  We must  
exit the program instead.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Sehrope Sarkuni <sehrope@jackdb.com>  
Discussion: https://www.postgresql.org/message-id/flat/9b49fe44-8f3e-eca9-5914-29e9e99030bf@2ndquadrant.com  

commit   : eb43f3d19324d7e5376b1f57fc2e5c142a6b5f3d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 29 Jul 2019 12:28:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 29 Jul 2019 12:28:30 +0900    

This is numbered take 8, and addresses again a set of issues with code  
comments, variable names and unreferenced variables.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/b137b5eb-9c95-9c2f-586e-38aba7d59788@gmail.com  

commit   : 7cce159349ccdb39ade07f869f08e4929ef2fe0b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 29 Jul 2019 09:58:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 29 Jul 2019 09:58:49 +0900    

When copying the definition of an index rebuilt concurrently for the new  
entry, the index information was taken directly from the old index using  
the relation cache.  In this case, predicates and expressions have  
some post-processing to prepare things for the planner, which loses some  
information including the collations added in any of them.  
  
This inconsistency can cause issues when attempting for example a table  
rewrite, and makes the new indexes rebuilt concurrently inconsistent  
with the old entries.  
  
In order to fix the problem, fetch expressions and predicates directly  
from the catalog of the old entry, and fill in IndexInfo for the new  
index with that.  This makes the process more consistent with  
DefineIndex(), and the code is refactored with the addition of a routine  
to create an IndexInfo node.  
  
Reported-by: Manuel Rigger  
Author: Michael Paquier  
Discussion: https://postgr.es/m/CA+u7OA5Hp0ra235F3czPom_FyAd-3+XwSJmX95r1+sRPOJc9VQ@mail.gmail.com  
Backpatch-through: 12  

commit   : a2a777d011971ace3a349a3f02b1bf6eeea07bf2    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 29 Jul 2019 10:12:37 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 29 Jul 2019 10:12:37 +1200    

Early previews of LLVM 9 reveal that our Min() macro causes compiler  
errors in LLVM headers reached by the #include directives in  
llvmjit_inline.cpp.  Let's just undefine it.  Per buildfarm animal  
seawasp.  Back-patch to 11.  
  
Reviewed-by: Fabien Coelho, Tom Lane  
Discussion: https://postgr.es/m/20190606173216.GA6306%40alvherre.pgsql  

commit   : b10f40bf0e4516d7832db8ccbe5f76319ad08682    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Jul 2019 12:02:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Jul 2019 12:02:27 -0400    

We had no actual end-to-end test of NOTIFY message delivery.  In the  
core async.sql regression test, testing this is problematic because psql  
traditionally prints the PID of the sending backend, making the output  
unstable.  We also have an isolation test script, but it likewise  
failed to prove that delivery worked, because isolationtester.c had  
no provisions for detecting/reporting NOTIFY messages.  
  
Hence, add such provisions to isolationtester.c, and extend  
async-notify.spec to include direct tests of basic NOTIFY functionality.  
  
I also added tests showing that NOTIFY de-duplicates messages normally,  
but not across subtransaction boundaries.  (That's the historical  
behavior since we introduced subtransactions, though perhaps we ought  
to change it.)  
  
Patch by me, with suggestions/review by Andres Freund.  
  
Discussion: https://postgr.es/m/31304.1564246011@sss.pgh.pa.us  

commit   : 44460d7017cde005d7a2e246db0b32375bfec15d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 28 Jul 2019 22:02:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 28 Jul 2019 22:02:15 +0900    

The table has not been updated for some commands introduced in recent  
releases, so refresh it.  While on it, reorder entries alphabetically.  
  
Backpatch all the way down for all the commands which have gone  
missing.  
  
Reported-by: Jeremy Smith  
Discussion: https://postgr.es/m/15883-afff0ea3cc2dbbb6@postgresql.org  
Backpatch-through: 9.4  

commit   : b7a82317b66362880c16f1bd49573ab34f0dad1f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 28 Jul 2019 16:21:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 28 Jul 2019 16:21:53 +0900    

The frontend version of walkdir() is defined in file_utils.c, and not  
initdb.c.  
  
Author: Sehrope Sarkuni  
Discussion: https://postgr.es/m/CAH7T-artawnBt4=KODNCD8Mt2ZX4CCjJT8c=_=950xjutcRZ4Q@mail.gmail.com  

commit   : 30717637c1c58fcd02980a6752c7e13c9de12b69    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jul 2019 20:21:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jul 2019 20:21:54 -0400    

If a test sends a notice just before blocking, it's possible on  
slow machines for isolationtester to detect the blocked state before  
it's consumed the notice.  (For this to happen, the notice would have  
to arrive after isolationtester has waited for data for 10ms, so on  
fast/lightly-loaded machines it's hard to reproduce the failure.)  
But, if we have seen the backend as blocked, it's certainly already  
sent any notices it's going to send.  Therefore, one more round of  
PQconsumeInput and PQisBusy should be enough to collect and process  
any such notices.  
  
This appears to explain the instability noted in commit ebd499282, so undo  
the hack therein to not print notices from insert-conflict-specconflict.  
  
Patch by me, diagnosis by Andres Freund.  
  
Discussion: https://postgr.es/m/14616.1564251339@sss.pgh.pa.us  

commit   : ebd49928215e3854d91167e798949a75b34958d0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jul 2019 15:59:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jul 2019 15:59:57 -0400    

For its entire existence, isolationtester.c has forced client_min_messages  
to WARNING, but that seems like a very poor choice of test design.  It  
should be up to individual test scripts to manage whether they emit notices  
and to ensure that the results are stable.  (There were no NOTICE messages  
in the original set of isolation tests, so this was certainly dead code  
when committed, but perhaps it was needed at some earlier point.)  
  
It's possible that the original motivation was due to platform-dependent  
variations in the timing of stdout vs. stderr output.  That should be  
moot since commits 73bcb76b7/6eda3e9c2, but just in case, adjust  
isotesterNoticeProcessor to print to stdout not stderr.  (stderr seems  
like the wrong thing anyway: it should be for error printouts not expected  
test output.)  
  
Testing shows that the notices in insert-conflict-specconflict are indeed  
a bit timing-unstable on very slow machines, so hide them; maybe we can  
improve that later.  Also, make the notices in plpgsql-toast a bit less  
verbose than the original code would've had them.  
  
Discussion: https://postgr.es/m/14616.1564251339@sss.pgh.pa.us  

commit   : 5ab892c391c6bc54a00e7a8de5cab077cabace6a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 27 Jul 2019 22:21:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 27 Jul 2019 22:21:18 +0900    

When doing a schema-level or a database-level operation, a list of  
relations to build is created which gets processed in parallel using  
multiple connections, based on the recent refactoring for parallel slots  
in src/bin/scripts/.  System catalogs are processed first in a  
serialized fashion to prevent deadlocks, followed by the rest done in  
parallel.  
  
This new option is not compatible with --system as reindexing system  
catalogs in parallel can lead to deadlocks, and with --index as there is  
no conflict handling for indexes rebuilt in parallel depending in the  
same relation.  
  
Author: Julien Rouhaud  
Reviewed-by: Sergei Kornilov, Michael Paquier  
Discussion: https://postgr.es/m/CAOBaU_YrnH_Jqo46NhaJ7uRBiWWEcS40VNRQxgFbqYo9kApUsg@mail.gmail.com  

commit   : 4552c0f566667160ab3eeaf1620ebb969c1e7eb0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 08:26:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 08:26:33 +0200    

Recently released xfsprogs 5.1.0 has reflink support enabled by  
default, so the note that it's not enabled by default can be removed.  

commit   : 959f6d6a1821b7d9068244f500dd80953e768d16    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 07:56:20 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 07:56:20 +0200    

Make the directory where the pg_upgrade binary resides the default for  
new bindir, as running the pg_upgrade binary from where the new  
cluster is installed is a very common scenario.  Setting this as the  
defauly bindir for the new cluster will remove the need to provide it  
explicitly via -B in many cases.  
  
To support directories being missing from option parsing, extend the  
directory check with a missingOk mode where the path must be filled at  
a later point before being used.  Also move the exec_path check to  
earlier in setup to make sure we know the new cluster bindir when we  
scan for required executables.  
  
This removes the exec_path from the OSInfo struct as it is not used  
anywhere.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/9328.1552952117@sss.pgh.pa.us  

commit   : 0befb4f31386efb622e4df9f3a313aa1f2e17899    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 07:48:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 07:48:08 +0200    

Expand the validate_exec() calls to cover all the used binaries.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/9328.1552952117@sss.pgh.pa.us  

commit   : 28cb0555c1153a0dcdf1c908d7265acafa413b57    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 07:46:02 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 07:46:02 +0200    

Author: Daniel Gustafsson <daniel@yesql.se>  

commit   : 0994cfc0ac853de4245f003698160fe1b8c577bd    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Jul 2019 17:46:40 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Jul 2019 17:46:40 -0400    

Per gripe from Ian Barwick  
  
Co-authored-by: Ian Barwick <ian@2ndquadrant.com>  
Discussion: https://postgr.es/m/CABvVfJWNnNKb8cHsTLhkTsvL1+G6BVcV+57+w1JZ61p8YGPdWQ@mail.gmail.com  

commit   : 8ab66081ca496fd74c406e435e20f4264881a02d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 13:07:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 13:07:08 -0400    

pg_timezone_names() tries to avoid showing the "Factory" zone in  
the view, mainly because that has traditionally had a very long  
"abbreviation" such as "Local time zone must be set--see zic manual page",  
so that showing it messes up psql's formatting of the whole view.  
Since tzdb version 2016g, IANA instead uses the abbreviation "-00",  
which is sane enough that there's no reason to discriminate against it.  
  
On the other hand, it emerges that FreeBSD and possibly other packagers  
are so wedded to backwards compatibility that they hack the IANA data  
to keep the old spelling --- and not just that old spelling, but even  
older spellings that IANA used back in the stone age.  This caused the  
filter logic to fail to suppress "Factory" at all on such platforms,  
though the formatting problem is definitely real in that case.  
  
To solve both problems, get rid of the hard-wired assumption about  
exactly what Factory's abbreviation is, and instead reject abbreviations  
exceeding 31 characters.  This will allow Factory to appear in the view  
if and only if it's using the modern abbreviation.  
  
In passing, simplify the code we add to zic.c to support "zic -P"  
to remove its now-obsolete hacks to not print the Factory zone's  
abbreviation.  Unlike pg_timezone_names(), there's no reason for  
that code to support old/nonstandard timezone data.  
  
Since we generally prefer to keep timezone-related behavior the  
same in all branches, and since this is arguably a bug fix,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/3961.1564086915@sss.pgh.pa.us  

commit   : 3754113f33651965d92aaad6f393757ac0cf8333    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 12:45:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 12:45:32 -0400    

Some platforms create a file named "localtime" in the system  
timezone directory, making it a copy or link to the active time  
zone file.  If Postgres is built with --with-system-tzdata, initdb  
will see that file as an exact match to localtime(3)'s behavior,  
and it may decide that "localtime" is the most preferred spelling of  
the active zone.  That's a very bad choice though, because it's  
neither informative, nor portable, nor stable if someone changes  
the system timezone setting.  Extend the preference logic added by  
commit e3846a00c so that we will prefer any other zone file that  
matches localtime's behavior over "localtime".  
  
On the same logic, also discriminate against "posixrules", which  
is another not-really-a-zone file that is often present in the  
timezone directory.  (Since we install "posixrules" but not  
"localtime", this change can affect the behavior of Postgres  
with or without --with-system-tzdata.)  
  
Note that this change doesn't prevent anyone from choosing these  
pseudo-zones if they really want to (i.e., by setting TZ for initdb,  
or modifying the timezone GUC later on).  It just prevents initdb  
from preferring these zone names when there are multiple matches to  
localtime's behavior.  
  
Since we generally prefer to keep timezone-related behavior the  
same in all branches, and since this is arguably a bug fix,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CADT4RqCCnj6FKLisvT8tTPfTP4azPhhDFJqDF1JfBbOH5w4oyQ@mail.gmail.com  
Discussion: https://postgr.es/m/27991.1560984458@sss.pgh.pa.us  

commit   : b9d2c5c7ac800bf20ea6cd4c556b6b3305863a8e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 11:59:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 11:59:00 -0400    

Money values exceeding about 18 digits (depending on lc_monetary)  
could be inaccurately converted to numeric, due to select_div_scale()  
deciding it didn't need to compute any fractional digits.  Force  
its hand by setting the dscale of one division input to equal the  
number of fractional digits we need.  
  
In passing, rearrange the logic to not do useless work in locales  
where money values are considered integral.  
  
Per bug #15925 from Slawomir Chodnicki.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/15925-da9953e2674bb5c8@postgresql.org  

commit   : e829337d42d0e3c73ba9f380e81e51aab4865f8f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 17:23:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 17:23:36 +0200    

Turn most mentions of libpq functions into links.  At id attributes to  
most libpq functions, where not existing yet, so that they can be  
linked to.  (In a handful of cases there were problems with the PDF  
processing toolchain, so those instances were not changed.)  
  
Author: Fabien COELHO <coelho@cri.ensmp.fr>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1905121032330.27203@lancre  

commit   : f4100839a00a9fffb19e70ed2e3c6a73ce2a5259    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 16:50:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 16:50:42 +0200    

When making an xref to a varlistentry, the stylesheets use the first  
<term> as the link text.  In the cases fixed here, the <term> element  
contained extra whitespace that ended up being part of the link text,  
which looked strange in the output in some cases.  This whitespace is  
significant, so remove it since we don't want it.  

commit   : 2e32a7711a8a6e3020c9fb431705dadaed305120    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 14:04:48 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 14:04:48 +0200    

Discussion: https://www.postgresql.org/message-id/517abe28-8a93-5b7a-ff40-b1fd61d33b26%402ndquadrant.com  

commit   : d0f5d25b393747157d35c775e0942a0c68957823    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 14:43:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 14:43:13 +0200    

The ids for linking to libpq functions were previously all lower-case.  
Change to mixed-case, matching the actual function name, for easier  
readability in the source.  The output isn't changed in a significant  
way, since the ids are converted to lower or upper case for file names  
and anchors.  

commit   : 27cd521e6e7084516fbc5e5a8492316b3ba8c25c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 26 Jul 2019 10:01:18 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 26 Jul 2019 10:01:18 +1200    

After starting slapd, wait until it can accept a connection before  
beginning the real test work.  This avoids occasional test failures.  
Back-patch to 11, where the LDAP tests arrived.  
  
Author: Thomas Munro  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/20190719033013.GI1859%40paquier.xyz  

commit   : f63d9e68d4132a4608e9f50782aaacbe5ed6f57a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 25 Jul 2019 14:52:36 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 25 Jul 2019 14:52:36 -0700    

Backpatch: 12-, like the previous commit  

commit   : af3deff3f2ac79585481181cb198b04c67486c09    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 25 Jul 2019 14:22:52 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 25 Jul 2019 14:22:52 -0700    

Since 15d8f8312 we assert that - and since 7ef04e4d2cb2, 4da597edf1  
rely on - the slot type for an expression's  
ecxt_{outer,inner,scan}tuple not changing, unless explicitly flagged  
as such. That allows to either skip deforming (for a virtual tuple  
slot) or optimize the code for JIT accelerated deforming  
appropriately (for other known slot types).  
  
This assumption was sometimes violated for grouping sets, when  
nodeAgg.c internally uses tuplesorts, and the child node doesn't  
return a TTSOpsMinimalTuple type slot. Detect that case, and flag that  
the outer slot might not be "fixed".  
  
It's probably worthwhile to optimize this further in the future, and  
more granularly determine whether the slot is fixed. As we already  
instantiate per-phase transition and equal expressions, we could  
cheaply set the slot type appropriately for each phase.  But that's a  
separate change from this bugfix.  
  
This commit does include a very minor optimization by avoiding to  
create a slot for handling tuplesorts, if no such sorts are  
performed. Previously we created that slot unnecessarily in the common  
case of computing all grouping sets via hashing. The code looked too  
confusing without that, as the conditions for needing a sort slot and  
flagging that the slot type isn't fixed, are the same.  
  
Reported-By: Ashutosh Sharma  
Author: Andres Freund  
Discussion: https://postgr.es/m/CAE9k0PmNaMD2oHTEAhRyxnxpaDaYkuBYkLa1dpOpn=RS0iS2AQ@mail.gmail.com  
Backpatch: 12-, where the bug was introduced in 15d8f8312  

commit   : cb9bb15783f2d6b2e66f7c18bc35e849df623dfa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 14:42:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 14:42:02 -0400    

Per buildfarm.  

commit   : b654714f9bcfb4443bcc531c32f059fd85f798ec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 12:10:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 12:10:54 -0400    

libpq failed to ignore Windows-style newlines in connection service files.  
This normally wasn't a problem on Windows itself, because fgets() would  
convert \r\n to just \n.  But if libpq were running inside a program that  
changes the default fopen mode to binary, it would see the \r's and think  
they were data.  In any case, it's project policy to ignore \r in text  
files unconditionally, because people sometimes try to use files with  
DOS-style newlines on Unix machines, where the C library won't hide that  
from us.  
  
Hence, adjust parseServiceFile() to ignore \r as well as \n at the end of  
the line.  In HEAD, go a little further and make it ignore all trailing  
whitespace, to match what it's always done with leading whitespace.  
  
In HEAD, also run around and fix up everyplace where we have  
newline-chomping code to make all those places look consistent and  
uniformly drop \r.  It is not clear whether any of those changes are  
fixing live bugs.  Most of the non-cosmetic changes are in places that  
are reading popen output, and the jury is still out as to whether popen  
on Windows can return \r\n.  (The Windows-specific code in pipe_read_line  
seems to think so, but our lack of support for this elsewhere suggests  
maybe it's not a problem in practice.)  Hence, I desisted from applying  
those changes to back branches, except in run_ssl_passphrase_command()  
which is new enough and little-tested enough that we'd probably not have  
heard about any problems there.  
  
Tom Lane and Michael Paquier, per bug #15827 from Jorge Gustavo Rocha.  
Back-patch the parseServiceFile() change to all supported branches,  
and the run_ssl_passphrase_command() change to v11 where that was added.  
  
Discussion: https://postgr.es/m/15827-e6ba53a3a7ed543c@postgresql.org  

commit   : 20e99cdddbd3b55257827d621c2f9c592521cd4b    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 25 Jul 2019 11:24:23 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 25 Jul 2019 11:24:23 -0400    

Add a line to the project file setting the target SDK. Otherwise, in for  
example VS2017, if the default but optional 8.1 SDK is not installed the  
build will fail.  
  
Patch from Peifeng Qiu, slightly edited by me.  
  
Discussion: https://postgr.es/m/CABmtVJhw1boP_bd4=b3Qv5YnqEdL696NtHFi2ruiyQ6mFHkeQQ@mail.gmail.com  
  
Backpatch to all live branches.  

commit   : f5a4ab23e42ac35862e3f7dc021a41f41a34386c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 11:02:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 11:02:43 -0400    

As of Fedora 30, it seems that the system-provided macros for setting  
up user privileges in SELinux policies don't grant the ability to read  
/etc/passwd, as they formerly did.  This restriction breaks psql  
(which tries to use getpwuid() to obtain the user name it's running  
under) and thereby the contrib/sepgsql regression test.  Add explicit  
specifications that we need the right to read /etc/passwd.  
  
Mike Palmiotto, per a report from me.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/23856.1563381159@sss.pgh.pa.us  

commit   : 35a34e62ed4974b9178a2dc924d645d6a12e7e9a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 13:58:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 13:58:53 +0200    

commit   : ecbdd009344d3a00733e4382f50137b5e0248ce8    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 24 Jul 2019 18:45:58 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 24 Jul 2019 18:45:58 -0700    

After 277cb789836 ON CONFLICT ... SET ... RETURNING failed with  
ERROR:  virtual tuple table slot does not have system attributes  
when taking the update path, as the slot used to insert into the  
table (and then process RETURNING) was defined to be a virtual slot in  
that commit. Virtual slots don't support system columns except for  
tableoid and ctid, as the other system columns are AM dependent.  
  
Fix that by using a slot of the table's type. Add tests for system  
column accesses in ON CONFLICT ...  RETURNING.  
  
Reported-By: Roby, bisected to the relevant commit by Jeff Janes  
Author: Andres Freund  
Discussion: https://postgr.es/m/73436355-6432-49B1-92ED-1FE4F7E7E100@finefun.com.au  
Backpatch: 12-, where the bug was introduced in 277cb789836  

commit   : c8e177f0bba6bcd9db7180580d58968974d8f6a9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 25 Jul 2019 07:55:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 25 Jul 2019 07:55:23 +0900    

Oversight in 7d81bdc, which introduced a new routine in perl lacking a  
return clause.  Per buildfarm member crake.  
  
Backpatch down to 9.6 like its parent.  
  
Reported-by: Andrew Dunstan  
Discussion: https://postgr.es/m/16da29fa-d504-1380-7095-40de586dc038@2ndQuadrant.com  
Backpatch-through: 9.6  

commit   : 4e784f35145bc6e01d54282afe10d9bb5200ebfe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Jul 2019 18:14:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Jul 2019 18:14:26 -0400    

describeOneTableDetails issued a partition-constraint-fetching query  
for every table, even ones it knows perfectly well are not partitions.  
  
To add insult to injury, it then proceeded to leak the empty PGresult  
if the table wasn't a partition.  Doing that a lot of times might  
amount to a meaningful leak, so this seems like a back-patchable bug.  
  
Fix that, and also fix a related PGresult leak in the partition-parent  
case (though that leak would occur only if we got no row, which is  
unexpected).  
  
Minor code beautification too, to make this code look more like the  
pre-existing code around it.  
  
Back-patch the whole change into v12.  However, the fact that we already  
know whether the table is a partition dates only to commit 1af25ca0c;  
back-patching the relevant changes from that is probably more churn  
than is justified in released branches.  Hence, in v11 and v10, just  
do the minimum to fix the PGresult leaks.  
  
Noted while messing around with adjacent code for yesterday's \d  
improvements.  

commit   : 6655a7299d835dea9e8e0ba69cc5284611b96f29    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 24 Jul 2019 20:24:07 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 24 Jul 2019 20:24:07 +0300    

Otherwise, after a deleted page gets even older, it becomes unrecyclable  
again. B-tree has the same problem, and has had since time immemorial,  
but let's at least fix this in GiST, where this is new.  
  
Backpatch to v12, where GiST page deletion was introduced.  
  
Reviewed-by: Andrey Borodin  
Discussion: https://www.postgresql.org/message-id/835A15A5-F1B4-4446-A711-BF48357EB602%40yandex-team.ru  

commit   : 9eb5607e69933f0a88b6774d1ba728f27afdbd3d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 24 Jul 2019 20:24:05 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 24 Jul 2019 20:24:05 +0300    

The explicit check in gistScanPage() isn't currently really necessary, as  
a deleted page is always empty, so the loop would fall through without  
doing anything, anyway. But it's a marginal optimization, and it gives a  
nice place to attach a comment to explain how it works.  
  
Backpatch to v12, where GiST page deletion was introduced.  
  
Reviewed-by: Andrey Borodin  
Discussion: https://www.postgresql.org/message-id/835A15A5-F1B4-4446-A711-BF48357EB602%40yandex-team.ru  

commit   : 1a721248f3899ccf8c0c7512b91d8458f2394aeb    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 24 Jul 2019 11:41:39 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 24 Jul 2019 11:41:39 -0400    

Windows hosts do not normally come with expr, so instead of using that  
to test the \setshell command, use echo instead, which is fairly  
universally available.  
  
Backpatch to release 11, where this came in.  
  
Problem found by me, patch by Fabien Coelho.  

commit   : fd7d387e0548fd371c06a91d75bc4632541ccfdd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Jul 2019 11:25:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Jul 2019 11:25:43 +0900    

Using pg_receivewal with synchronous_commit = remote_apply set in the  
backend is incompatible if pg_receivewal is a synchronous standby as it  
never applies WAL, so document this problem and solutions to it.  
  
Backpatch to 9.6, where remote_apply has been added.  
  
Author: Robert Haas, Jesper Pedersen  
Reviewed-by: Laurenz Albe, Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/1427a2d3-1e51-9335-1931-4f8853d90d5e@redhat.com  
Backpatch-through: 9.6  

commit   : 7d81bdc8c0ce838efa248928065e9b2da829f981    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Jul 2019 10:53:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Jul 2019 10:53:39 +0900    

Slow buildfarm machines have run into issues with this TAP test caused  
by a race condition related to the startup of a set of standbys, where  
it is possible to finish with an unexpected order in the WAL sender  
array of the primary.  
  
This closes the race condition by making sure that any standby started  
is registered into the WAL sender array of the primary before starting  
the next one based on lookups of pg_stat_replication.  
  
Backpatch down to 9.6 where the test has been introduced.  
  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera, Noah Misch  
Discussion: https://postgr.es/m/20190617055145.GB18917@paquier.xyz  
Backpatch-through: 9.6  

commit   : 5562272a4229cfa57354aa203cffd36b4e7f70cb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 23 Jul 2019 17:22:15 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 23 Jul 2019 17:22:15 -0400    

If the user creates a deferred constraint in a partition, and in a  
transaction they cause the constraint's trigger execution to be deferred  
until commit time *and* drop the constraint, then when commit time comes  
the queued trigger will fail to run because the trigger object will have  
been dropped.  
  
This is explained because when a constraint gets dropped in a  
partitioned table, the recursion to drop the ones in partitions is done  
by the dependency mechanism, not by ALTER TABLE traversing the recursion  
tree as in all other cases.  In the non-partitioned case, this problem  
is avoided by checking that the table is not "in use" by alter-table;  
other alter-table subcommands that recurse to partitions do that check  
for each partition.  But the dependency mechanism doesn't have a way to  
do that.  Fix the problem by applying the same check to all partitions  
during ALTER TABLE's "prep" phase, which correctly raises the necessary  
error.  
  
Reported-by: Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>  
Discussion: https://postgr.es/m/CAKcux6nZiO9-eEpr1ZD84bT1mBoVmeZkfont8iSpcmYrjhGWgA@mail.gmail.com  

commit   : 24f62e93f314c107b4fa679869e5ba9adb2d545f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Jul 2019 17:04:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Jul 2019 17:04:21 -0400    

Include partitioning information much as we do for partitioned tables.  
(However, \d+ doesn't show the partition bounds, because those are  
not stored for indexes.)  
  
In passing, fix a couple of queries to look less messy in -E output.  
  
Also, add some tests for \d on tables with nondefault tablespaces.  
(Somebody previously added a rather silly number of tests for \d  
on partitioned indexes, yet completely neglected other cases.)  
  
Justin Pryzby, reviewed by Fabien Coelho  
  
Discussion: https://postgr.es/m/20190422154902.GH14223@telsasoft.com  

commit   : eb5472da9f83c2e432ac27a053929947e354d20c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Jul 2019 15:25:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Jul 2019 15:25:56 -0400    

Add the name of the owning table to the footers for a TOAST table.  
Also, show all the same footers as for a regular table (in practice,  
this adds the index and perhaps the tablespace and access method).  
  
Justin Pryzby, reviewed by Fabien Coelho  
  
Discussion: https://postgr.es/m/20190422154902.GH14223@telsasoft.com  

commit   : 06140c201b982436974d71e756d7331767a41e57    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 Jul 2019 14:40:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 Jul 2019 14:40:42 +0200    

This sets both LC_COLLATE and LC_CTYPE with one option.  Similar  
behavior is already supported in initdb, CREATE COLLATION, and  
createdb.  
  
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>  
Discussion: https://www.postgresql.org/message-id/flat/d9d5043a-dc70-da8a-0166-1e218e6e34d4%402ndquadrant.com  

commit   : 3cae75f4209bcbb06285544de0f1c59f717a3159    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Jul 2019 14:29:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Jul 2019 14:29:34 +0900    

Oversight in 5f384037.  
  
Author: Álvaro Herrera  
Discussion: https://postgr.es/m/20190722151806.GA22634@alvherre.pgsql  

commit   : a0555ddab9b672a04681ce0d9f6c94104c01b15f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Jul 2019 14:55:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Jul 2019 14:55:22 -0400    

The logic in ATExecDropColumn that rejects dropping partition key  
columns is quite an inadequate defense, because it doesn't execute  
in cases where a column needs to be dropped due to cascade from  
something that only the column, not the whole partitioned table,  
depends on.  That leaves us with a badly broken partitioned table;  
even an attempt to load its relcache entry will fail.  
  
We really need to have explicit pg_depend entries that show that the  
column can't be dropped without dropping the whole table.  Hence,  
add those entries.  In v12 and HEAD, bump catversion to ensure that  
partitioned tables will have such entries.  We can't do that in  
released branches of course, so in v10 and v11 this patch affords  
protection only to partitioned tables created after the patch is  
installed.  Given the lack of field complaints (this bug was found  
by fuzz-testing not by end users), that's probably good enough.  
  
In passing, fix ATExecDropColumn and ATPrepAlterColumnType  
messages to be more specific about which partition key column  
they're complaining about.  
  
Per report from Manuel Rigger.  Back-patch to v10 where partitioned  
tables were added.  
  
Discussion: https://postgr.es/m/CA+u7OA4JKCPFrdrAbOs7XBiCyD61XJxeNav4LefkSmBLQ-Vobg@mail.gmail.com  
Discussion: https://postgr.es/m/31920.1562526703@sss.pgh.pa.us  

commit   : 7961886580a594e519ca7ed1811b464206738be5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 19:28:25 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 19:28:25 +0200    

This reverts commit 09f08930f0f6fd4a7350ac02f29124b919727198.  
  
The buildfarm client needs some adjustments first.  

commit   : 09f08930f0f6fd4a7350ac02f29124b919727198    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 14:40:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 14:40:55 +0200    

Change the defaults for the pg_hba.conf generated by initdb to "peer"  
for local (if supported, else "md5") and "md5" for host.  
  
(Changing from "md5" to SCRAM is left as a separate exercise.)  
  
"peer" is currently not supported on AIX, HP-UX, and Windows.  Users  
on those operating systems will now either have to provide a password  
to initdb or choose a different authentication method when running  
initdb.  
  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/bec17f0a-ddb1-8b95-5e69-368d9d0a3390%40postgresql.org  

commit   : 1e6a759838f7c104f3cd1fe6981a98780da4131b    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 23 Jul 2019 00:14:11 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 23 Jul 2019 00:14:11 +1200    

When we already know the length that we're going to append, then it  
makes sense to use appendBinaryStringInfo instead of  
appendStringInfoString so that the append can be performed with a simple  
memcpy() using a known length rather than having to first perform a  
strlen() call to obtain the length.  
  
Discussion: https://postgr.es/m/CAKJS1f8+FRAM1s5+mAa3isajeEoAaicJ=4e0WzrH3tAusbbiMQ@mail.gmail.com  

commit   : 19781729f789f3c6b2540e02b96f8aa500460322    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 12:05:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 12:05:03 +0200    

Some code could get confused when certain catalog state involving both  
identity and serial sequences was present, perhaps during an attempt  
to upgrade the latter to the former.  Specifically, dropping the  
default of a serial column maintains the ownership of the sequence by  
the column, and so it would then be possible to afterwards make the  
column an identity column that would now own two sequences.  This  
causes the code that looks up the identity sequence to error out,  
making the new identity column inoperable until the ownership of the  
previous sequence is released.  
  
To fix this, make the identity sequence lookup only consider sequences  
with the appropriate dependency type for an identity sequence, so it  
only ever finds one (unless something else is broken).  In the above  
example, the old serial sequence would then be ignored.  Reorganize  
the various owned-sequence-lookup functions a bit to make this  
clearer.  
  
Reported-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://www.postgresql.org/message-id/flat/470c54fc8590be4de0f41b0d295fd6390d5e8a6c.camel@cybertec.at  

commit   : efdcca55a3df27a12efb84a18bce6ea739927b80    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 22 Jul 2019 19:03:12 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 22 Jul 2019 19:03:12 +1200    

In nodeAppend.c and nodeMergeAppend.c there were some foreach loops which  
looped over the list of subplans and only performed any work if the  
subplan index was found in a Bitmapset.  With the old linked list  
implementation of List, this form made sense as accessing the Nth list  
element was O(N).  However, thanks to 1cff1b95a we now have array-based  
lists, so accessing the Nth element has become O(1).  
  
Here we make the most of the O(1) lookups and just loop over the set  
members of the Bitmapset with bms_next_member().  This performs slightly  
better when a small number of the list items are in the Bitmapset.  Micro  
benchmarks show that when the Bitmapset contains all or most of the list  
items then the new code is ever so slightly slower.  In practice, the cost  
is so small that it's drowned out by various other things such as locking  
the relations belonging to each subplan, etc.  
  
The primary goal here is to leave better code examples around which benefit  
better from the new list implementation.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/CAKJS1f8ZcsLVgkF4wOfRyMYTcPgLFiUAOedFC+U2vK_aFZk-BA@mail.gmail.com  

commit   : 23bccc823d434d9dcf3c12622fe260d9235baae2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Jul 2019 10:01:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Jul 2019 10:01:50 +0900    

This is numbered take 7, and addresses a set of issues with code  
comments, variable names and unreferenced variables.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/dff75442-2468-f74f-568c-6006e141062f@gmail.com  

commit   : e1a0f6a983068675813074847e1d0d61bd37ac0e    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 22 Jul 2019 10:29:41 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 22 Jul 2019 10:29:41 +1200    

3373c7155 changed how we determine EquivalenceClasses for relations and  
added an Assert to ensure all relations mentioned in each EC's ec_relids  
was a RELOPT_BASEREL.  However, the join removal code may remove a LEFT  
JOIN and since it does not clean up EC members belonging to the removed  
relations it can leave RELOPT_DEADREL rels in ec_relids.  
  
Fix this by adjusting the Assert to allow RELOPT_DEADREL rels too.  
  
Reported-by: sqlsmith via Andreas Seltenreich  
Discussion: https://postgr.es/m/87y30r8sls.fsf@ansel.ydns.eu  

commit   : 330cafdfaa11ebe53e3e59688acac1577ae0cb34    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Jul 2019 11:42:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Jul 2019 11:42:11 -0400    

Coverity complained about this code, apparently because it uses a local  
array of size FUNC_MAX_ARGS without a guard that the input argument list  
is no longer than that.  (Not sure why it complained today, since this  
code's been the same for a long time; possibly it re-analyzed everything  
the List API change touched?)  
  
Rather than add a guard, though, let's just get rid of the local array  
altogether.  It was only there to avoid list_nth() calls, and those are  
no longer expensive.  

commit   : 90317ab7e64bd2d855c73a6ba579de6d04a7b25c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 21 Jul 2019 22:27:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 21 Jul 2019 22:27:11 +0900    

Several buildfarm members have been complaining about that with gcc,  
like jacana.  Weirdly enough, Visual Studio's compilers do not find this  
issue.  
  
Author: Michael Paquier  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/20190719050830.GK1859@paquier.xyz  

commit   : 3373c7155350cf6fcd51dd090f29e1332901e329    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 21 Jul 2019 17:30:58 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 21 Jul 2019 17:30:58 +1200    

Previously in order to determine which ECs a relation had members in, we  
had to loop over all ECs stored in PlannerInfo's eq_classes and check if  
ec_relids mentioned the relation.  For the most part, this was fine, as  
generally, unless queries were fairly complex, the overhead of performing  
the lookup would have not been that significant.  However, when queries  
contained large numbers of joins and ECs, the overhead to find the set of  
classes matching a given set of relations could become a significant  
portion of the overall planning effort.  
  
Here we allow a much more efficient method to access the ECs which match a  
given relation or set of relations.  A new Bitmapset field in RelOptInfo  
now exists to store the indexes into PlannerInfo's eq_classes list which  
each relation is mentioned in.  This allows very fast lookups to find all  
ECs belonging to a single relation.  When we need to lookup ECs belonging  
to a given pair of relations, we can simply bitwise-AND the Bitmapsets from  
each relation and use the result to perform the lookup.  
  
We also take the opportunity to write a new implementation of  
generate_join_implied_equalities which makes use of the new indexes.  
generate_join_implied_equalities_for_ecs must remain as is as it can be  
given a custom list of ECs, which we can't easily determine the indexes of.  
  
This was originally intended to fix the performance penalty of looking up  
foreign keys matching a join condition which was introduced by 100340e2d.  
However, we're speeding up much more than just that here.  
  
Author: David Rowley, Tom Lane  
Reviewed-by: Tom Lane, Tomas Vondra  
Discussion: https://postgr.es/m/6970.1545327857@sss.pgh.pa.us  

commit   : 894af78f185afee221a6762a1a49057043b7bbf5    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 20 Jul 2019 11:11:55 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 20 Jul 2019 11:11:55 -0700    

Solely relying on a relation's reltuples/relpages estimate to size the  
Bloom filters used by amcheck verification makes verification less  
effective when the estimates are very stale.  In extreme cases,  
verification options that use Bloom filters internally could be totally  
ineffective, without users receiving any clear indication that certain  
types of corruption might easily be missed.  
  
To fix, use RelationGetNumberOfBlocks() instead of relpages to size the  
downlink block Bloom filter.  Use the same RelationGetNumberOfBlocks()  
value to derive a minimum size for the heapallindexed Bloom filter,  
rather than completely trusting reltuples.  Verification will still be  
reasonably effective when the projected/estimated number of Bloom filter  
elements is at least 1/5 of the final number of elements, which is  
assured by the new sizing logic.  
  
Reported-By: Alexander Korotkov  
Discussion: https://postgr.es/m/CAH2-Wzk0ke2J42KrNYBKu0Xovjy-sU5ub7PWjgpbsKdAQcL4OA@mail.gmail.com  
Backpatch: 11-, where downlink/heapallindexed verification were added.  

commit   : a63378a03ec0a53c7c579dfdb3abff57811d8ced    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 18 Jul 2019 12:28:16 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 18 Jul 2019 12:28:16 +0200    

The current extended statistics code was a bit confused which collation  
to use.  When building the statistics, the collations defined as default  
for the data types were used (since commit 5e0928005).  The MCV code was  
however using the column collations for MCV serialization, and then  
DEFAULT_COLLATION_OID when computing estimates. So overall the code was  
using all three possible options, inconsistently.  
  
This uses the column colation everywhere - this makes it consistent with  
what 5e0928005 did for regular stats.  We however do not track the  
collations in a catalog, because we can derive them from column-level  
information.  This may need to change in the future, e.g. after allowing  
statistics on expressions.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  
Backpatch-to: 12  

commit   : e38a55ba46bbd2510baccdbaa01298cbca972b88    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 Jul 2019 16:28:28 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 Jul 2019 16:28:28 +0200    

The examine_opclause_expression function needs to return information on  
which side of the operator we found the Var, but the variable was called  
"isgt" which is rather misleading (it assumes the operator is either  
less-than or greater-than, but it may be equality or something else).  
Other places in the planner use a variable called "varonleft" for this  
purpose, so just adopt the same convention here.  
  
The code also assumed we don't care about this flag for equality, as  
(Var = Const) and (Const = Var) should be the same thing. But that does  
not work for cross-type operators, in which case we need to pass the  
parameters to the procedure in the right order. So just use the same  
code for all types of expressions.  
  
This means we don't need to care about the selectivity estimation  
function anymore, at least not in this code. We should only get the  
supported cases here (thanks to statext_is_compatible_clause).  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  
Backpatch-to: 12  

commit   : 6f40ee4f837ec1ac59c8ddc73b67a04978a184d5    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 19 Jul 2019 13:24:33 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 19 Jul 2019 13:24:33 -0700    

Make pgss_post_parse_analyze() more consistent with the other hooks,  
and avoid unnecessary overhead when pg_stat_statements.track=none.  
  
Author: Raymond Martin  
Reviewed-by: Fabien COELHO  
Discussion: https://postgr.es/m/BN8PR21MB1217B003C4F79DE230AA36B9B1580%40BN8PR21MB1217.namprd21.prod.outlook.com  

commit   : 421466863548de58199c7c6ececaae6b5f621b2f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Jul 2019 14:48:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Jul 2019 14:48:57 -0400    

Absorb commit e5e04c962a5d12eebbf867ca25905b3ccc34cbe0 from upstream  
IANA code, in hopes of silencing warnings from MSVC about negating  
a bool value.  
  
Discussion: https://postgr.es/m/20190719035347.GJ1859@paquier.xyz  

commit   : 1300fa66b2f3d0dcd2eed7a5eff9e3fc22807f7c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Jul 2019 11:42:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Jul 2019 11:42:33 +0900    

16828d5 has improved ALTER TABLE so as a column addition does not  
require a rewrite for a non-NULL default with constant expressions, but  
one spot in the documentation did not get updated consistently.  
The documentation also now clarifies the fact that this does not apply  
if the expression is volatile, where a table rewrite is still required.  
  
Reported-by: Daniel Westermann  
Author: Ian Barwick  
Reviewed-by: Michael Paquier, Daniel Westermann  
Discussion: https://postgr.es/m/DB6PR0902MB2184C7D5645CF15D75EB7957D2CF0@DB6PR0902MB2184.eurprd09.prod.outlook.com  
Backpatch-through: 11  

commit   : 5f3840370b63fdf17f704a285623ccc233fa8d4f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Jul 2019 09:31:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Jul 2019 09:31:58 +0900    

The existing facility of vacuumdb to handle parallel connections into a  
given database with an authentication set is moved to a common file in  
src/bin/scripts/, named scripts_parallel.c.  This introduces a set of  
routines to initialize, wait and terminate a set of connections,  
simplifying a bit the code of vacuumdb on the way.  More routines  
related to result handling and database connection are moved to  
common.c.  
  
The initial plan is to use that for reindexdb, but it could be applied  
to other tools like clusterdb.  
  
While on it, clean up a set of variables "progname" which were defined  
as routine arguments for error messages.  Since most of the callers have  
switched to pg_log_error() and such there is no need for this variable.  
  
Author: Julien Rouhaud  
Reviewed-by: Michael Paquier, Álvaro Herrera  
Discussion: https://postgr.es/m/CAOBaU_YrnH_Jqo46NhaJ7uRBiWWEcS40VNRQxgFbqYo9kApUsg@mail.gmail.com  

commit   : b538c90b1bded5464787e2b8e4431302d24eb601    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 Jul 2019 16:38:39 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 Jul 2019 16:38:39 -0700    

I was careless passing a datum directly to DATE_NOT_FINITE without  
calling DatumGetDateADT() first.  
  
Backpatch-through: 9.4  

commit   : 70a33b21099c046dc38f07ffb02b1e0cf2aff91d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Jul 2019 08:50:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Jul 2019 08:50:14 +0900    

Noticed while browsing the code.  

commit   : e6feef571a016c9dac52a01aebad484768eb5c68    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 Jul 2019 12:42:39 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 Jul 2019 12:42:39 -0700    

The values 'infinity' and '-infinity' are a part of the DATE type  
itself, so a bound of the date 'infinity' is not the same as an  
unbounded/infinite range. However, it is still wrong to try to  
canonicalize such values, because adding or subtracting one has no  
effect. Fix by treating 'infinity' and '-infinity' the same as  
unbounded ranges for the purposes of canonicalization (but not other  
purposes).  
  
Backpatch to all versions because it is inconsistent with the  
documented behavior. Note that this could be an incompatibility for  
applications relying on the behavior contrary to the documentation.  
  
Author: Laurenz Albe  
Reviewed-by: Thomas Munro  
Discussion: https://postgr.es/m/77f24ea19ab802bc9bc60ddbb8977ee2d646aec1.camel%40cybertec.at  
Backpatch-through: 9.4  

commit   : d004147eb3ece6b5981dbdd3d918ffc3f23fc505    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 18 Jul 2019 13:22:56 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 18 Jul 2019 13:22:56 -0700    

Commit 857f9c36cda, which taught nbtree VACUUM to avoid unnecessary  
index scans, bumped the nbtree version number from 2 to 3, while adding  
the ability for nbtree indexes to be upgraded on-the-fly.  Various  
assertions that assumed that an nbtree index was always on version 2 had  
to be changed to accept any supported version (version 2 or 3 on  
Postgres 11).  
  
However, a few assertions were missed in the initial commit, all of  
which were in code paths that cache a local copy of the metapage  
metadata, where the index had been expected to be on the current version  
(no longer version 2) as a generic sanity check.  Rather than simply  
update the assertions, follow-up commit 0a64b45152b intentionally made  
the metapage caching code update the per-backend cached metadata version  
without changing the on-disk version at the same time.  This could even  
happen when the planner needed to determine the height of a B-Tree for  
costing purposes.  The assertions only fail on Postgres v12 when  
upgrading from v10, because they were adjusted to use the authoritative  
shared memory metapage by v12's commit dd299df8.  
  
To fix, remove the cache-only upgrade mechanism entirely, and update the  
assertions themselves to accept any supported version (go back to using  
the cached version in v12).  The fix is almost a full revert of commit  
0a64b45152b on the v11 branch.  
  
VACUUM only considers the authoritative metapage, and never bothers with  
a locally cached version, whereas everywhere else isn't interested in  
the metapage fields that were added by commit 857f9c36cda.  It seems  
unlikely that this bug has affected any user on v11.  
  
Reported-By: Christoph Berg  
Bug: #15896  
Discussion: https://postgr.es/m/15896-5b25e260fdb0b081%40postgresql.org  
Backpatch: 11-, where VACUUM was taught to avoid unnecessary index scans.  

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

Now that commit fec0778c8 drew a clear line between public and private  
fields in SPITupleTable, it seems pretty silly that the count of valid  
tuples isn't on the public side of that line.  The reason why not was  
that there wasn't such a count.  For reasons lost in the mists of time,  
spi.c preferred to keep a count of remaining free entries in the array.  
But that seems pretty pointless: it's unlike the way we handle similar  
code everywhere else, and it involves extra subtractions that surely  
outweigh having to do a comparison rather than test-for-zero to check  
for array-full.  
  
Hence, rearrange so that this code does the expansible array logic  
the same as everywhere else, with a count of valid entries alongside  
the allocated array length.  And document the count as public.  
  
I looked for core-code callers where it would make sense to start  
relying on tuptable->numvals rather than the separate SPI_processed  
variable.  Right now there don't seem to be places where it'd be  
a win to do so without more code restructuring than I care to  
undertake today.  In principle, though, having SPITupleTables be  
fully self-contained should be helpful down the line.  
  
Discussion: https://postgr.es/m/16852.1563395722@sss.pgh.pa.us  

commit   : 7d24f6a49076f975ca87926b3cde8fdea3448ecb    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 Jul 2019 18:16:50 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 Jul 2019 18:16:50 +0200    

When evaluating clauses on a multivariate MCV list, we build a bitmap  
tracking how the clauses match each item of the MCV list.  When updating  
the bitmap we need to consider the current value (tracking how the item  
matches preceding clauses), match for the current clause and whether the  
clauses are connected by AND or OR.  
  
Until now the logic was copied on every place updating the bitmap, which  
was not quite readable.  So just move it to a separate function and call  
it where needed.  
  
Backpatch to 12, where the code was introduced. While not a bugfix, this  
should make maintenance and future backpatches easier.  
  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  

commit   : e4deae7396f2a5576c0c8289e2bfc005ed3d6989    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 15 Jul 2019 02:00:31 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 15 Jul 2019 02:00:31 +0200    

There were two issues in how the extended statistics handled NULL values  
in opclauses. Firstly, the code was oblivious to the possibility that  
Const may be NULL (constisnull=true) in which case the constvalue is  
undefined. We need to treat this as a mismatch, and not call the proc.  
  
Secondly, the MCV item itself may contain NULL values too - the code  
already did check that, and updated the match bitmap accordingly, but  
failed to ensure we won't call the operator procedure anyway. It did  
work for AND-clauses, because in that case false in the bitmap stops  
evaluation of further clauses. But for OR-clauses ir was not easy to  
get incorrect estimates or even trigger a crash.  
  
This fixes both issues by extending the existing check so that it looks  
at constisnull too, and making sure it skips calling the procedure.  
  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  

commit   : e8b6ae2130e3a95bb776708a9a7c9cb21fe8ac87    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 13 Jul 2019 00:12:16 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 13 Jul 2019 00:12:16 +0200    

We expect opclauses to have exactly one Var and one Const, but the code  
was checking the Const by calling is_pseudo_constant_clause() which is  
incorrect - we need a proper constant.  
  
Fixed by using plain IsA(x,Const) to check type of the node. We need to  
do these checks in two places, so move it into a separate function that  
can be called in both places.  
  
Reported by Andreas Seltenreich, based on crash reported by sqlsmith.  
  
Backpatch to v12, where this code was introduced.  
  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  
Backpatch-to: 12  

commit   : a4303a078c661ebafe8c8c2167b2ad9bf16b32ce    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 Jul 2019 18:13:39 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 Jul 2019 18:13:39 +0200    

The TYPECACHE_GT_OPR is not needed (it used to be in older version of  
the MCV code), but the compiler failed to detect this as the result was  
used in a fmgr_info() call, populating a FmgrInfo entry.  
  
Backpatch to v12, where this code was introduced.  
  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  
Backpatch-to: 12  

commit   : 21039555cdec75836d246fcbcd4b44ee63dabfad    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 17 Jul 2019 19:39:54 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 17 Jul 2019 19:39:54 -0700    

Author: Brad DeJong  
Discussion: https://postgr.es/m/CAJnrtnxDYOQFsDfWz2iri0T_fFL2ZbbzgCOE=4yaMcszgcsf4A@mail.gmail.com  
Backpatch: 12-  

commit   : 1c1602b8b685a68796f8ba48e41f778c0c42ba43    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jul 2019 10:05:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jul 2019 10:05:59 +0900    

The documentation mentioned that data checksums cannot be changed after  
initialization, which is not true as pg_checksums can do that with its  
--enable option introduced in v12.  This simply removes the sentence  
telling so.  
  
Reported-by: Basil Bourque  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/15909-e9d74271f1647472@postgresql.org  
Backpatch-through: 12  

commit   : 93907478e15f5762800b6acbe2eff03167843874    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 19:15:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 19:15:21 -0400    

Brazil no longer observes DST.  
Historical corrections for Palestine, Hong Kong, and Italy.  

commit   : f285322f9cd3145ea2e5b870e6ba7e0c641422ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 18:26:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 18:26:23 -0400    

A large fraction of this diff is just due to upstream's somewhat  
random decision to rename a bunch of internal variables and struct  
fields.  However, there is an interesting new feature in zic:  
it's grown a "-b slim" option that emits zone files without 32-bit  
data and other backwards-compatibility hacks.  We should consider  
whether we wish to enable that.  

commit   : fec0778c8098cebec2d5cb3674ac7151d8d95638    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 14:55:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 14:55:13 -0400    

The fields that we consider public are "tupdesc" and "vals", which  
historically are in the middle of the struct.  Move them to the front  
(this should be perfectly safe to do in HEAD) and add comments to make  
it quite clear which fields are public or not.  
  
Also adjust spi.sgml's documentation of the struct to match.  
That doc had bit-rotted somewhat, as it was missing some fields.  
(Arguably we should just remove all the private fields from the docs,  
but for now I refrained.)  
  
Daniel Gustafsson, reviewed by Fabien Coelho  
  
Discussion: https://postgr.es/m/0D19F836-B743-4340-B6A2-F148CA3DD1F0@yesql.se  

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

At least on Fedora and RHEL, it's not in the same RPM that's needed  
for building sepgsql itself.  Today is the second or third time I've  
had to rediscover how to install that, so let's document it this time.  

commit   : 82c8a3c52adfd993b72289bfa8739f97216a06df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 13:04:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 13:04:59 -0400    

The aggregate-order difference explained in my previous commit  
turns out to also affect the order of log entries emitted in the  
contrib/sepgsql regression test.  Per buildfarm.  
  
Discussion: https://postgr.es/m/21272.1563318411@sss.pgh.pa.us  

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.