PostgreSQL 11.5 commit log

commit   : fdf16779f107dd22a2cb8430d2eee6c344b34187    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Aug 2019 17:14:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Aug 2019 17:14:59 -0400    

commit   : d03c0413343ac5a79bc2f6ee5abc84c873efd863    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Aug 2019 11:49:14 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Aug 2019 11:49:14 -0400    

Security: CVE-2019-10208, CVE-2019-10209  

commit   : a034418cfc85fffa300d4d44792561c09e76f68b    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Aug 2019 11:20:21 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 21f94c51f680cefa2ea6b0d94aa8a967a375afc6    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 5 Aug 2019 07:48:41 -0700    
  
committer: Noah Misch <[email protected]>    
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   : b0fb44eacd8f96f48d3589f1a066fdd75947b4bd    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 5 Aug 2019 15:50:23 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 5 Aug 2019 15:50:23 +0200    

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

commit   : 6dad61dc76ea5ef35a437bf881e48cf46df67e29    
  
author   : Michael Paquier <[email protected]>    
date     : Mon, 5 Aug 2019 14:30:16 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Mon, 5 Aug 2019 14:30:16 +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/[email protected]  
Backpatch-through: 9.6  

commit   : 7a5e39ec94814c0df595e896a62a765a260da517    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 4 Aug 2019 17:08:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 4 Aug 2019 17:08:41 -0400    

commit   : e8b639357f0a9d9543578ac9331a8b33dcc4f25f    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 4 Aug 2019 14:05:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 4 Aug 2019 14:05:35 -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/[email protected]  

commit   : 45d6789e78dc2997292a528e2538fa496485b85f    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 4 Aug 2019 13:07:12 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : e3967a16d3a0b9c1c6ca20edccc2696e313127e9    
  
author   : Alvaro Herrera <[email protected]>    
date     : Sun, 4 Aug 2019 11:18:45 -0400    
  
committer: Alvaro Herrera <[email protected]>    
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 <[email protected]>  
Reviewed-by: Amit Langote <[email protected]>  
Discussion: https://postgr.es/m/[email protected]  

commit   : 082c9f5f761ced18a6f014f2638096f6a8228164    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 2 Aug 2019 16:18:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 2 Aug 2019 16:18:46 -0400    

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  

commit   : a7eb28d0caa8db3e81e46921afc6cca5e4cf388a    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 1 Aug 2019 09:38:02 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 1 Aug 2019 09:38:02 +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/[email protected]  
Backpatch-through: 9.4  

commit   : c64e2970592c623af9d8c8205004b4b18ff3c5f0    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 31 Jul 2019 15:42:50 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 31 Jul 2019 15:42:50 -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/[email protected]  

commit   : a6380f8a4b424cf097a066b45b91fa43d367c562    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 30 Jul 2019 21:14:14 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
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   : 4dbf70b2ff1ee487923394fd9e4fb28bb78839f2    
  
author   : Tomas Vondra <[email protected]>    
date     : Tue, 30 Jul 2019 19:17:12 +0200    
  
committer: Tomas Vondra <[email protected]>    
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/[email protected]  
Reported-by: Justin Pryzby  

commit   : 0dcb1c6c4874d2d464d426ded208b58b01e52174    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 29 Jul 2019 18:49:04 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 0ef70bbaddb6b725c1d0d72bcf607ef9fdba0c1c    
  
author   : Thomas Munro <[email protected]>    
date     : Mon, 29 Jul 2019 10:12:37 +1200    
  
committer: Thomas Munro <[email protected]>    
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   : 0e8f927fa6bb428975645337d19ab33b348cef86    
  
author   : Michael Paquier <[email protected]>    
date     : Sun, 28 Jul 2019 22:02:34 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 28 Jul 2019 22:02:34 +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/[email protected]  
Backpatch-through: 9.4  

commit   : 66abcce55f12641b0a5fd03be61c17362038c659    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 26 Jul 2019 17:46:40 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 26 Jul 2019 17:46:40 -0400    

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

commit   : e991b6cce3f26d979a2a47792526f3785bac116b    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 26 Jul 2019 15:17:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 26 Jul 2019 15:17:03 -0400    

pgbench would sometimes get stuck waiting forever after its last  
client thread terminated, due to failing to check for there being  
nothing more to wait for.  
  
Bug introduced during refactoring in v10 (I didn't bother to try to  
assign blame to a specific commit).  It's already repaired in  
HEAD/v12 thanks to commit 3bac77c48, but v10 and v11 need this fix.  
  
Fabien Coelho, per report from Tomas Vondra; reviewed by  
Yoshikazu Imai  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : d304313b071a8314dea8a116271d66172536fe13    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 26 Jul 2019 13:07:08 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 4459266bf0d3d1873d0304584757c17e0bce732c    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 26 Jul 2019 12:45:32 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : ca918f99aaa5fe108248ea2380f637bab09a88c2    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 26 Jul 2019 11:59:00 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 77d5dea386f5747ca56bac1ae745e4604111adda    
  
author   : Thomas Munro <[email protected]>    
date     : Fri, 26 Jul 2019 10:01:18 +1200    
  
committer: Thomas Munro <[email protected]>    
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   : e465d9d4058884e848571f3a59c541feb030a7b2    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2019 14:42:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2019 14:42:02 -0400    

Per buildfarm.  

commit   : 11a0a4db3cdb93a5b645b802f908dae53b5bb892    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2019 12:10:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2019 12:10:55 -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/[email protected]  

commit   : fe9e632846a1888b93699d08c7513b35fcce63fb    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 25 Jul 2019 11:24:23 -0400    
  
committer: Andrew Dunstan <[email protected]>    
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   : 5a1c61bdf4c010dd4de197e3fd1678f518f10f75    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2019 11:02:43 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 917e817ec24ffdded5adfa4e1dfc14f574844929    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 25 Jul 2019 07:55:33 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 25 Jul 2019 07:55:33 +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/[email protected]  
Backpatch-through: 9.6  

commit   : cff13efb4a7185bfdd95c96b1c61b2090e515be4    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 24 Jul 2019 18:14:26 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 1357181d46249d211837e1df7a49ee1131027a99    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 24 Jul 2019 11:41:39 -0400    
  
committer: Andrew Dunstan <[email protected]>    
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   : 059e22693b2312cd091e5afe5800cedc6abd14b8    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 24 Jul 2019 11:26:29 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 24 Jul 2019 11:26:29 +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/[email protected]  
Backpatch-through: 9.6  

commit   : ca553394b2efcf0a551b1fe2ae82a1515f90f2cb    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 24 Jul 2019 10:54:26 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 24 Jul 2019 10:54:26 +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/[email protected]  
Backpatch-through: 9.6  

commit   : ec7f9a7407d3f6e0d27033b026bcb966eebe8e71    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 23 Jul 2019 17:22:15 -0400    
  
committer: Alvaro Herrera <[email protected]>    
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 <[email protected]>  
Discussion: https://postgr.es/m/CAKcux6nZiO9-eEpr1ZD84bT1mBoVmeZkfont8iSpcmYrjhGWgA@mail.gmail.com  

commit   : 8d21512dc34f04c43a1a3d453967b88b2edcd8cc    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 22 Jul 2019 17:14:22 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 22 Jul 2019 17:14:22 -0400    

Remove "set -x", and pass "-A trust" to initdb explicitly,  
to suppress almost all of the noise this script used to emit  
on stderr.  
  
Back-patch of commit eb9812f27 into all active branches.  
  
Discussion: https://postgr.es/m/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 6cdefc82ba9db66e9a9e185bd4b1dc52a0ffc708    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 22 Jul 2019 14:55:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 22 Jul 2019 14:55:23 -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/[email protected]  

commit   : 577c8802d350e76bb0bb2b7ce5bcac551abd90d1    
  
author   : Peter Geoghegan <[email protected]>    
date     : Sat, 20 Jul 2019 11:11:52 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Sat, 20 Jul 2019 11:11:52 -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   : ee9417a04fba50b72289c746caf4cbd3fa818bb9    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 19 Jul 2019 14:48:57 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 80aa66392ec8264cad6b2ad1bb442238c8771a6d    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 19 Jul 2019 11:43:11 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 19 Jul 2019 11:43:11 +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   : 477ebfc9695e267d3f345a77211579236bcac91c    
  
author   : Jeff Davis <[email protected]>    
date     : Thu, 18 Jul 2019 16:45:03 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Thu, 18 Jul 2019 16:45:03 -0700    

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

commit   : f5f20deda33ba4146d68071193289f99c8a5d6c8    
  
author   : Jeff Davis <[email protected]>    
date     : Thu, 18 Jul 2019 14:01:17 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Thu, 18 Jul 2019 14:01:17 -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   : 6523f2ed34413ffcbee8b20d01b0101d9e7dd9c1    
  
author   : Peter Geoghegan <[email protected]>    
date     : Thu, 18 Jul 2019 13:22:53 -0700    
  
committer: Peter Geoghegan <[email protected]>    
date     : Thu, 18 Jul 2019 13:22:53 -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   : bcafb675a0097cbf3b437e04369ccd571a65fc46    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 17 Jul 2019 19:15:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 17 Jul 2019 19:15:21 -0400    

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

commit   : 1d1ff50d27cf32e37c5294c34d84dd4225db99a9    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 17 Jul 2019 18:26:23 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 46e2a18d0dfd140bfa36e5d543feeac5f5600244    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 16 Jul 2019 18:17:47 -0400    
  
committer: Tom Lane <[email protected]>    
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   : c83067d7eac0bad956e3e4db02dfdfbf4a99db61    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 15 Jul 2019 20:57:24 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 15 Jul 2019 20:57:24 -0400    

Reported-by: Ian Barwick  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.4  

commit   : f757d89e88e83eb93498fd161d2c24977ef28a3d    
  
author   : Thomas Munro <[email protected]>    
date     : Sun, 14 Jul 2019 14:19:54 +1200    
  
committer: Thomas Munro <[email protected]>    
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   : 5c1b7edc23a01afedc10702f06b6e0da7b0c56f6    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 12 Jul 2019 16:24:59 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 757f1baa8c13ffe7abd7b0f49f787a1c007cdf89    
  
author   : David Rowley <[email protected]>    
date     : Fri, 12 Jul 2019 19:10:12 +1200    
  
committer: David Rowley <[email protected]>    
date     : Fri, 12 Jul 2019 19:10:12 +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   : 5918b82614513e1262c6c3ed286e4e1212a01bc3    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 10 Jul 2019 08:58:41 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 10 Jul 2019 08:58:41 -0400    

Per gripe from Phil Bayer.  
  
Authors: Amit Langote and others  
Discussion: https://postgr.es/m/[email protected]  

commit   : 2ede93de9e80f0f39276c0afabf1621d21180370    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 10 Jul 2019 09:01:28 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 10 Jul 2019 09:01:28 -0400    

REL_11_STABLE's configure does not select C99 mode by default, so using  
C99 block initializer broke the build for some compilers.  Revert to C89  
in that branch.  
  
Author: Michaël Paquier  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1cde7fe84a479113127596e46e070f07ac6f09d0    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 10 Jul 2019 15:15:07 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 10 Jul 2019 15:15:07 +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/[email protected]  
Backpatch-through: 9.4  

commit   : 9509173d24309b4ef46790921c07dc4084b6bc62    
  
author   : Thomas Munro <[email protected]>    
date     : Wed, 10 Jul 2019 10:15:54 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Wed, 10 Jul 2019 10:15:54 +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   : 1637d959d618886ac6ca59cc3c3785ce5ba06b40    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 9 Jul 2019 17:16:36 -0400    
  
committer: Alvaro Herrera <[email protected]>    
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/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 3955c50f3762be6f0a63573c5b4efef72b30dc2b    
  
author   : Thomas Munro <[email protected]>    
date     : Tue, 9 Jul 2019 18:24:33 +1200    
  
committer: Thomas Munro <[email protected]>    
date     : Tue, 9 Jul 2019 18:24:33 +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   : 1b6c2b9d99b6db34b32629fdd86530f93c07bdee    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 8 Jul 2019 14:28:42 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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 <[email protected]>  
Discussion: https://www.postgresql.org/message-id/flat/CAJSLCQ13==D8Ka2YLyctTm0Y+8MhGYcX_zj7fU0rqRzhcV++3w@mail.gmail.com  

commit   : 24c5c711f497c995ad7b560aedd41b4d0f0f77f4    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 3 Jul 2019 18:08:53 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 133f5ae214de4a9aed7bfb138ea72ad7926262e2    
  
author   : David Rowley <[email protected]>    
date     : Wed, 3 Jul 2019 23:45:42 +1200    
  
committer: David Rowley <[email protected]>    
date     : Wed, 3 Jul 2019 23:45:42 +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   : 721963f24ae8c2097bb7c44cc0f428740f6cf2a7    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 3 Jul 2019 08:57:39 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 3 Jul 2019 08:57:39 +0900    

This adjusts 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  
Backpatch-through: 9.4  

commit   : 074add6ed286a02256a1b03137ff6dd7c8126f25    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 2 Jul 2019 13:35:14 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 4b85f20f948d885875a1e1b89979e627b86e6e64    
  
author   : Noah Misch <[email protected]>    
date     : Sun, 30 Jun 2019 17:34:17 -0700    
  
committer: Noah Misch <[email protected]>    
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/[email protected]  

commit   : 05dc5f4767e1c5ed157b2870f05d57f3378302f4    
  
author   : Andrew Gierth <[email protected]>    
date     : Sun, 30 Jun 2019 23:49:23 +0100    
  
committer: Andrew Gierth <[email protected]>    
date     : Sun, 30 Jun 2019 23:49:23 +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   : 43085a4f693e35d674a9965c484e4e87f18f6d29    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 28 Jun 2019 14:51:08 -0400    
  
committer: Alvaro Herrera <[email protected]>    
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/[email protected]  

commit   : 6827e46cdf351678f71577efd4736f5d443b6e01    
  
author   : Thomas Munro <[email protected]>    
date     : Fri, 28 Jun 2019 11:11:26 +1200    
  
committer: Thomas Munro <[email protected]>    
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   : 803cdf22a2d395653496702af789ccae7c17e18c    
  
author   : Tomas Vondra <[email protected]>    
date     : Thu, 27 Jun 2019 18:14:25 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Thu, 27 Jun 2019 18:14:25 +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   : e4f2d4fe9269c3c9c33f5182d4c3c90f99587fb4    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 27 Jun 2019 11:57:10 -0400    
  
committer: Alvaro Herrera <[email protected]>    
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   : 9653ca2197e241ebeae127086ce1cc8b201a477e    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 26 Jun 2019 18:38:51 -0400    
  
committer: Alvaro Herrera <[email protected]>    
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/[email protected]  
Author: Álvaro Herrera  
Reviewed-by: Amit Langote  

commit   : 0e08a3a1f541228e312111eda5122f6004fe7dbf    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 26 Jun 2019 23:04:32 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 26 Jun 2019 23:04:32 +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/[email protected]  
Backpatch-through: 9.4  

commit   : bf270892f1be2713d47d7a9c452b5ea17d39af8e    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 25 Jun 2019 23:06:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 25 Jun 2019 23:06:17 -0400    

contrib/amcheck didn't get the memo either.  

commit   : 52cdbdc42c23e4f9ae1e62e95bd85d11c030d3f6    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 25 Jun 2019 11:15:38 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 25 Jun 2019 11:15:38 +0900    

This could trigger valgrind failures when doing ambiguous function name  
lookups when no arguments are provided by the caller.  The problem has  
been introduced in aefeb68, so backpatch to v10.  HEAD is fine thanks to  
the refactoring done in bfb456c1.  
  
Reported-by: Alexander Lakhin  
Author: Alexander Lakhin, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 10  

commit   : 2839bf3538e764c559f79d3cc8f57d5e7b580741    
  
author   : Thomas Munro <[email protected]>    
date     : Tue, 25 Jun 2019 09:29:53 +1200    
  
committer: Thomas Munro <[email protected]>    
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   : be5676f4143dd4f01b754ff48966011577f42bfd    
  
author   : Thomas Munro <[email protected]>    
date     : Tue, 25 Jun 2019 09:17:04 +1200    
  
committer: Thomas Munro <[email protected]>    
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   : afaf48afb107b58863d098a4bebf97f78971c1fe    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 24 Jun 2019 16:43:05 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : 40dde829070ddebd3f8bbf06d8e1cc4bff2e0c06    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 22 Jun 2019 20:31:50 -0400    
  
committer: Tom Lane <[email protected]>    
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/[email protected]  

commit   : a40dca815dd1d703623f774059b103a13f85e0f1    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 21 Jun 2019 20:34:23 -0700    
  
committer: Noah Misch <[email protected]>    
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/[email protected]  

commit   : f7aebd7f74117a9b44eb6af575061fc16a728236    
  
author   : Thomas Munro <[email protected]>    
date     : Fri, 21 Jun 2019 10:57:07 +1200    
  
committer: Thomas Munro <[email protected]>    
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   : 6dfc9464472ec283cf6b13ee67b42afc6346c533    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 19 Jun 2019 11:02:28 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 19 Jun 2019 11:02:28 +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/[email protected]  
Backpatch-through: 11  

commit   : 5246d3e791033267516b66ce3518f9cc6c23c261    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 18 Jun 2019 18:23:16 -0400    
  
committer: Alvaro Herrera <[email protected]>    
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/[email protected]  
Discussion: https://postgr.es/m/[email protected]  

commit   : 14d8b539d3bd4cf9faf65ca86a733bada202107f    
  
author   : Thomas Munro <[email protected]>    
date     : Tue, 18 Jun 2019 22:38:30 +1200    
  
committer: Thomas Munro <[email protected]>    
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