PostgreSQL 9.5.19 commit log

Stamp 9.5.19.

commit   : 167e5353799eabb034817b1e7bafd674d3c2bb04    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Aug 2019 17:20:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Aug 2019 17:20:40 -0400    

Click here for diff

M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc

Last-minute updates for release notes.

commit   : e3d8c9a5f1014be97150d07b3e5af1d32a45df65    
  
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    

Click here for diff

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

M doc/src/sgml/release-9.5.sgml

Require the schema qualification in pg_temp.type_name(arg).

commit   : 752fa3dbfc36c70a692986b56daac41410fca3f6    
  
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    

Click here for diff

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  

M doc/src/sgml/config.sgml
M src/backend/catalog/namespace.c
M src/backend/parser/parse_func.c
M src/backend/parser/parse_type.c
M src/backend/utils/adt/ruleutils.c
M src/include/catalog/namespace.h
M src/include/parser/parse_type.h
M src/test/regress/expected/temp.out
M src/test/regress/sql/temp.sql

Translation updates

commit   : 0e9e7e28902ca0a01b0d36cbdd155abe4ea63cfe    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 5 Aug 2019 15:36:58 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 5 Aug 2019 15:36:58 +0200    

Click here for diff

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

M src/backend/po/ru.po
M src/bin/initdb/po/ru.po
M src/bin/scripts/po/ru.po
M src/interfaces/libpq/po/ru.po

Release notes for 11.5, 10.10, 9.6.15, 9.5.19, 9.4.24.

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

Click here for diff

M doc/src/sgml/release-9.5.sgml

Fix handling of previous password hooks in passwordcheck

commit   : 4536e494fdf2d6ec493751a193f8086d327848d6    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 1 Aug 2019 09:38:25 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 1 Aug 2019 09:38:25 +0900    

Click here for diff

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  

M contrib/passwordcheck/passwordcheck.c

Fix pg_dump's handling of dependencies for custom opclasses.

commit   : 9dd74ba5aebc83341795fcb568b0e1f97cc2eb5d    
  
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    

Click here for diff

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]  

M src/bin/pg_dump/pg_dump.c

Print WAL position correctly in pg_rewind error message.

commit   : ee3f036861228f3d85cd9cbb8d158f7209770ccd    
  
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    

Click here for diff

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.  

M src/bin/pg_rewind/parsexlog.c

Doc: Fix event trigger firing table

commit   : d452d0cf6fd37bc7a59f9604a4ad06a2d86cf44e    
  
author   : Michael Paquier <[email protected]>    
date     : Sun, 28 Jul 2019 22:02:50 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Sun, 28 Jul 2019 22:02:50 +0900    

Click here for diff

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  

M doc/src/sgml/event-trigger.sgml

Tweak our special-case logic for the IANA "Factory" timezone.

commit   : f227aecb9af753aa559ed488815a94d95fa38b0a    
  
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    

Click here for diff

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]  

M src/backend/utils/adt/datetime.c
M src/timezone/zic.c

Avoid choosing "localtime" or "posixrules" as TimeZone during initdb.

commit   : 9ef8117420d49ee70d50b19a862607def58ab560    
  
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    

Click here for diff

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]  

M src/bin/initdb/findtimezone.c

Fix loss of fractional digits for large values in cash_numeric().

commit   : 13e493cf68a4ed8a54e974c41470fab43676e67c    
  
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    

Click here for diff

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]  

M src/backend/utils/adt/cash.c
M src/test/regress/expected/money.out
M src/test/regress/sql/money.sql

Fix syntax error in commit 20e99cddd.

commit   : 4583605e6d1f2b95a61dfe0c1fdfba99a88e3c4a    
  
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    

Click here for diff

Per buildfarm.  

M src/tools/msvc/MSBuildProject.pm

Fix failures to ignore \r when reading Windows-style newlines.

commit   : 6266654db7fa7bafacd9f1baf94c1cfdd8c09f97    
  
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    

Click here for diff

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]  

M src/interfaces/libpq/fe-connect.c

Honor MSVC WindowsSDKVersion if set

commit   : 4f435f78d536203555fbbb670f103a54f4fcbe11    
  
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    

Click here for diff

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.  

M src/tools/msvc/MSBuildProject.pm

Fix contrib/sepgsql test policy to work with latest SELinux releases.

commit   : b22e249837ad51753476186dd1e80a18f598992f    
  
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    

Click here for diff

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]  

M contrib/sepgsql/sepgsql-regtest.te

Make pg_upgrade's test.sh less chatty.

commit   : 69c3d519112f8c62a94b680351e40496a653fac8    
  
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    

Click here for diff

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]  

M src/bin/pg_upgrade/test.sh

Silence compiler warning, hopefully.

commit   : caa22d72a5f0745034e980784d92bc541927e631    
  
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    

Click here for diff

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]  

M src/timezone/zic.c

Fix error in commit e6feef57.

commit   : f1c72294ba62ccc95bc510e2ee52f537fc9ec5bf    
  
author   : Jeff Davis <[email protected]>    
date     : Thu, 18 Jul 2019 16:56:18 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Thu, 18 Jul 2019 16:56:18 -0700    

Click here for diff

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

M src/backend/utils/adt/rangetypes.c

Fix daterange canonicalization for +/- infinity.

commit   : 8af1fccba2b1a46d58fad46ed8d03e8c92fe1152    
  
author   : Jeff Davis <[email protected]>    
date     : Thu, 18 Jul 2019 16:55:59 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Thu, 18 Jul 2019 16:55:59 -0700    

Click here for diff

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  

M src/backend/utils/adt/rangetypes.c
M src/test/regress/expected/rangetypes.out
M src/test/regress/sql/rangetypes.sql

Update time zone data files to tzdata release 2019b.

commit   : a0c905f23d4c3f7ba647fb69a7e63fd07cdeabe0    
  
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    

Click here for diff

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

M src/timezone/data/tzdata.zi

Sync our copy of the timezone library with IANA release tzcode2019b.

commit   : 417845646311bb0477d61e484538f4ce7c3ebbb5    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 17 Jul 2019 18:26:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 17 Jul 2019 18:26:24 -0400    

Click here for diff

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.  

M src/timezone/README
M src/timezone/localtime.c
M src/timezone/pgtz.h
M src/timezone/tzfile.h
M src/timezone/zic.c

Fix thinko in construction of old_conpfeqop list.

commit   : f9208f2469635c372bf3c2ccfc9835dc11bd8c1c    
  
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    

Click here for diff

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.  

M src/backend/commands/tablecmds.c

doc: mention pg_reload_conf() for reloading the config file

commit   : 1944a253b3aeaaeb204cbaa66f84237a81f87151    
  
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    

Click here for diff

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

M doc/src/sgml/client-auth.sgml

Fix variable initialization when using buffering build with GiST

commit   : b9e1538fcf35708f19ce3f86c22b9bd91a0d2820    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 10 Jul 2019 15:15:23 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 10 Jul 2019 15:15:23 +0900    

Click here for diff

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  

M src/backend/access/gist/gistbuildbuffers.c

Add support for Visual Studio 2019 in build scripts

commit   : 3337fd192596973936c1cd96294f21f3c6f6e6c7    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 3 Jul 2019 08:58:28 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 3 Jul 2019 08:58:28 +0900    

Click here for diff

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  

M doc/src/sgml/install-windows.sgml
M src/tools/msvc/MSBuildProject.pm
M src/tools/msvc/README
M src/tools/msvc/Solution.pm
M src/tools/msvc/VSObjectFactory.pm

Don't read fields of a misaligned ExpandedObjectHeader or AnyArrayType.

commit   : b664b187d7ea6546ef4e0f32167a93c6a74dca08    
  
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    

Click here for diff

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]  

M src/backend/utils/adt/arrayfuncs.c
M src/include/utils/array.h
M src/include/utils/arrayaccess.h
M src/include/utils/expandeddatum.h

Repair logic for reordering grouping sets optimization.

commit   : 4a36c77156f2ff6e07a349cddc65e5dd21abc1a8    
  
author   : Andrew Gierth <[email protected]>    
date     : Sun, 30 Jun 2019 23:49:31 +0100    
  
committer: Andrew Gierth <[email protected]>    
date     : Sun, 30 Jun 2019 23:49:31 +0100    

Click here for diff

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  

M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/groupingsets.out
M src/test/regress/sql/groupingsets.sql

Fix misleading comment in nodeIndexonlyscan.c.

commit   : d7395cf608e7ec8c9cebd17c19dc5d07c761010e    
  
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    

Click here for diff

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  

M src/backend/executor/nodeIndexonlyscan.c

Update reference to sampling algorithm in analyze.c

commit   : 88d63c6ac78de0a9c8bffc43146666e630efc426    
  
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    

Click here for diff

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  

M src/backend/commands/analyze.c

Add support for OpenSSL 1.1.0 and newer versions in MSVC scripts

commit   : d908a0087e0a74c16cf5869276f7cce165bf0782    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 26 Jun 2019 23:05:54 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 26 Jun 2019 23:05:54 +0900    

Click here for diff

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  

M src/tools/msvc/Solution.pm

Don't unset MAKEFLAGS in non-GNU Makefile.

commit   : 9ad5ea82d2bda2ae04b1be958d890d24bc1010f6    
  
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    

Click here for diff

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  

M Makefile

Further fix ALTER COLUMN TYPE's handling of indexes and index constraints.

commit   : 316f6893282450b5a748550d922aa72141f97d1c    
  
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    

Click here for diff

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]  

M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql

Fix spinlock assembly code for MIPS so it works on MIPS r6.

commit   : 36d2c3ad33f8af9415e41b12822516a3e1e68486    
  
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    

Click here for diff

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]  

M src/include/storage/s_lock.h

Remove obsolete comments about sempahores from proc.c.

commit   : cb9242efe0abd8ed9129c16e91085a1675e72f30    
  
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    

Click here for diff

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  

M src/backend/storage/lmgr/proc.c