PostgreSQL 9.6.0 commit log

commit   : a721a1ba9cf6c86cb52f1bf325d5a27b64e870d6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2016 16:26:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2016 16:26:58 -0400    

commit   : e77ea9dbd71693c1a26d4962d5bd2f2163c94acc    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 26 Sep 2016 12:00:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 26 Sep 2016 12:00:00 -0400    

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 5c283d709ce8368fe710f90429b72048ac4c6349  

commit   : 1d473b567e43a84c60428a9f70602acd4deac530    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2016 11:50:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Sep 2016 11:50:35 -0400    

Evidently an oversight in commit 729205571.  Back-patch to 9.2 where  
privileges for types were introduced.  
  
Report: <20160922173517.8214.88959@wrigleys.postgresql.org>  

commit   : fc37e2afa04c612c35e33e0ce447be296ba6bb02    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Sep 2016 16:25:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Sep 2016 16:25:35 -0400    

Set release date, document a few recent commits, do one last pass of  
copy-editing.  

commit   : 5a83e2d4ea7ea064fc5b7d850456bb04db0274ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 15:50:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 15:50:00 -0400    

When configured with --enable-tap-tests, "make install" will now install  
the Perl support files for TAP testing where PGXS will find them.  
This allows extensions to rely on $(prove_check) even when being built  
out-of-tree.  Back-patch to 9.4 where we first started to support TAP  
testing, to reduce the number of cases extension makefiles need to  
consider.  
  
Craig Ringer  
  
Discussion: <CAMsr+YFXv+2qne6xJW7z_25mYBtktRX5rpkrgrb+DRgQ_FxgHQ@mail.gmail.com>  

commit   : 94e4cac251927e3ce1f66b3d96a03f1f7c3ba3e7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 14:22:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 14:22:07 -0400    

These worked as-is until around 7.0, but fail in newer versions because  
there are more operators named "#".  Besides it's a bit inconsistent that  
only two of the examples on this page lack type names on their constants.  
  
Report: <20160923081530.1517.75670@wrigleys.postgresql.org>  

commit   : 7e02476f337990e68c80b7a1395dcc6af111c034    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 13:49:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 13:49:26 -0400    

Faulty AND/OR nesting in the WHERE clause of getFuncs' SQL query led to  
dumping range constructor functions if they are part of an extension  
and we're in binary-upgrade mode.  Actually, we don't want to dump them  
separately even then, since CREATE TYPE AS RANGE will create the range's  
constructor functions regardless.  Per report from Andrew Dunstan.  
  
It looks like this mistake was introduced by me, in commit b985d4877, in  
perhaps-overzealous refactoring to reduce code duplication.  I'm suitably  
embarrassed.  
  
Report: <34854939-02d7-f591-5677-ce2994104599@dunslane.net>  

commit   : a20435fe9aa52cd8c62f3b0ed359077a56824830    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 10:44:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 10:44:50 -0400    

Apparent copy-and-pasteo in standby_desc_invalidations() had two  
entries for msg->id == SHAREDINVALRELMAP_ID.  
  
Aleksander Alekseev  
  
Discussion: <20160923090814.GB1238@e733>  

commit   : e7f5d8ea1c75cc341a966897760a812e437c4668    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 10:09:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 10:09:52 -0400    

We must test GetLastError() even when CreateFileMapping() returns a  
non-null handle.  If that value were left over from some previous system  
call, we might be fooled into thinking the segment already existed.  
Experimentation on Windows 7 suggests that CreateFileMapping() clears  
the error code on success, but it is not documented to do so, so let's  
not rely on that happening in all Windows releases.  
  
Amit Kapila  
  
Discussion: <20811.1474390987@sss.pgh.pa.us>  

commit   : b251379fb44b4893624999f1ba00986c029f11cf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 09:54:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Sep 2016 09:54:11 -0400    

Commits 470d886c3 et al intended to fix the problem that the postmaster  
selected the same "random" DSM control segment ID on every start.  But  
using PostmasterRandom() for that destroys the intended property that the  
delay between random_start_time and random_stop_time will be unpredictable.  
(Said delay is probably already more predictable than we could wish, but  
that doesn't mean that reducing it by a couple orders of magnitude is OK.)  
Revert the previous patch and add a comment warning against misuse of  
PostmasterRandom.  Fix the original problem by calling srandom() early in  
PostmasterMain, using a low-security seed that will later be overwritten  
by PostmasterRandom.  
  
Discussion: <20789.1474390434@sss.pgh.pa.us>  

commit   : a88fe25f50ae9ce491fe10a90aeef2cbed6f2b9a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Sep 2016 11:34:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Sep 2016 11:34:44 -0400    

ExecInitCteScan supposed that it didn't have to do anything to the extra  
tuplestore read pointer it gets from tuplestore_alloc_read_pointer.  
However, it needs this read pointer to be positioned at the start of the  
tuplestore, while tuplestore_alloc_read_pointer is actually defined as  
cloning the current position of read pointer 0.  In normal situations  
that accidentally works because we initialize the whole plan tree at once,  
before anything gets read.  But it fails in an EvalPlanQual recheck, as  
illustrated in bug #14328 from Dima Pavlov.  To fix, just forcibly rewind  
the pointer after tuplestore_alloc_read_pointer.  The cost of doing so is  
negligible unless the tuplestore is already in TSS_READFILE state, which  
wouldn't happen in normal cases.  We could consider altering tuplestore's  
API to make that case cheaper, but that would make for a more invasive  
back-patch and it doesn't seem worth it.  
  
This has been broken probably for as long as we've had CTEs, so back-patch  
to all supported branches.  
  
Discussion: <32468.1474548308@sss.pgh.pa.us>  

commit   : c925e6335e1da58aba3dd764bb9f97fa81d893b8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 21 Sep 2016 08:37:02 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 21 Sep 2016 08:37:02 -0400    

Previously, the individual settings were documented, but there was  
no overall discussion of the capabilities and limitations of the  
feature.  Add that.  
  
Patch by me, reviewed by Peter Eisentraut and Álvaro Herrera.  

commit   : 970300faae189c38fbe393dfab1e326fb75c9a49    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 21 Sep 2016 13:24:13 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 21 Sep 2016 13:24:13 +0300    

The way "latency average" was printed was differently if it was calculated  
from the overall run time or was measured on a per-transaction basis.  
Also, the per-script weight is a test parameter, rather than a result, so  
use the "weight: %f" style for that.  
  
Backpatch to 9.6, since the inconsistency on "latency average" was  
introduced there.  
  
Fabien Coelho  
  
Discussion: <alpine.DEB.2.20.1607131015370.7486@sto>  

commit   : 93834a20f67ee458c98067e253894457c5a958ad    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 21 Sep 2016 13:14:48 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 21 Sep 2016 13:14:48 +0300    

If the test duration was given in # of transactions (-t or no option),  
rather as a duration (-T), the latency average was always printed as 0.  
It has been broken ever since the display of latency average was added,  
in 9.4.  
  
Fabien Coelho  
  
Discussion: <alpine.DEB.2.20.1607131015370.7486@sto>  

commit   : 496c90b5e04729916ae9131ac93b2e63b46e3e2f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Sep 2016 12:00:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Sep 2016 12:00:00 -0400    

based on patch from Takeshi Ideriha <iderihatakeshi@gmail.com>  

commit   : dfddf931707bfc9724179b0f554649dabccf45aa    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Sep 2016 12:00:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Sep 2016 12:00:00 -0400    

The existing example threw an error.  
  
From: gabrielle <gorthx@gmail.com>  

commit   : 00e1933ef30c212b35d3360aff0e77211352dbd7    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Sep 2016 12:00:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Sep 2016 12:00:00 -0400    

When win32security.c was moved from src/backend/port/win32/security.c,  
the message writing function was changed from write_stderr to log_error,  
but nls.mk was not updated.  We could add log_error to GETTEXT_TRIGGERS,  
but it's also used in src/common/exec.c in a different way and that  
would create some confusion or a larger patch.  For now, just put an  
explicit translation marker onto the strings that were previously  
translated.  

commit   : 92668cd4d3df5a7a48408fc722e876a3e1c167d9    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 20 Sep 2016 12:24:44 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 20 Sep 2016 12:24:44 -0400    

Otherwise, every startup gets the same "random" value, which is  
definitely not what was intended.  

commit   : 6bcd26c43c4f0ef718e984643338ddd5b207f9f9    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 20 Sep 2016 12:04:41 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 20 Sep 2016 12:04:41 -0400    

Otherwise, attempts to run multiple postmasters running on the same  
machine may fail, because Windows sometimes returns ERROR_ACCESS_DENIED  
rather than ERROR_ALREADY_EXISTS when there is an existing segment.  
  
Hitting this bug is much more likely because of another defect not  
fixed by this patch, namely that dsm_postmaster_startup() uses  
random() which returns the same value every time.  But that's not  
a reason not to fix this.  
  
Kyotaro Horiguchi and Amit Kapila, reviewed by Michael Paquier  
  
Discussion: <CAA4eK1JyNdMeF-dgrpHozDecpDfsRZUtpCi+1AbtuEkfG3YooQ@mail.gmail.com>  

commit   : fd94ac501f11a747093e0fa5af8514af7408dbc3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 20 Sep 2016 11:38:25 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 20 Sep 2016 11:38:25 +0300    

The GiST search queue is implemented as a pairing heap rather than as  
Red-Black Tree, since 9.5 (commit e7032610). I neglected these comments  
in that commit.  

commit   : f65764a04a0cccbcd53bf413d6f73ecedaae21c6    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Sep 2016 22:55:43 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 Sep 2016 22:55:43 +0300    

We can't use txn_scheduled to hold the sleep-until time for \sleep, because  
that interferes with calculation of the latency of the transaction as whole.  
  
Backpatch to 9.4, where this bug was introduced.  
  
Fabien COELHO  
  
Discussion: <alpine.DEB.2.20.1608231622170.7102@lancre>  

commit   : 156f974f56543365b89f96182e9dfa16f4287e9a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 19 Sep 2016 14:21:48 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 19 Sep 2016 14:21:48 -0400    

MauMau, reviewed by Michael Paquier  

commit   : 275fe7ecab25ee17ae9389167e161d60a5da6b41    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 19 Sep 2016 13:38:21 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 19 Sep 2016 13:38:21 -0400    

Bernd Helmle, reviewed by Thomas Munro, tweaked by me.  

commit   : e06728d631a6bb511006d7e85839713abcdbb555    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 18 Sep 2016 13:46:32 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 18 Sep 2016 13:46:32 +0300    

This makes the -? and -V options work consistently with other binaries.  
--help and --version are now only recognized as the first option, i.e.  
"ecpg --foobar --help" no longer prints the help, but that's consistent  
with most of our other binaries, too.  
  
Backpatch to all supported versions.  
  
Haribabu Kommi  
  
Discussion: <CAJrrPGfnRXvmCzxq6Dy=stAWebfNHxiL+Y_z7uqksZUCkW_waQ@mail.gmail.com>  

commit   : 9895818d5656e3fe775af05df3e2b2cce7346962    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 Sep 2016 22:29:39 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 Sep 2016 22:29:39 +0300    

LibreSSL defines OPENSSL_VERSION_NUMBER to claim that it is version 2.0.0,  
but it doesn't have the functions added in OpenSSL 1.1.0. Add autoconf  
checks for the individual functions we need, and stop relying on  
OPENSSL_VERSION_NUMBER.  
  
Backport to 9.5 and 9.6, like the patch that broke this. In the  
back-branches, there are still a few OPENSSL_VERSION_NUMBER checks left,  
to check for OpenSSL 0.9.8 or 0.9.7. I left them as they were - LibreSSL  
has all those functions, so they work as intended.  
  
Per buildfarm member curculio.  
  
Discussion: <2442.1473957669@sss.pgh.pa.us>  

commit   : 72ce78162c6c4e52b7a9bb1a2de50daee0a3628e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Sep 2016 11:23:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Sep 2016 11:23:25 -0400    

The documentation states that the default value is 8MB, but this was  
only true at BLCKSZ = 8kB, because the default was hard-coded as 1024.  
Make the code match the docs by computing the default as 8MB/BLCKSZ.  
  
Oversight in commit 75be66464, noted pursuant to a gripe from Peter E.  
  
Discussion: <90634e20-097a-e4fd-67d5-fb2c42f0dd71@2ndquadrant.com>  

commit   : bea38f34a4e601d2ea803a3a6d6b90ee0fe2d2b6    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 15 Sep 2016 09:22:52 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 15 Sep 2016 09:22:52 -0400    

Otherwise, users who have configured shared_buffers >= 256GB won't  
be able to use this module.  There probably aren't many of those, but  
it doesn't hurt anything to fix it so that it works.  
  
Backpatch to 9.4, where MemoryContextAllocHuge was introduced.  The  
same problem exists in older branches, but there's no easy way to  
fix it there.  
  
KaiGai Kohei  

commit   : fcd93e4af943fc444a5928355c9471d36f077538    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 Sep 2016 12:55:38 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 Sep 2016 12:55:38 +0300    

Changes needed to build at all:  
  
- Check for SSL_new in configure, now that SSL_library_init is a macro.  
- Do not access struct members directly. This includes some new code in  
  pgcrypto, to use the resource owner mechanism to ensure that we don't  
  leak OpenSSL handles, now that we can't embed them in other structs  
  anymore.  
- RAND_SSLeay() -> RAND_OpenSSL()  
  
Changes that were needed to silence deprecation warnings, but were not  
strictly necessary:  
  
- RAND_pseudo_bytes() -> RAND_bytes().  
- SSL_library_init() and OpenSSL_config() -> OPENSSL_init_ssl()  
- ASN1_STRING_data() -> ASN1_STRING_get0_data()  
- DH_generate_parameters() -> DH_generate_parameters()  
- Locking callbacks are not needed with OpenSSL 1.1.0 anymore. (Good  
  riddance!)  
  
Also change references to SSLEAY_VERSION_NUMBER with OPENSSL_VERSION_NUMBER,  
for the sake of consistency. OPENSSL_VERSION_NUMBER has existed since time  
immemorial.  
  
Fix SSL test suite to work with OpenSSL 1.1.0. CA certificates must have  
the "CA:true" basic constraint extension now, or OpenSSL will refuse them.  
Regenerate the test certificates with that. The "openssl" binary, used to  
generate the certificates, is also now more picky, and throws an error  
if an X509 extension is specified in "req_extensions", but that section  
is empty.  
  
Backpatch to 9.5 and 9.6, per popular demand. The file structure was  
somewhat different in earlier branches, so I didn't bother to go further  
than that. In back-branches, we still support OpenSSL 0.9.7 and above.  
OpenSSL 0.9.6 should still work too, but I didn't test it. In master, we  
only support 0.9.8 and above.  
  
Patch by Andreas Karlsson, with additional changes by me.  
  
Discussion: <20160627151604.GD1051@msg.df7cb.de>  

commit   : 18ae680632b5c7a1550a768f1a4dc8e31b08215d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 Sep 2016 11:51:43 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 Sep 2016 11:51:43 +0300    

These were modified by the patch to only use replacement selection for the  
first run in an external sort.  

commit   : 5e1431f94e4c8260c76c061a94c97b0e15956ebe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Sep 2016 19:19:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Sep 2016 19:19:24 -0400    

Standardize on "user_name" for a field name in related examples in  
ddl.sgml; before we had variously "user_name", "username", and "user".  
The last is flat wrong because it conflicts with a reserved word.  
  
Be consistent about entry capitalization in a table in func.sgml.  
  
Fix a typo in pgtrgm.sgml.  
  
Back-patch to 9.6 and 9.5 as relevant.  
  
Alexander Law  

commit   : 4b47cb35fa516c1bb380ab4edf3131fb6adfacfe    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 12 Sep 2016 09:02:17 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 12 Sep 2016 09:02:17 +0100    

Daniel Gustafsson  

commit   : f2dba881a5e13abc957f0e692749f89c9288134d    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sun, 11 Sep 2016 23:27:29 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sun, 11 Sep 2016 23:27:29 +0100    

Previously checkpoint_timeout was capped at 3600s  
New max setting is 86400s = 24h = 1d  
  
Discussion: 32558.1454471895@sss.pgh.pa.us  

commit   : fa7b3a88dd5d7f6d18614eefc6cc0662e31bd451    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Sep 2016 17:54:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Sep 2016 17:54:23 -0400    

Some experimentation with an older version of gcc showed that it is able  
to determine whether "if (elevel_ >= ERROR)" is compile-time constant  
if elevel_ is declared "const", but otherwise not so much.  We had  
accounted for that in ereport() but were too miserly with braces to  
make it so in elog().  I don't know how many currently-interesting  
compilers have the same quirk, but in case it will save some code  
space, let's make sure that elog() is on the same footing as ereport()  
for this purpose.  
  
Back-patch to 9.3 where we introduced pg_unreachable() calls into  
elog/ereport.  

commit   : 7a142b6bbf20c5ad54d11ea45e7a74ce02c510f0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Sep 2016 13:49:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Sep 2016 13:49:04 -0400    

Commit dd1a3bccc replaced a test on whether a subroutine returned a  
null pointer with a test on whether &pointer->backendStatus was null.  
This accidentally failed to fail, at least on common compilers, because  
backendStatus is the first field in the struct; but it was surely trouble  
waiting to happen.  Commit f91feba87 then messed things up further,  
changing the logic to  
  
	local_beentry = pgstat_fetch_stat_local_beentry(curr_backend);  
	if (!local_beentry)  
		continue;  
	beentry = &local_beentry->backendStatus;  
	if (!beentry)  
	{  
  
where the second "if" is now dead code, so that the intended behavior of  
printing a row with "<backend information not available>" cannot occur.  
  
I suspect this is all moot because pgstat_fetch_stat_local_beentry  
will never actually return null in this function's usage, but it's still  
very poor coding.  Repair back to 9.4 where the original problem was  
introduced.  

commit   : c3656c9ff3aa20ce5144ae77b5f6669f09c9362b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Sep 2016 15:54:29 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 9 Sep 2016 15:54:29 -0300    

When heap_lock_tuple decides to follow the update chain, it tried to  
also lock any version of the tuple that was created by an update that  
was subsequently rolled back.  This is pointless, since for all intents  
and purposes that tuple exists no more; and moreover it causes  
misbehavior, as reported independently by Marko Tiikkaja and Marti  
Raudsepp: some SELECT FOR UPDATE/SHARE queries may fail to return  
the tuples, and assertion-enabled builds crash.  
  
Fix by having heap_lock_updated_tuple test the xmin and return success  
immediately if the tuple was created by an aborted transaction.  
  
The condition where tuples become invisible occurs when an updated tuple  
chain is followed by heap_lock_updated_tuple, which reports the problem  
as HeapTupleSelfUpdated to its caller heap_lock_tuple, which in turn  
propagates that code outwards possibly leading the calling code  
(ExecLockRows) to believe that the tuple exists no longer.  
  
Backpatch to 9.3.  Only on 9.5 and newer this leads to a visible  
failure, because of commit 27846f02c176; before that, heap_lock_tuple  
skips the whole dance when the tuple is already locked by the same  
transaction, because of the ancient HeapTupleSatisfiesUpdate behavior.  
Still, the buggy condition may also exist in more convoluted scenarios  
involving concurrent transactions, so it seems safer to fix the bug in  
the old branches too.  
  
Discussion:  
	https://www.postgresql.org/message-id/CABRT9RC81YUf1=jsmWopcKJEro=VoeG2ou6sPwyOUTx_qteRsg@mail.gmail.com  
	https://www.postgresql.org/message-id/48d3eade-98d3-8b9a-477e-1a8dc32a724d@joh.to  

commit   : 1fef3d576e3a8ac69f90faf192997858f1d82f64    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 9 Sep 2016 13:11:25 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 9 Sep 2016 13:11:25 +0100    

Reading 2PC state files during recovery was borked, causing corruptions during  
recovery. Effect limited to servers with 2PC, subtransactions and  
recovery/replication.  
  
Stas Kelvich, reviewed by Michael Paquier and Pavan Deolasee  

commit   : 1fa42debe676146f1f3e4809ef42e9a0f300e112    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 9 Sep 2016 11:43:08 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 9 Sep 2016 11:43:08 +0100    

lazy_truncate_heap() was waiting for  
VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL, but in microseconds  
not milliseconds as originally intended.  
  
Found by code inspection.  
  
Simon Riggs  

commit   : 9796882e68367a9259b6d5e84bd0a227b579d586    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 9 Sep 2016 11:20:36 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 9 Sep 2016 11:20:36 +0100    

Revert to original use of word “sample”, though with clarification,  
per Tom Lane.  
  
Discussion: 29052.1471015383@sss.pgh.pa.us  

commit   : f6802936a53671c9db24273ab2ae94291a68afcd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 8 Sep 2016 16:51:09 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 8 Sep 2016 16:51:09 -0700    

mdtruncate() forgot to FileClose() a segment's mdfd_vfd, when deleting  
it. That lead to a fd.c handle to a truncated file being kept open until  
backend exit.  
  
The issue appears to have been introduced way back in 1a5c450f3024ac5,  
before that the handle was closed inside FileUnlink().  
  
The impact of this bug is limited - only VACUUM and ON COMMIT TRUNCATE  
for temporary tables, truncate files in place (i.e. TRUNCATE itself is  
not affected), and the relation has to be bigger than 1GB. The  
consequences of a leaked fd.c handle aren't severe either.  
  
Discussion: <20160908220748.oqh37ukwqqncbl3n@alap3.anarazel.de>  
Backpatch: all supported releases  

commit   : e012e7845423a6428ce82bf3a21f6efc958351fb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 8 Sep 2016 14:39:05 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 8 Sep 2016 14:39:05 -0300    

commit_ts and test_pg_dump were declaring targets before including the  
PGXS stanza, which meant that the "all" target customarily defined as  
the first (and therefore default target) was not the default anymore.  
Fix that by moving those target definitions to after PGXS.  
  
commit_ts was initially good, but I broke it in commit 9def031bd2;  
test_pg_dump was born broken, probably copying from commit_ts' mistake.  
  
In passing, fix a comment mistake in test_pg_dump/Makefile.  
  
Backpatch to 9.6.  
  
Noted by Tom Lane.  

commit   : 31eb14504de311c98db2d1306ac61427bcdad863    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Sep 2016 13:12:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Sep 2016 13:12:01 -0400    

Previously, if a schema was created by an extension, a normal pg_dump run  
(not --binary-upgrade) would summarily skip every object in that schema.  
In a case where an extension creates a schema and then users create other  
objects within that schema, this does the wrong thing: we want pg_dump  
to skip the schema but still create the non-extension-owned objects.  
  
There's no easy way to fix this pre-9.6, because in earlier versions the  
"dump" status for a schema is just a bool and there's no way to distinguish  
"dump me" from "dump my members".  However, as of 9.6 we do have enough  
state to represent that, so this is a simple correction of the logic in  
selectDumpableNamespace.  
  
In passing, make some cosmetic fixes in nearby code.  
  
Martín Marqués, reviewed by Michael Paquier  
  
Discussion: <99581032-71de-6466-c325-069861f1947d@2ndquadrant.com>  

commit   : a88cee90fdfb2c125d56cb08164ca9a9ca39a75d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Sep 2016 10:48:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Sep 2016 10:48:03 -0400    

If the database has a non-default tablespace, we emitted a TABLESPACE  
clause in the CREATE DATABASE command emitted by -C, even if  
--no-tablespaces was also specified.  This seems wrong, and it's  
inconsistent with what pg_dumpall does, so change it.  Per bug #14315  
from Danylo Hlynskyi.  
  
Back-patch to 9.5.  The bug is much older, but it'd be a more invasive  
change before 9.5 because dumpDatabase() hasn't got an easy way to get  
to the outputNoTablespaces flag.  Doesn't seem worth the work given  
the lack of previous complaints.  
  
Report: <20160908081953.1402.75347@wrigleys.postgresql.org>  

commit   : d7c45172a673be1fc9e51e98e45a44c14d1ee78d    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 8 Sep 2016 11:20:21 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 8 Sep 2016 11:20:21 +0100    

StandbyRecoverPreparedTransactions() leaked the buffer  
used for two phase state file. This was leaked once  
at startup and at every shutdown checkpoint seen.  
  
Backpatch to 9.6  
  
Stas Kelvich  

commit   : 5c8cb8c01f0a8d484de301f58e673ed9c732fbbe    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Sep 2016 20:51:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Sep 2016 20:51:28 -0400    

Previously it less precisely talked about autovacuum.  
  
Backpatch-through: 9.6  

commit   : 01280ee203b7c34b48e61f874b497951cc63d8a7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Sep 2016 13:36:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Sep 2016 13:36:08 -0400    

Document the formerly-undocumented behavior that schema and comment  
control-file entries for an extension are honored only during initial  
installation, whereas other properties are also honored during updates.  
  
While at it, do some copy-editing on the recently-added docs for CREATE  
EXTENSION ... CASCADE, use links for some formerly vague cross references,  
and make a couple other minor improvements.  
  
Back-patch to 9.6 where CASCADE was added.  The other parts of this  
could go further back, but they're probably not important enough to  
bother.  

commit   : ed3598f33f4c2a9eb07678bd29a90919e6c63938    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Sep 2016 17:50:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Sep 2016 17:50:53 -0400    

Mostly, explain how row xmin's used to be replaced by FrozenTransactionId  
and no longer are.  Do a little copy-editing on the side.  
  
Per discussion with Egor Rogov.  Back-patch to 9.4 where the behavioral  
change occurred.  
  
Discussion: <575D7955.6060209@postgrespro.ru>  

commit   : 96ba40c0f15aa1e950b35536387fde30ebbc4547    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Sep 2016 15:50:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Sep 2016 15:50:31 -0400    

Negative availMemLessRefund would be problematic.  It's not entirely  
clear whether the case can be hit in the code as it stands, but this  
seems like good future-proofing in any case.  While we're at it,  
insist that the value be not merely positive but not tiny, so as to  
avoid doing a lot of repalloc work for little gain.  
  
Peter Geoghegan  
  
Discussion: <CAM3SWZRVkuUB68DbAkgw=532gW0f+fofKueAMsY7hVYi68MuYQ@mail.gmail.com>  

commit   : 512c197b21aa86b1827bfc433f4aebc1469648fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Sep 2016 20:02:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Sep 2016 20:02:16 -0400    

After further reflection about the mess cleaned up in commit 39b691f25,  
I decided the main bit of test coverage that was still missing was to  
check that the non-default abbreviation-set files we supply are usable.  
Add that.  
  
Back-patch to supported branches, just because it seems like a good  
idea to keep this all in sync.  

commit   : 06b185d181897c4a9672e26b93d5abc89de52f85    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Sep 2016 19:42:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Sep 2016 19:42:08 -0400    

Commit b2cbced9e instituted a policy of referring to the timezone database  
as the "IANA timezone database" in our user-facing documentation.  
Propagate that wording into a couple of places that were still using "zic"  
to refer to the database, which is definitely not right (zic is the  
compilation tool, not the data).  
  
Back-patch, not because this is very important in itself, but because  
we routinely cherry-pick updates to the tznames files and I don't want  
to risk future merge failures.  

commit   : 7bdf63ccdc70e7168740bdc426195b3b5d508f29    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Sep 2016 13:19:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Sep 2016 13:19:55 -0400    

Maybe we ought to make pg_upgrade do this for you, but it won't happen  
in 9.6, so call out the need for it as a migration consideration.  

commit   : 36646d3aff0cf6ff9f26033e38808d23e27426e8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Sep 2016 13:28:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Sep 2016 13:28:53 -0400    

computeLeafRecompressWALData() tried to produce a uint16 WAL log field by  
memcpy'ing the first two bytes of an int-sized variable.  That accidentally  
works on little-endian hardware, but not at all on big-endian.  Replay then  
thinks it's looking at an ADDITEMS action with zero entries, and reads the  
first two bytes of the first TID therein as the next segno/action,  
typically leading to "unexpected GIN leaf action" errors during replay.  
Even if replay failed to crash, the resulting GIN index page would surely  
be incorrect.  To fix, just declare the variable as uint16 instead.  
  
Per bug #14295 from Spencer Thomason (much thanks to Spencer for turning  
his problem into a self-contained test case).  This likely also explains  
a previous report of the same symptom from Bernd Helmle.  
  
Back-patch to 9.4 where the problem was introduced (by commit 14d02f0bb).  
  
Discussion: <20160826072658.15676.7628@wrigleys.postgresql.org>  
Possible-Report: <2DA7350F7296B2A142272901@eje.land.credativ.lan>  

commit   : 33befe035d86d833a5bc7289612722a4e650227d    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 3 Sep 2016 16:19:41 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 3 Sep 2016 16:19:41 +0100    

Be specific about conditions under which we emit >1 copy of message  
  
Craig Ringer  

commit   : 32c9950b39981026774cfd1e1c3e717ee71f7826    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Sep 2016 17:29:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Sep 2016 17:29:31 -0400    

Previously, we threw an error if a dynamic timezone abbreviation did not  
match any abbreviation recorded in the referenced IANA time zone entry.  
That seemed like a good consistency check at the time, but it turns out  
that a number of the abbreviations in the IANA database are things that  
Olson and crew made up out of whole cloth.  Their current policy is to  
remove such names in favor of using simple numeric offsets.  Perhaps  
unsurprisingly, a lot of these made-up abbreviations have varied in meaning  
over time, which meant that our commit b2cbced9e and later changes made  
them into dynamic abbreviations.  So with newer IANA database versions  
that don't mention these abbreviations at all, we fail, as reported in bug  
#14307 from Neil Anderson.  It's worse than just a few unused-in-the-wild  
abbreviations not working, because the pg_timezone_abbrevs view stops  
working altogether (since its underlying function tries to compute the  
whole view result in one call).  
  
We considered deleting these abbreviations from our abbreviations list, but  
the problem with that is that we can't stay ahead of possible future IANA  
changes.  Instead, let's leave the abbreviations list alone, and treat any  
"orphaned" dynamic abbreviation as just meaning the referenced time zone.  
It will behave a bit differently than it used to, in that you can't any  
longer override the zone's standard vs. daylight rule by using the "wrong"  
abbreviation of a pair, but that's better than failing entirely.  (Also,  
this solution can be interpreted as adding a small new feature, which is  
that any abbreviation a user wants can be defined as referencing a time  
zone name.)  
  
Back-patch to all supported branches, since this problem affects all  
of them when using tzdata 2016f or newer.  
  
Report: <20160902031551.15674.67337@wrigleys.postgresql.org>  
Discussion: <6189.1472820913@sss.pgh.pa.us>  

commit   : 3fc489cb36a53bc246271107450c5cf5fcd5b009    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Aug 2016 08:52:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Aug 2016 08:52:13 -0400    

This can't really work because standby_mode expects there to be more  
WAL arriving, which there will not ever be because there's no WAL  
receiver process to fetch it.  Moreover, if standby_mode is on then  
hot standby might also be turned on, causing even more strangeness  
because that expects read-only sessions to be executing in parallel.  
Bernd Helmle reported a case where btree_xlog_delete_get_latestRemovedXid  
got confused, but rather than band-aiding individual problems it seems  
best to prevent getting anywhere near this state in the first place.  
Back-patch to all supported branches.  
  
In passing, also fix some omissions of errcodes in other ereport's in  
readRecoveryCommandFile().  
  
Michael Paquier (errcode hacking by me)  
  
Discussion: <00F0B2CEF6D0CEF8A90119D4@eje.credativ.lan>  

commit   : a66be67820063dc3d880b2a5408714b877eec8ae    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 31 Aug 2016 12:36:18 +0530    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 31 Aug 2016 12:36:18 +0530    

Commit f9143d102ffd0947ca904c62b1d3d6fd587e0c80 falsified these.  
  
KaiGai Kohei  

commit   : d9720e4377911d9d4157221ff362226f2169fe4c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Aug 2016 15:25:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Aug 2016 15:25:01 -0400    

While testing simple_prompt() revisions, I happened to notice that  
current initdb behaves rather badly when --pwprompt is specified and  
the user miskeys the second password.  It complains about the mismatch,  
does "rm -rf" on the data directory, and exits.  The problem is that  
since commit c4a8812cf, there's a standalone backend sitting waiting  
for commands at that point.  It gets unhappy about its datadir having  
gone away, and spews a PANIC message at the user, which is not nice.  
(And the shell then adds to the mess with meaningless bleating about a  
core dump...)  We don't really want that sort of thing to happen unless  
there's an internal failure in initdb, which this surely is not.  
  
The best fix seems to be to move the collection of the password  
earlier, so that it's done essentially as part of argument collection,  
rather than at the rather ad-hoc time it was done before.  
  
Back-patch to 9.6 where the problem was introduced.  

commit   : 7961c31aa76b1ce9adaac7ee98c67c149c1a4eef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Aug 2016 16:22:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Aug 2016 16:22:24 -0400    

commit   : 7e3aad82e0b4dc7ed491b8bb7082c39f7a0212e9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 29 Aug 2016 12:00:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 29 Aug 2016 12:00:00 -0400    

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

commit   : 9100f534030c543f95c11a2f9c5f1571f55999b9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Aug 2016 08:57:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Aug 2016 08:57:34 -0400    

Sync relevant parts of commit d2ddee63b back to 9.6 branch.  

commit   : 216fd7fe77c693a9595bb7550de2927dde650218    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 29 Aug 2016 12:18:12 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 29 Aug 2016 12:18:12 +0100    

Make pg_receivexlog work correctly with —-synchronous without slots  
  
Backpatch to 9.5  
  
Gabriele Bartolini, reviewed by Michael Paquier and Simon Riggs  

commit   : 2802b02a540c0f5bc2d11e801dc527d4240ed404    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 29 Aug 2016 14:34:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 29 Aug 2016 14:34:58 +0900    

Previously pg_xlogdump failed to dump the contents of the WAL file  
if the file starts with the continuation WAL record which spans  
more than one pages. Since pg_xlogdump assumed that the continuation  
record always fits on a page, it could not find the valid WAL record to  
start reading from in that case.  
  
This patch changes pg_xlogdump so that it can handle a continuation  
WAL record which crosses a page boundary and find the valid record  
to start reading from.  
  
Back-patch to 9.3 where pg_xlogdump was introduced.  
  
Author: Pavan Deolasee  
Reviewed-By: Michael Paquier and Craig Ringer  
Discussion: CABOikdPsPByMiG6J01DKq6om2+BNkxHTPkOyqHM2a4oYwGKsqQ@mail.gmail.com  

commit   : 9595bffc59831cfca1339b4eca35eac39e188209    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Aug 2016 17:44:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Aug 2016 17:44:29 -0400    

Per Tomas Vondra.  

commit   : 1e17ceba093dbb3aecedb62ef879934514524db3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Aug 2016 17:40:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Aug 2016 17:40:06 -0400    

I think they're pretty much release-quality now.  

commit   : 197e8b7fa4eca5267f45c715419c52522dfc600f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Aug 2016 12:37:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Aug 2016 12:37:23 -0400    

commit   : b9fe6cbc81ea120a39be755f23d6615486c11618    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Aug 2016 17:50:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Aug 2016 17:50:38 -0400    

I found that half a dozen (nearly 5%) of our AllocSetContextCreate calls  
had typos in the context-sizing parameters.  While none of these led to  
especially significant problems, they did create minor inefficiencies,  
and it's now clear that expecting people to copy-and-paste those calls  
accurately is not a great idea.  Let's reduce the risk of future errors  
by introducing single macros that encapsulate the common use-cases.  
Three such macros are enough to cover all but two special-purpose contexts;  
those two calls can be left as-is, I think.  
  
While this patch doesn't in itself improve matters for third-party  
extensions, it doesn't break anything for them either, and they can  
gradually adopt the simplified notation over time.  
  
In passing, change TopMemoryContext to use the default allocation  
parameters.  Formerly it could only be extended 8K at a time.  That was  
probably reasonable when this code was written; but nowadays we create  
many more contexts than we did then, so that it's not unusual to have a  
couple hundred K in TopMemoryContext, even without considering various  
dubious code that sticks other things there.  There seems no good reason  
not to let it use growing blocks like most other contexts.  
  
Back-patch to 9.6, mostly because that's still close enough to HEAD that  
it's easy to do so, and keeping the branches in sync can be expected to  
avoid some future back-patching pain.  The bugs fixed by these changes  
don't seem to be significant enough to justify fixing them further back.  
  
Discussion: <21072.1472321324@sss.pgh.pa.us>  

commit   : e796d0abab0f9508326c0aa721fe1475548fbe4e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Aug 2016 16:20:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Aug 2016 16:20:17 -0400    

This has been requested a few times, but the use-case for it was never  
entirely clear.  The reason for adding it now is that transmission of  
error reports from parallel workers fails when NLS is active, because  
pq_parse_errornotice() wrongly assumes that the existing severity field  
is nonlocalized.  There are other ways we could have fixed that, but the  
other options were basically kluges, whereas this way provides something  
that's at least arguably a useful feature along with the bug fix.  
  
Per report from Jakob Egger.  Back-patch into 9.6, because otherwise  
parallel query is essentially unusable in non-English locales.  The  
problem exists in 9.5 as well, but we don't want to risk changing  
on-the-wire behavior in 9.5 (even though the possibility of new error  
fields is specifically called out in the protocol document).  It may  
be sufficient to leave the issue unfixed in 9.5, given the very limited  
usefulness of pq_parse_errornotice in that version.  
  
Discussion: <A88E0006-13CB-49C6-95CC-1A77D717213C@eggerapps.at>  

commit   : bef2d627f30c0d854d02dc860b0d54fa3309d4ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Aug 2016 15:04:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Aug 2016 15:04:05 -0400    

HandleParallelMessages leaked memory into the caller's context.  Since it's  
called from ProcessInterrupts, there is basically zero certainty as to what  
CurrentMemoryContext is, which means we could be leaking into long-lived  
contexts.  Over the processing of many worker messages that would grow to  
be a problem.  Things could be even worse than just a leak, if we happened  
to service the interrupt while ErrorContext is current: elog.c thinks it  
can reset that on its own whim, possibly yanking storage out from under  
HandleParallelMessages.  
  
Give HandleParallelMessages its own dedicated context instead, which we can  
reset during each call to ensure there's no accumulation of wasted memory.  
  
Discussion: <16610.1472222135@sss.pgh.pa.us>  

commit   : 42ebdc8129f038e06e17d7b3da7fc11897323814    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Aug 2016 14:19:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Aug 2016 14:19:03 -0400    

The guiding principle for the last few patches in this area apparently  
involved throwing darts.  
  
Cosmetic only, but back-patch to 9.6 because there is no reason for  
9.6 and HEAD to diverge yet in this file.  

commit   : 6e47c6cf7de30b9f6a6b31eb7d4af80039a16920    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Aug 2016 14:15:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Aug 2016 14:15:47 -0400    

Copy the palloc'd strings into the correct context, ie ErrorContext  
not wherever the source ErrorData is.  This would be a large bug,  
except that it appears that all catchers of thrown errors do either  
EmitErrorReport or CopyErrorData before doing anything that would  
cause transient memory contexts to be cleaned up.  Still, it's wrong  
and it will bite somebody someday.  
  
Fix failure to copy cursorpos and internalpos.  
  
Utter the appropriate incantations involving recursion_depth, so that  
we'll behave sanely if we get an error inside pstrdup.  (In general,  
the body of this function ought to act like, eg, errdetail().)  
  
Per code reading induced by Jakob Egger's report.  

commit   : 9dca62e9ff3db2f482c829884b24a425692a5a18    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Aug 2016 10:07:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Aug 2016 10:07:28 -0400    

The previous coding here was capable of adding a "parallel worker" context  
line to errors that were not, in fact, returned from a parallel worker.  
Instead of using an errcontext callback to add that annotation, just paste  
it onto the message by hand; this looks uglier but is more reliable.  
  
Discussion: <19757.1472151987@sss.pgh.pa.us>  

commit   : e6bd440688af13449bcb1b80698e6ef4b16245a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Aug 2016 09:57:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Aug 2016 09:57:09 -0400    

Commit f0c7b789a added a test case in case.sql that creates and then drops  
both an '=' operator and the type it's for.  Given the right timing, that  
can cause a "cache lookup failed for type" failure in concurrent sessions,  
which see the '=' operator as a potential match for '=' in a query, but  
then the type is gone by the time they inquire into its properties.  
It might be nice to make that behavior more robust someday, but as a  
back-patchable solution, adjust the new test case so that the operator  
is never visible to other sessions.  Like the previous commit, back-patch  
to all supported branches.  
  
Discussion: <5983.1471371667@sss.pgh.pa.us>  

commit   : 006fb80a569179d3df4932857818925667e8d581    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2016 22:20:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2016 22:20:01 -0400    

When there is an identifiable REPLICA IDENTITY index on the target table,  
heap_update leaks the id_attrs bitmapset.  That's not many bytes, but it  
adds up over enough rows, since the code typically runs in a query-lifespan  
context.  Bug introduced in commit e55704d8b, which did a rather poor job  
of cloning the existing use-pattern for RelationGetIndexAttrBitmap().  
  
Per bug #14293 from Zhou Digoal.  Back-patch to 9.4 where the bug was  
introduced.  
  
Report: <20160824114320.15676.45171@wrigleys.postgresql.org>  

commit   : 1414d490f7eee23bf3544953a47340e9b54fcf29    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 24 Aug 2016 21:11:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 24 Aug 2016 21:11:44 -0400    

Reported-by: Alexander Law  
  
Author: Alexander Law  
  
Backpatch-through: 9.6  

commit   : 616be05dfea09e8221e190086c0d75351f3a57ca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2016 14:37:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2016 14:37:50 -0400    

ExecReScanAgg's check for whether it could re-use a previously calculated  
hashtable neglected the possibility that the Agg node might reference  
PARAM_EXEC Params that are not referenced by its input plan node.  That's  
okay if the Params are in upper tlist or qual expressions; but if one  
appears in aggregate input expressions, then the hashtable contents need  
to be recomputed when the Param's value changes.  
  
To avoid unnecessary performance degradation in the case of a Param that  
isn't within an aggregate input, add logic to the planner to determine  
which Params are within aggregate inputs.  This requires a new field in  
struct Agg, but fortunately we never write plans to disk, so this isn't  
an initdb-forcing change.  
  
Per report from Jeevan Chalke.  This has been broken since forever,  
so back-patch to all supported branches.  
  
Andrew Gierth, with minor adjustments by me  
  
Report: <CAM2+6=VY8ykfLT5Q8vb9B6EbeBk-NGuLbT6seaQ+Fq4zXvrDcA@mail.gmail.com>  

commit   : eaae83c123f5e8e103abbbe822fe73b791d9d5c9    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 24 Aug 2016 13:20:25 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 24 Aug 2016 13:20:25 -0500    

Accidentally added in 8b65cf4c5edabdcae45ceaef7b9ac236879aae50.  
  
Pointed out by Álvaro Herrera  

commit   : be84c12ae9d65be85765c2b70bf14773d133c4f0    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 23 Aug 2016 23:40:38 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 23 Aug 2016 23:40:38 -0400    

Every program having -lpgfeutils in LDFLAGS must have this dependency,  
whether or not the program uses a libpgfeutils symbol.  Back-patch to  
9.6, where libpgfeutils was introduced.  

commit   : 5c0b74240cb1f25a09b9b38d7cb665c0935a5d81    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Aug 2016 23:21:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Aug 2016 23:21:10 -0400    

With Asserts off, these variables are set but never used, resulting  
in warnings from pickier compilers.  Fix that with our standard solution.  
Per report from Jeff Janes.  

commit   : fcf1ed48ef0b2a92f903104160f792b5c10c6595    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 23 Aug 2016 12:45:33 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 23 Aug 2016 12:45:33 -0400    

Discussion: dcc4113d-1eda-4f60-d1c5-f50eee160bad@gmail.com  
  
Author: Alexander Law <exclusion@gmail.com>  
  
Backpatch-through: 9.6  

commit   : 221d63c8d0decb58b9b08e265d24700385a9cdbc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 22 Aug 2016 17:20:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 22 Aug 2016 17:20:44 -0400    

Reported-by: Jeff Janes  
  
Backpatch-through: 9.6  

commit   : 48b9ca0b60ce4e92caf6b2ad68d40d09f1795fca    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 22 Aug 2016 15:22:11 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 22 Aug 2016 15:22:11 -0400    

Due to an error in the abbreviated key abort logic, the most recently  
processed SortTuple could be incorrectly marked NULL, resulting in an  
incorrect final sort order.  
  
In the worst case, this could result in a corrupt btree index, which  
would need to be rebuild using REINDEX.  However, abbrevation doesn't  
abort very often, not all data types use it, and only one tuple would  
end up in the wrong place, so the practical impact of this mistake may  
be somewhat limited.  
  
Report and patch by Peter Geoghegan.  

commit   : c3813268a7eca8000b8963c079e521eccd960620    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Aug 2016 14:35:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Aug 2016 14:35:32 -0400    

Obvious brain fade in set_rel_consider_parallel().  Noticed it while  
adjusting the adjacent RTE_FUNCTION case.  
  
In 9.6, also make the code look more like what I just did in HEAD  
by removing the unnecessary function_rte_parallel_ok subroutine  
(it does nothing that expression_tree_walker wouldn't do).  

commit   : 0440f49523fb88a3ecbc1672d8fcee20197c5c40    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 19 Aug 2016 14:38:55 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 19 Aug 2016 14:38:55 -0300    

Clobbering errno during cleanup after an error is an oft-repeated, easy  
to make mistake.  Deal with it here as everywhere else, by saving it  
aside and restoring after cleanup, before ereport'ing.  
  
In passing, add a missing errcode declaration in another ereport() call  
in the same file, which I noticed while skimming the file looking for  
similar problems.  
  
Backpatch to 9.4, where this code was introduced.  

commit   : 2b4ae9c29d42ce7b1b7bb947c585b78a21535aa2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 Aug 2016 21:41:10 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 18 Aug 2016 21:41:10 -0400    

We already mentioned unix_socket_directories as an option.  
  
Reported-by: https://www.postgresql.org/message-id/45016837-6cf3-3136-f959-763d06a28076%402ndquadrant.com  
  
Backpatch-through: 9.6  

commit   : 0d5afd3f21e1f3bfb76a50aa613620b9caba4a4e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 18 Aug 2016 17:30:14 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 18 Aug 2016 17:30:14 -0700    

On some buildfarm animals the isolationtest added in 07ef0351 failed, as  
the order in which processes are run after unlocking is not  
guaranteed. Add an alternative output for that.  
  
Discussion: <7969.1471484738@sss.pgh.pa.us>  
Backpatch: 9.6, like the test in the aforementioned commit  

commit   : 6ab10fe2afa7690e84a5845ede51b81690020064    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Aug 2016 16:04:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Aug 2016 16:04:35 -0400    

As usual, we've been pretty awful about maintaining these counts.  
They're not all that critical, perhaps, but let's get them right  
at release time.  Also fix 9.5, which I notice is just as bad.  
It's probably wrong further back, but the lack of --help=foo  
options before 9.5 makes it too painful to count.  

commit   : c81c71d8846fa1667e67b45559ce4c72a8e076d9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Aug 2016 14:48:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Aug 2016 14:48:51 -0400    

These types are storage-compatible with real arrays, but they don't support  
toasting, so of course they can't support expansion either.  
  
Per bug #14289 from Michael Overmeyer.  Back-patch to 9.5 where expanded  
arrays were introduced.  
  
Report: <20160818174414.1529.37913@wrigleys.postgresql.org>  

commit   : 191d45793df71d69b83cfa3c8c2747f7597ba1b7    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 18 Aug 2016 12:32:42 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 18 Aug 2016 12:32:42 +0200    

This adds a couple of new timezones that are present in the newer  
versions of Windows. It also updates comments to reference UTC rather  
than GMT, as this change has been made in Windows.  
  
Michael Paquier  

commit   : e79aaebccd1bd12c477af838015252059f989b2b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 17 Aug 2016 17:03:36 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 17 Aug 2016 17:03:36 -0700    

INSERT ..  ON CONFLICT runs a pre-check of the possible conflicting  
constraints before performing the actual speculative insertion.  In case  
the inserted tuple included TOASTed columns the ON CONFLICT condition  
would be handled correctly in case the conflict was caught by the  
pre-check, but if two transactions entered the speculative insertion  
phase at the same time, one would have to re-try, and the code for  
aborting a speculative insertion did not handle deleting the  
speculatively inserted TOAST datums correctly.  
  
TOAST deletion would fail with "ERROR: attempted to delete invisible  
tuple" as we attempted to remove the TOAST tuples using  
simple_heap_delete which reasoned that the given tuples should not be  
visible to the command that wrote them.  
  
This commit updates the heap_abort_speculative() function which aborts  
the conflicting tuple to use itself, via toast_delete, for deleting  
associated TOAST datums.  Like before, the inserted toast rows are not  
marked as being speculative.  
  
This commit also adds a isolationtester spec test, exercising the  
relevant code path. Unfortunately 9.5 cannot handle two waiting  
sessions, and thus cannot execute this test.  
  
Reported-By: Viren Negi, Oskari Saarenmaa  
Author: Oskari Saarenmaa, edited a bit by me  
Bug: #14150  
Discussion: <20160519123338.12513.20271@wrigleys.postgresql.org>  
Backpatch: 9.5, where ON CONFLICT was introduced  

commit   : 8cb23dba8d75d9be8f1cc58bdfcbcd8e410be39a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 17 Aug 2016 13:15:03 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 17 Aug 2016 13:15:03 -0700    

Slot creation did not clear all fields upon creation. After start the  
memory is zeroed, but when a physical replication slot was created in  
the shared memory of a previously existing logical slot, catalog_xmin  
would not be cleared. That in turn would prevent vacuum from doing its  
duties.  
  
To fix initialize all the fields. To make similar future bugs less  
likely, zero all of ReplicationSlotPersistentData, and re-order the  
rest of the initialization to be in struct member order.  
  
Analysis: Andrew Gierth  
Reported-By: md@chewy.com  
Author: Michael Paquier  
Discussion: <20160705173502.1398.70934@wrigleys.postgresql.org>  
Backpatch: 9.4, where replication slots were introduced  

commit   : d715b76d12fa516370ce0b56a708fe1521605b66    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Aug 2016 15:51:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Aug 2016 15:51:10 -0400    

As implemented, -e ran an EXPLAIN but then discarded the output, which  
certainly seems pointless.  Make it print to stdout instead.  It's been  
like that forever, so back-patch to all supported branches.  
  
Daniel Gustafsson, reviewed by Andreas Scherbaum  
  
Patch: <B97BDCB7-A3B3-4734-90B5-EDD586941629@yesql.se>  

commit   : 9b33c7e80d5ac9d85cbb9330f172a5e606876b1c    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 17 Aug 2016 10:39:22 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 17 Aug 2016 10:39:22 +0200    

The performance overhead of this can be significant on Windows, and most  
people don't have the tools to view it anyway as Windows does not have  
native support for process titles.  
  
Discussion: <0A3221C70F24FB45833433255569204D1F5BE3E8@G01JPEXMBYT05>  
  
Takayuki Tsunakawa  

commit   : dd028e904c67dae5f5d51da73628a8bd3cb1f5f1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 16 Aug 2016 23:04:50 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 16 Aug 2016 23:04:50 -0400    

Backpatch-through: 9.6  

commit   : f1222ad61a362e67ebb9284d0265470d05b5e338    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2016 16:14:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2016 16:14:16 -0400    

I'm not sure which bozo thought it's a problem to use strtol() only  
for its endptr result, but silence the warning using same method  
used elsewhere.  
  
Report: <f845d3a6-5328-3e2a-924f-f8e91aa2b6d2@2ndquadrant.com>  

commit   : 32b99efd6a39ca06abe0514865da5f75e2e3f69b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2016 15:58:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2016 15:58:30 -0400    

This is somewhat cosmetic, since as long as you know what you are looking  
at, "10.0" is a serviceable substitute for "10".  But there is a potential  
for confusion between version numbers with minor numbers and those without  
--- we don't want people asking "why is psql saying 10.0 when my server is  
10.2".  Therefore, back-patch as far as practical, which turns out to be  
9.3.  I could have redone the patch to use fprintf(stderr) in place of  
psql_error(), but it seems more work than is warranted for branches that  
will be EOL or nearly so by the time v10 comes out.  
  
Although only psql seems to contain any code that needs this, I chose  
to put the support function into fe_utils, since it seems likely we'll  
need it in other client programs in future.  (In 9.3-9.5, use dumputils.c,  
the predecessor of fe_utils/string_utils.c.)  
  
In HEAD, also fix the backend code that whines about loadable-library  
version mismatch.  I don't see much need to back-patch that.  

commit   : 203bf7f4078451c2a75c21251882227cf67e1cd3    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 16 Aug 2016 12:00:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 16 Aug 2016 12:00:00 -0400    

From: Jeff Janes <jeff.janes@gmail.com>  

commit   : 7c7630c2022156d54adf6c1d27c30f2b75138f03    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 16 Aug 2016 12:00:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 16 Aug 2016 12:00:00 -0400    

From: Alexander Law <exclusion@gmail.com>  

commit   : 0aa1e9a44db0b8f8b08acadf2833c724489bd279    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 16 Aug 2016 13:23:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 16 Aug 2016 13:23:32 -0400    

Commit af33039317ddc4a0e38a02e2255c2bf453115fd2 aimed to reduce  
leakage from tqueue.c, which is good.  Unfortunately, by changing the  
memory context in which all of gather_readnext() executes, it also  
changed the context in which ExecShutdownGatherWorkers executes, which  
is not good, because that function eventually causes a call to  
ExecParallelRetrieveInstrumentation, which proceeds to allocate  
planstate->worker_instrument in a short-lived context, causing a  
crash.  
  
Rushabh Lathia, reviewed by Amit Kapila and by me.  

commit   : d95a7c3fbcfd5e65802f7fb0bee31a914160d9ed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2016 11:35:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2016 11:35:36 -0400    

Improve shaky English grammar.  And markup.  

commit   : 23e0d97d1ca5dc4c455fec01cf4bb65158bb2484    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2016 10:59:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2016 10:59:14 -0400    

Commit 473b93287 added a sentence about that, but neglected to remove  
the adjacent sentence it had falsified.  Per Alexander Law.  

commit   : f85b1a84152f7bf019fd7a2c5eede97867dcddbb    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 16 Aug 2016 08:09:15 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 16 Aug 2016 08:09:15 -0400    

Per discussion, set the default value of max_parallel_workers_per_gather  
to 0 in 9.6 only.  We'll leave it enabled in master so that it gets  
more testing and in the hope that it can be enable by default in v10.  

commit   : b5bce6c1ec6061c8a4f730d927e162db7e2ce365    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Aug 2016 13:42:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Aug 2016 13:42:51 -0400    

commit   : 05d8dec690e9719ff9a1830f5492864104275b5e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Aug 2016 11:32:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Aug 2016 11:32:09 -0400    

Wrap the perltidy invocation into a shell script to reduce the risk of  
copy-and-paste errors.  Include removal of *.bak files in the script,  
so they don't accidentally get committed.  Improve the directions in  
the README file.  

commit   : 9389fbd0385776adf3252eb8cfe6e37a640fdff4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Aug 2016 15:06:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Aug 2016 15:06:01 -0400    

NUMERIC_MAX_PRECISION is a purely arbitrary constraint on the precision  
and scale you can write in a numeric typmod.  It might once have had  
something to do with the allowed range of a typmod-less numeric value,  
but at least since 9.1 we've allowed, and documented that we allowed,  
any value that would physically fit in the numeric storage format;  
which is something over 100000 decimal digits, not 1000.  
  
Hence, get rid of numeric_in()'s use of NUMERIC_MAX_PRECISION as a limit  
on the allowed range of the exponent in scientific-format input.  That was  
especially silly in view of the fact that you can enter larger numbers as  
long as you don't use 'e' to do it.  Just constrain the value enough to  
avoid localized overflow, and let make_result be the final arbiter of what  
is too large.  Likewise adjust ecpg's equivalent of this code.  
  
Also get rid of numeric_recv()'s use of NUMERIC_MAX_PRECISION to limit the  
number of base-NBASE digits it would accept.  That created a dump/restore  
hazard for binary COPY without doing anything useful; the wire-format  
limit on number of digits (65535) is about as tight as we would want.  
  
In HEAD, also get rid of pg_size_bytes()'s unnecessary intimacy with what  
the numeric range limit is.  That code doesn't exist in the back branches.  
  
Per gripe from Aravind Kumar.  Back-patch to all supported branches,  
since they all contain the documentation claim about allowed range of  
NUMERIC (cf commit cabf5d84b).  
  
Discussion: <2895.1471195721@sss.pgh.pa.us>  

commit   : d6c9e05cb7db64239887fac65b243229594f331d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Aug 2016 22:24:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Aug 2016 22:24:48 -0400    

In blinsert(), cope with the possibility that a page we pull from the  
notFullPage list is marked BLOOM_DELETED.  This could happen if VACUUM  
recently marked it deleted but hasn't (yet) updated the metapage.  
We can re-use such a page safely, but we *must* reinitialize it so that  
it's no longer marked deleted.  
  
Fix blvacuum() so that it updates the notFullPage list even if it's  
going to update it to empty.  The previous "optimization" of skipping  
the update seems pretty dubious, since it means that the next blinsert()  
will uselessly visit whatever pages we left in the list.  
  
Uniformly treat PageIsNew pages the same as deleted pages.  This should  
allow proper recovery if a crash occurs just after relation extension.  
  
Properly use vacuum_delay_point, not assorted ad-hoc CHECK_FOR_INTERRUPTS  
calls, in the blvacuum() main loop.  
  
Fix broken tuple-counting logic: blvacuum.c counted the number of live  
index tuples over again in each scan, leading to VACUUM VERBOSE reporting  
some multiple of the actual number of surviving index tuples after any  
vacuum that removed any tuples (since they'd be counted in blvacuum, maybe  
more than once, and then again in blvacuumcleanup, without ever zeroing the  
counter).  It's sufficient to count them in blvacuumcleanup.  
  
stats->estimated_count is a boolean, not a counter, and we don't want  
to set it true, so don't add tuple counts to it.  
  
Add a couple of Asserts that we don't overrun available space on a bloom  
page.  I don't think there's any bug there today, but the way the  
FreeBlockNumberArray size calculation is set up is scarily fragile, and  
BloomPageGetFreeSpace isn't much better.  The Asserts should help catch  
any future mistakes.  
  
Per investigation of a report from Jeff Janes.  I think the first item  
above may explain his report; the other changes were things I noticed  
while casting about for an explanation.  
  
Report: <CAMkU=1xEUuBphDwDmB1WjN4+td4kpnEniFaTBxnk1xzHCw8_OQ@mail.gmail.com>  

commit   : ed0097e4f9e6b1227935e01fa67f12a238b66064    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Aug 2016 18:31:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Aug 2016 18:31:14 -0400    

Per discussion, we should provide such functions to replace the lost  
ability to discover AM properties by inspecting pg_am (cf commit  
65c5fcd35).  The added functionality is also meant to displace any code  
that was looking directly at pg_index.indoption, since we'd rather not  
believe that the bit meanings in that field are part of any client API  
contract.  
  
As future-proofing, define the SQL API to not assume that properties that  
are currently AM-wide or index-wide will remain so unless they logically  
must be; instead, expose them only when inquiring about a specific index  
or even specific index column.  Also provide the ability for an index  
AM to override the behavior.  
  
In passing, document pg_am.amtype, overlooked in commit 473b93287.  
  
Andrew Gierth, with kibitzing by me and others  
  
Discussion: <87mvl5on7n.fsf@news-spur.riddles.org.uk>  

commit   : 499787819309293f3d2cd7219aee334a0e7d5069    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Aug 2016 18:45:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Aug 2016 18:45:18 -0400    

Apparently that's not obvious to everybody, so let's belabor the point.  
  
In passing, document that DROP POLICY has CASCADE/RESTRICT options (which  
it does, per gram.y) but they do nothing (I assume, anyway).  Also update  
some long-obsolete commentary in gram.y.  
  
Discussion: <20160805104837.1412.84915@wrigleys.postgresql.org>  

commit   : 4b234fd8bf21cd6f5ff44f1f1c613bf40860998d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Aug 2016 12:13:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Aug 2016 12:13:04 -0400    

EXPLAIN (ANALYZE, TIMING OFF) would print an elapsed time of zero for  
a trigger function, because no measurement has been taken but it printed  
the field anyway.  This isn't what EXPLAIN does elsewhere, so suppress it.  
  
In the same vein, EXPLAIN (ANALYZE, BUFFERS) with non-text output format  
would print buffer I/O timing numbers even when no measurement has been  
taken because track_io_timing is off.  That seems not per policy, either,  
so change it.  
  
Back-patch to 9.2 where these features were introduced.  
  
Maksim Milyutin  
  
Discussion: <081c0540-ecaa-bd29-3fd2-6358f3b359a9@postgrespro.ru>  

commit   : e05f6f75dbe00a7349dccf1116b5ed983b4728c0    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 12 Aug 2016 12:43:45 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 12 Aug 2016 12:43:45 +0100    

Commit 14e8803f1 removed LWLocks when accessing MyProc->syncRepState  
but didn't clean up the surrounding code and comments.  
  
Cleanup and backpatch to 9.5, to keep code similar.  
  
Julien Rouhaud, improved by suggestion from Michael Paquier,  
implemented trivially by myself.  

commit   : 6e75559ea9cb0bc8fd07543567cd02d4ec85ca20    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 12 Aug 2016 10:34:43 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 12 Aug 2016 10:34:43 +0100    

Original wording was correct but not the intended meaning.  
  
Reported by Patrik Wenger  

commit   : 371b572df2d7e24750f8d0fc2e45d673ac70beec    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 11 Aug 2016 15:09:24 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 11 Aug 2016 15:09:24 -0400    

commit   : e3049285a3b8790e26e584fdf1ca31ea2e2eb4bc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Aug 2016 12:23:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Aug 2016 12:23:35 -0400    

Don't spell "InvalidOid" as "0".  Initialize method fields in the same  
order as amapi.h declares them (and every other AM handler initializes  
them).  

commit   : 0f249fe5f5cb3c83fd8e05743740b35ff5d34196    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Aug 2016 11:22:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Aug 2016 11:22:25 -0400    

Commit 874fe3aea changed the command tag returned for CREATE MATVIEW/CREATE  
TABLE AS ... WITH NO DATA, but missed that there was code in spi.c that  
expected the command tag to always be "SELECT".  Fortunately, the  
consequence was only an Assert failure, so this oversight should have no  
impact in production builds.  
  
Since this code path was evidently un-exercised, add a regression test.  
  
Per report from Shivam Saxena. Back-patch to 9.3, like the previous commit.  
  
Michael Paquier  
  
Report: <97218716-480B-4527-B5CD-D08D798A0C7B@dresources.com>  

commit   : fd5a2db774c1952567f75603dffb6d9fb0b0013d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Aug 2016 23:08:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Aug 2016 23:08:44 -0400    

commit   : ff2fd6b06ac00a3c5d451063e0a87dca6156db4e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Aug 2016 21:39:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Aug 2016 21:39:50 -0400    

Previous contents of adminpack.sgml were rather far short of project norms.  
Not to mention being outright wrong about the signature of pg_file_read().  

commit   : ab0a23c7c9a4b6dfba7fbffe798452299a6444b9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 Aug 2016 19:07:24 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 Aug 2016 19:07:24 -0400    

commit   : 2abf92bc698558699c199ff14261b00ee92e98dd    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 9 Aug 2016 18:36:16 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 9 Aug 2016 18:36:16 -0400    

commit   : e775d35317590793863327fedcf3737c3ab838d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Aug 2016 13:39:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Aug 2016 13:39:24 -0400    

Per discussion with David Johnston.  

commit   : 67c08c0d704a5f828492642bf9d133cbb2af3661    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Aug 2016 16:25:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Aug 2016 16:25:04 -0400    

commit   : cfdadf5f930c4e613e3a13ab09673856aa59351e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 8 Aug 2016 14:02:16 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 8 Aug 2016 14:02:16 -0400    

Author: Oleg Bartunov  

commit   : de4b3ea16d8b053e95eb9d862075b0de123e45b9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Aug 2016 13:13:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Aug 2016 13:13:05 -0400    

commit   : 9b8271c5a655ef1c35141b266d5039da8d3b2337    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Aug 2016 11:56:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Aug 2016 11:56:10 -0400    

Security: CVE-2016-5423, CVE-2016-5424  

commit   : 9a46324fd46506c86b190d3163902ed90072c53c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Aug 2016 11:12:59 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Aug 2016 11:12:59 -0400    

Several places in NUM_numpart_from_char(), which is called from the SQL  
function to_number(text, text), could accidentally read one byte past  
the end of the input buffer (which comes from the input text datum and  
is not null-terminated).  
  
1. One leading space character would be skipped, but there was no check  
   that the input was at least one byte long.  This does not happen in  
   practice, but for defensiveness, add a check anyway.  
  
2. Commit 4a3a1e2cf apparently accidentally doubled that code that skips  
   one space character (so that two spaces might be skipped), but there  
   was no overflow check before skipping the second byte.  Fix by  
   removing that duplicate code.  
  
3. A logic error would allow a one-byte over-read when looking for a  
   trailing sign (S) placeholder.  
  
In each case, the extra byte cannot be read out directly, but looking at  
it might cause a crash.  
  
The third item was discovered by Piotr Stefaniak, the first two were  
found and analyzed by Tom Lane and Peter Eisentraut.  

commit   : 34927b2920a865559be743836c1aa60a3621c133    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Aug 2016 11:08:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Aug 2016 11:08:00 -0400    

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

commit   : f0c7b789ab12fbc8248b671c7882dd96ac932ef4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Aug 2016 10:33:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Aug 2016 10:33:46 -0400    

ExecEvalCase() tried to save a cycle or two by passing  
&econtext->caseValue_isNull as the isNull argument to its sub-evaluation of  
the CASE value expression.  If that subexpression itself contained a CASE,  
then *isNull was an alias for econtext->caseValue_isNull within the  
recursive call of ExecEvalCase(), leading to confusion about whether the  
inner call's caseValue was null or not.  In the worst case this could lead  
to a core dump due to dereferencing a null pointer.  Fix by not assigning  
to the global variable until control comes back from the subexpression.  
Also, avoid using the passed-in isNull pointer transiently for evaluation  
of WHEN expressions.  (Either one of these changes would have been  
sufficient to fix the known misbehavior, but it's clear now that each of  
these choices was in itself dangerous coding practice and best avoided.  
There do not seem to be any similar hazards elsewhere in execQual.c.)  
  
Also, it was possible for inlining of a SQL function that implements the  
equality operator used for a CASE comparison to result in one CASE  
expression's CaseTestExpr node being inserted inside another CASE  
expression.  This would certainly result in wrong answers since the  
improperly nested CaseTestExpr would be caused to return the inner CASE's  
comparison value not the outer's.  If the CASE values were of different  
data types, a crash might result; moreover such situations could be abused  
to allow disclosure of portions of server memory.  To fix, teach  
inline_function to check for "bare" CaseTestExpr nodes in the arguments of  
a function to be inlined, and avoid inlining if there are any.  
  
Heikki Linnakangas, Michael Paquier, Tom Lane  
  
Report: https://github.com/greenplum-db/gpdb/pull/327  
Report: <4DDCEEB8.50602@enterprisedb.com>  
Security: CVE-2016-5423  

commit   : fcd15f13581f6d75c63d213220d5a94889206c1b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

Due to simplistic quoting and confusion of database names with conninfo  
strings, roles with the CREATEDB or CREATEROLE option could escalate to  
superuser privileges when a superuser next ran certain maintenance  
commands.  The new coding rule for PQconnectdbParams() calls, documented  
at conninfo_array_parse(), is to pass expand_dbname=true and wrap  
literal database names in a trivial connection string.  Escape  
zero-length values in appendConnStrVal().  Back-patch to 9.1 (all  
supported versions).  
  
Nathan Bossart, Michael Paquier, and Noah Misch.  Reviewed by Peter  
Eisentraut.  Reported by Nathan Bossart.  
  
Security: CVE-2016-5424  

commit   : 41f18f021a0882eccbeca62e2ed4b66c6b96e9c9    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

Rename these newly-extern functions with terms more typical of their new  
neighbors.  No functional changes; a subsequent commit will use them in  
more places.  Back-patch to 9.1 (all supported versions).  Back branches  
lack src/fe_utils, so instead rename the functions in place; the  
subsequent commit will copy them into the other programs using them.  
  
Security: CVE-2016-5424  

commit   : bd65371851b7a9964b4b265d06fe1304315e37c1    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

The incorrect quoting may have permitted arbitrary command execution.  
At a minimum, it gave broader control over the command line to actors  
supposed to have control over a single argument.  Back-patch to 9.1 (all  
supported versions).  
  
Security: CVE-2016-5424  

commit   : 142c24c23447f212e642a0ffac9af878b93f490d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

These characters prematurely terminate Windows shell command processing,  
causing the shell to execute a prefix of the intended command.  The  
chief alternative to rejecting these characters was to bypass the  
Windows shell with CreateProcess(), but the ability to use such names  
has little value.  Back-patch to 9.1 (all supported versions).  
  
This change formally revokes support for these characters in database  
names and roles names.  Don't document this; the error message is  
self-explanatory, and too few users would benefit.  A future major  
release may forbid creation of databases and roles so named.  For now,  
check only at known weak points in pg_dumpall.  Future commits will,  
without notice, reject affected names from other frontend programs.  
  
Also extend the restriction to pg_dumpall --dbname=CONNSTR arguments and  
--file arguments.  Unlike the effects on role name arguments and  
database names, this does not reflect a broad policy change.  A  
migration to CreateProcess() could lift these two restrictions.  
  
Reviewed by Peter Eisentraut.  
  
Security: CVE-2016-5424  

commit   : c400717172d77e5b07e51e04c5e5e13da181572e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

These programs nominally accepted conninfo strings, but they would  
proceed to use the original dbname parameter as though it were an  
unadorned database name.  This caused "reindexdb dbname=foo" to issue an  
SQL command that always failed, and other programs printed a conninfo  
string in error messages that purported to print a database name.  Fix  
both problems by using PQdb() to retrieve actual database names.  
Continue to print the full conninfo string when reporting a connection  
failure.  It is informative there, and if the database name is the sole  
problem, the server-side error message will include the name.  Beyond  
those user-visible fixes, this allows a subsequent commit to synthesize  
and use conninfo strings without that implementation detail leaking into  
messages.  As a side effect, the "vacuuming database" message now  
appears after, not before, the connection attempt.  Back-patch to 9.1  
(all supported versions).  
  
Reviewed by Michael Paquier and Peter Eisentraut.  
  
Security: CVE-2016-5424  

commit   : 9d924e9a64b91571e04252424c01210fc0f6f6d9    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

The decision to reuse values of parameters from a previous connection  
has been based on whether the new target is a conninfo string.  Add this  
means of overriding that default.  This feature arose as one component  
of a fix for security vulnerabilities in pg_dump, pg_dumpall, and  
pg_upgrade, so back-patch to 9.1 (all supported versions).  In 9.3 and  
later, comment paragraphs that required update had already-incorrect  
claims about behavior when no connection is open; fix those problems.  
  
Security: CVE-2016-5424  

commit   : 984e5beb38a7c79a5a9243865d9598c405df17f6    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Aug 2016 10:07:46 -0400    

In arguments, these meta-commands wrongly treated each pair as closing  
the double quoted string.  Make the behavior match the documentation.  
This is a compatibility break, but I more expect to find software with  
untested reliance on the documented behavior than software reliant on  
today's behavior.  Back-patch to 9.1 (all supported versions).  
  
Reviewed by Tom Lane and Peter Eisentraut.  
  
Security: CVE-2016-5424  

commit   : a1f8b6bd14adb724365d91dcc58079ac3a2293e7    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Aug 2016 09:27:20 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Aug 2016 09:27:20 -0400    

From: Alexander Law <exclusion@gmail.com>  

commit   : 8a56d4e361d4566ce5d6b55f25c3f23aa44f4741    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Aug 2016 08:15:41 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Aug 2016 08:15:41 -0400    

07d25a964 changed only one occurrence.  Change the other one as well.  

commit   : be7f7ee5ea73626c037600b515087e8f98038140    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 22:24:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 22:24:44 -0400    

commit   : d8710f18f4a63947874301311f5558e7d3d93438    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 7 Aug 2016 21:53:16 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 7 Aug 2016 21:53:16 -0400    

Although the standard has routines.result_cast_character_set_name, given  
the naming of the surrounding columns, we concluded that this must have  
been a mistake and that result_cast_char_set_name was intended, so  
change the implementation.  The documentation was already using the new  
name.  
  
found by Clément Prévost <prevostclement@gmail.com>  

commit   : 19322c0a785f656b82a780c3db44920dcc9bd658    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 21:31:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 21:31:01 -0400    

commit   : 4a1f42f287c33e457cb3f081e692853a65dc0efb    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 7 Aug 2016 21:27:36 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 7 Aug 2016 21:27:36 -0400    

commit   : 95bee941be4c009ebbc29162a0dc9664f40de12f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 18:52:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 18:52:02 -0400    

If ANALYZE found no repeated non-null entries in its sample, it set the  
column's stadistinct value to -1.0, intending to indicate that the entries  
are all distinct.  But what this value actually means is that the number  
of distinct values is 100% of the table's rowcount, and thus it was  
overestimating the number of distinct values by however many nulls there  
are.  This could lead to very poor selectivity estimates, as for example  
in a recent report from Andreas Joseph Krogh.  We should discount the  
stadistinct value by whatever we've estimated the nulls fraction to be.  
(That is what will happen if we choose to use a negative stadistinct for  
a column that does have repeated entries, so this code path was just  
inconsistent.)  
  
In addition to fixing the stadistinct entries stored by several different  
ANALYZE code paths, adjust the logic where get_variable_numdistinct()  
forces an "all distinct" estimate on the basis of finding a relevant unique  
index.  Unique indexes don't reject nulls, so there's no reason to assume  
that the null fraction doesn't apply.  
  
Back-patch to all supported branches.  Back-patching is a bit of a judgment  
call, but this problem seems to affect only a few users (else we'd have  
identified it long ago), and it's bad enough when it does happen that  
destabilizing plan choices in a worse direction seems unlikely.  
  
Patch by me, with documentation wording suggested by Dean Rasheed  
  
Report: <VisenaEmail.26.df42f82acae38a58.156463942b8@tc7-visena>  
Discussion: <16143.1470350371@sss.pgh.pa.us>  

commit   : 8a8c6b53810026641a1e12f60f873a7bd3cea5e3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 17:56:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 17:56:34 -0400    

Oversight in commit 976b24fb4.  
  
Andreas Seltenreich  
  
Report: <87y448l3ag.fsf@credativ.de>  

commit   : 9ee1cf04ab6bcefe03a11837b53f29ca9dc24c7a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 17:46:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 17:46:08 -0400    

Discussion of commit 3e2f3c2e4 exposed a problem that is of longer  
standing: since we don't detoast data while sticking it into a portal's  
holdStore for PORTAL_ONE_RETURNING and PORTAL_UTIL_SELECT queries, and we  
release the query's snapshot as soon as we're done loading the holdStore,  
later readout of the holdStore can do TOAST fetches against data that can  
no longer be seen by any of the session's live snapshots.  This means that  
a concurrent VACUUM could remove the TOAST data before we can fetch it.  
Commit 3e2f3c2e4 exposed the problem by showing that sometimes we had *no*  
live snapshots while fetching TOAST data, but we'd be at risk anyway.  
  
I believe this code was all right when written, because our management of a  
session's exposed xmin was such that the TOAST references were safe until  
end of transaction.  But that's no longer true now that we can advance or  
clear our PGXACT.xmin intra-transaction.  
  
To fix, copy the query's snapshot during FillPortalStore() and save it in  
the Portal; release it only when the portal is dropped.  This essentially  
implements a policy that we must hold a relevant snapshot whenever we  
access potentially-toasted data.  We had already come to that conclusion  
in other places, cf commits 08e261cbc94ce9a7 and ec543db77b6b72f2.  
  
I'd have liked to add a regression test case for this, but I didn't see  
a way to make one that's not unreasonably bloated; it seems to require  
returning a toasted value to the client, and those will be big.  
  
In passing, improve PortalRunUtility() so that it positively verifies  
that its ending PopActiveSnapshot() call will pop the expected snapshot,  
removing a rather shaky assumption about which utility commands might  
do their own PopActiveSnapshot().  There's no known bug here, but now  
that we're actively referencing the snapshot it's almost free to make  
this code a bit more bulletproof.  
  
We might want to consider back-patching something like this into older  
branches, but it would be prudent to let it prove itself more in HEAD  
beforehand.  
  
Discussion: <87vazemeda.fsf@credativ.de>  

commit   : 07a601eedab7c5fa4d62055fa3efacef2f38e446    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 14:36:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 14:36:02 -0400    

The sole caller expects NULL to be returned in such a case, so make  
it so and document it.  
  
Per reports from Andreas Seltenreich and Regina Obe.  This doesn't  
really fix their problem, as now their RETURNING queries will say  
"ERROR: no known snapshots", but in any case this function should  
not dump core in a reasonably-foreseeable situation.  
  
Report: <87vazemeda.fsf@credativ.de>  
Report: <20160807051854.1427.32414@wrigleys.postgresql.org>  

commit   : bcbecbce2fde3c6dfa9080db11663877808a007d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 13:15:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Aug 2016 13:15:55 -0400    

This oversight could cause logical decoding to fail to decode an outer  
transaction containing changes, if a subtransaction had an XID but no  
actual changes.  Per bug #14279 from Marko Tiikkaja.  Patch by Marko  
based on analysis by Andrew Gierth.  
  
Discussion: <20160804191757.1430.39011@wrigleys.postgresql.org>  

commit   : 3676631c687009c2fadcb35e7d312e9eb8a98182    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Aug 2016 22:08:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Aug 2016 22:08:31 -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   : e89526d4f3567c58c2a69fa1b1d9e44df89349fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Aug 2016 14:28:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Aug 2016 14:28:37 -0400    

In _bt_unlink_halfdead_page(), we might fail to find an immediate left  
sibling of the target page, perhaps because of corruption of the page  
sibling links.  The code intends to cope with this by just abandoning  
the deletion attempt; but what actually happens is that it fails outright  
due to releasing the same buffer lock twice.  (And error recovery masks  
a second problem, which is possible leakage of a pin on another page.)  
Seems to have been introduced by careless refactoring in commit efada2b8e.  
Since there are multiple cases to consider, let's make releasing the buffer  
lock in the failure case the responsibility of _bt_unlink_halfdead_page()  
not its caller.  
  
Also, avoid fetching the leaf page's left-link again after we've dropped  
lock on the page.  This is probably harmless, but it's not exactly good  
coding practice.  
  
Per report from Kyotaro Horiguchi.  Back-patch to 9.4 where the faulty code  
was introduced.  
  
Discussion: <20160803.173116.111915228.horiguchi.kyotaro@lab.ntt.co.jp>  

commit   : 69dc5ae408f68c302029a6b43912a2cc16b1256c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 18:58:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 18:58:12 -0400    

Beginning with the next development cycle, PG servers will report two-part  
not three-part version numbers.  Fix libpq so that it will compute the  
correct numeric representation of such server versions for reporting by  
PQserverVersion().  It's desirable to get this into the field and  
back-patched ASAP, so that older clients are more likely to understand the  
new server version numbering by the time any such servers are in the wild.  
  
(The results with an old client would probably not be catastrophic anyway  
for a released server; for example "10.1" would be interpreted as 100100  
which would be wrong in detail but would not likely cause an old client to  
misbehave badly.  But "10devel" or "10beta1" would result in sversion==0  
which at best would result in disabling all use of modern features.)  
  
Extracted from a patch by Peter Eisentraut; comments added by me  
  
Patch: <802ec140-635d-ad86-5fdf-d3af0e260c22@2ndquadrant.com>  

commit   : fc509cd82443a4cf338032492f6b1bd6e8698f8d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 16:21:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 16:21:38 -0400    

Report: <57A4E6DF.8070209@dunslane.net>  

commit   : f10eab73df2b94c860dea4a906c54e3c903f42e2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 16:09:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 16:09:06 -0400    

This is required for the result to be a legal tsvector value.  
Noted while fooling with Andreas Seltenreich's ts_delete() crash.  
  
Discussion: <87invhoj6e.fsf@credativ.de>  

commit   : c50d192ce33c10fa06411306f8644b4f47ce9a06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 15:14:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 15:14:08 -0400    

Such cases either failed an Assert, or produced a corrupt tsvector in  
non-Assert builds, as reported by Andreas Seltenreich.  The reason is  
that tsvector_delete_by_indices() just assumed that its input array had  
no duplicates.  Fix by explicitly de-duping.  
  
In passing, improve some comments, and fix a number of tests for null  
values to use ERRCODE_NULL_VALUE_NOT_ALLOWED not  
ERRCODE_INVALID_PARAMETER_VALUE.  
  
Discussion: <87invhoj6e.fsf@credativ.de>  

commit   : 33fe7360afdc0bb1820743ea5bfe3fc7d522f6c4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 14:58:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 14:58:13 -0400    

Messed up by recent commits --- this is annoying me while trying to fix  
some bugs here.  

commit   : 5ebad9a580d8f80943fd7095db14621278cc009c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Aug 2016 14:35:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Aug 2016 14:35:09 -0400    

This reverts the spaces before k/M/G/TB units removed for consistency in  
commit ca0c37b56f4a80ad758774e34c86cc4335583d29.  
  
Discussion: 20160802165116.GC32575@momjian.us  

commit   : a629330b2990c2e76cc8e45a78ede0920c16e0bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 12:58:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2016 12:58:17 -0400    

DST law changes in Kemerovo and Novosibirsk.  Historical corrections for  
Azerbaijan, Belarus, and Morocco.  Asia/Novokuznetsk and Asia/Novosibirsk  
now use numeric time zone abbreviations instead of invented ones.  Zones  
for Antarctic bases and other locations that have been uninhabited for  
portions of the time span known to the tzdata database now report "-00"  
rather than "zzz" as the zone abbreviation for those time spans.  
  
Also, I decided to remove some of the timezone/data/ files that we don't  
use.  At one time that subdirectory was a complete copy of what IANA  
distributes in the tzdata tarballs, but that hasn't been true for a long  
time.  There seems no good reason to keep shipping those specific files  
but not others; they're just bloating our tarballs.  

commit   : 81c766b3fd41c78c634d78ebae8d316808dfc630    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 5 Aug 2016 11:57:00 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 5 Aug 2016 11:57:00 -0400    

tqual.h is included in some front-end compiles, and a static inline  
breaks on buildfarm member castoroides.  Since the macro is never  
referenced, it should dodge that problem, although this doesn't  
seem like the cleanest way of hiding things from front-end compiles.  
  
Report and review by Tom Lane; patch by me.  

commit   : e7caacf733f3ee77a555aa715ab6fbf4434e6b52    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 4 Aug 2016 20:07:16 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 4 Aug 2016 20:07:16 -0700    

As mentioned in its commit message, eca0f1db left open a race condition,  
where a page could be marked all-visible, after the code checked  
PageIsAllVisible() to pin the VM, but before the page is locked.  Plug  
that hole.  
  
Reviewed-By: Robert Haas, Andres Freund  
Author: Amit Kapila  
Discussion: CAEepm=3fWAbWryVW9swHyLTY4sXVf0xbLvXqOwUoDiNCx9mBjQ@mail.gmail.com  
Backpatch: -  

commit   : 4eb4b3f24561cb115b24984c755b2a75155afedf    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 4 Aug 2016 18:55:16 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 4 Aug 2016 18:55:16 -0400    

This happens when using rsync to pg_upgrade slaves.  
  
Reported-by: Jerry Sievers  
  
Discussion: 20160726161946.GA3511@momjian.us  

commit   : 8d498a5c8a4c702ca71463a5c76bb4f319872378    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Aug 2016 16:06:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Aug 2016 16:06:14 -0400    

Some conditions resulted in "return" directly out of a PG_TRY block,  
which left the exception stack dangling, and to add insult to injury  
failed to restore the state of set_latch_on_sigusr1.  
  
This is a bug only in 9.5; in HEAD it was accidentally fixed by commit  
db0f6cad4, which removed the surrounding PG_TRY block.  However, I (tgl)  
chose to apply the patch to HEAD as well, because the old coding was  
gratuitously different from WaitForBackgroundWorkerStartup(), and there  
would indeed have been no bug if it were done like that to start with.  
  
Dmitry Ivanov  
  
Discussion: <1637882.WfYN5gPf1A@abook>  

commit   : 81568a971f2634bc447af2788eafee899f2db2a1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 Aug 2016 17:02:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 Aug 2016 17:02:00 -0400    

commit   : 3e2f3c2e423b3ae906668c186bac79522b8e3e29    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 3 Aug 2016 16:41:43 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 3 Aug 2016 16:41:43 -0400    

Previously, we tested for MVCC snapshots to see whether they were too  
old, but not TOAST snapshots, which can lead to complaints about missing  
TOAST chunks if those chunks are subject to early pruning.  Ideally,  
the threshold lsn and timestamp for a TOAST snapshot would be that of  
the corresponding MVCC snapshot, but since we have no way of deciding  
which MVCC snapshot was used to fetch the TOAST pointer, use the oldest  
active or registered snapshot instead.  
  
Reported by Andres Freund, who also sketched out what the fix should  
look like.  Patch by me, reviewed by Amit Kapila.  

commit   : a3c7a993d5eb29df4d33075b83c75ae25f257897    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Aug 2016 16:37:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Aug 2016 16:37:03 -0400    

Previously, if an INSERT with multiple rows of VALUES had indirection  
(array subscripting or field selection) in its target-columns list, the  
parser handled that by applying transformAssignedExpr() to each element  
of each VALUES row independently.  This led to having ArrayRef assignment  
nodes or FieldStore nodes in each row of the VALUES RTE.  That works for  
simple cases, but in bug #14265 Nuri Boardman points out that it fails  
if there are multiple assignments to elements/fields of the same target  
column.  For such cases to work, rewriteTargetListIU() has to nest the  
ArrayRefs or FieldStores together to produce a single expression to be  
assigned to the column.  But it failed to find them in the top-level  
targetlist and issued an error about "multiple assignments to same column".  
  
We could possibly fix this by teaching the rewriter to apply  
rewriteTargetListIU to each VALUES row separately, but that would be messy  
(it would change the output rowtype of the VALUES RTE, for example) and  
inefficient.  Instead, let's fix the parser so that the VALUES RTE outputs  
are just the user-specified values, cast to the right type if necessary,  
and then the ArrayRefs or FieldStores are applied in the top-level  
targetlist to Vars representing the RTE's outputs.  This is the same  
parsetree representation already used for similar cases with INSERT/SELECT  
syntax, so it allows simplifications in ruleutils.c, which no longer needs  
to treat INSERT-from-multiple-VALUES as its own special case.  
  
This implementation works by applying transformAssignedExpr to the VALUES  
entries as before, and then stripping off any ArrayRefs or FieldStores it  
adds.  With lots of VALUES rows it would be noticeably more efficient to  
not add those nodes in the first place.  But that's just an optimization  
not a bug fix, and there doesn't seem to be any good way to do it without  
significant refactoring.  (A non-invasive answer would be to apply  
transformAssignedExpr + stripping to just the first VALUES row, and then  
just forcibly cast remaining rows to the same data types exposed in the  
first row.  But this way would lead to different, not-INSERT-specific  
errors being reported in casting failure cases, so it doesn't seem very  
nice.)  So leave that for later; this patch at least isn't making the  
per-row parsing work worse, and it does make the finished parsetree  
smaller, saving rewriter and planner work.  
  
Catversion bump because stored rules containing such INSERTs would need  
to change.  Because of that, no back-patch, even though this is a very  
long-standing bug.  
  
Report: <20160727005725.7438.26021@wrigleys.postgresql.org>  
Discussion: <9578.1469645245@sss.pgh.pa.us>  

commit   : ef1b5af82339a49564037be656a3ff657fb2a246    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Aug 2016 14:48:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Aug 2016 14:48:05 -0400    

We don't want postmaster child processes to contain a copy of the  
postmaster's PostmasterContext.  That would be a waste of memory at least,  
and at worst a security issue, since there are copies of the semi-sensitive  
pg_hba and pg_ident data in there.  All other child process types delete  
the PostmasterContext after forking, but the original coding of the  
background worker patch (commit da07a1e85) did not do so.  It appears  
that the only reason for that was to avoid copying the bgworker's  
MyBgworkerEntry out of that context; but the couple of additional  
statements needed to do so are hardly good justification for it.  Hence,  
copy that data and then clear the context as other child processes do.  
  
Because this patch changes the memory context in which a bgworker function  
gains control, back-patching it would be a bit risky, so we won't fix this  
in back branches.  The "security" complaint is pretty thin anyway for  
generic bgworkers; only with the introduction of parallel query is there  
any question of running untrusted code in a bgworker process.  
  
Discussion: <14111.1470082717@sss.pgh.pa.us>  

commit   : 6a9e09c49e1405c47b0870de73fec5748302f92d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 Aug 2016 14:41:01 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 Aug 2016 14:41:01 -0400    

From: Clément Prévost <prevostclement@gmail.com>  

commit   : 2b8fd4fa67693b0b07c412eed34c6b6da6c74d43    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 Aug 2016 13:45:55 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 Aug 2016 13:45:55 -0400    

These were probably copied in by accident.  
  
From: Clément Prévost <prevostclement@gmail.com>  

commit   : b26f7fa6ae2b4e5d64525b3d5bc66a0ddccd9e24    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 3 Aug 2016 13:21:23 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 3 Aug 2016 13:21:23 -0400    

In test 001_stream_rep we're using pg_stat_replication.write_location to  
determine catch-up status, but we care about xlog having been applied  
not just received, so change that to apply_location.  
  
In test 003_recovery_targets, we query the database for a recovery  
target specification and later for the xlog position supposedly  
corresponding to that recovery specification.  If for whatever reason  
more WAL is written between the two queries, the recovery specification  
is earlier than the xlog position used by the query in the test harness,  
so we wait forever, leading to test failures.  Deal with this by using a  
single query to extract both items.  In 2a0f89cd717 we tried to deal  
with it by giving them more tests to run, but in hindsight that was  
obviously doomed to failure (no revert of that, though).  
  
Per hamster buildfarm failures.  
  
Author: Michaël Paquier  

commit   : 69bdfc4090816d77a3d08684a30bfb05f8b1e104    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 Aug 2016 12:29:15 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 Aug 2016 12:29:15 -0400    

Suggest a statement trigger instead.  

commit   : c93d8737be47667091b36f5852fd706146514008    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 3 Aug 2016 09:58:50 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 3 Aug 2016 09:58:50 -0500    

Ashutosh Sharma with minor fixes by me.  

commit   : 6eb5b05d225006adaf38adc9f30637ee22521881    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 3 Aug 2016 10:32:32 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 3 Aug 2016 10:32:32 -0400    

Author: Amit Langote  

commit   : 0a4d67b16cd6a0d435169e66a1b4911007cb6aef    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 2 Aug 2016 22:34:45 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 2 Aug 2016 22:34:45 -0400    

It seems clearer to refer to these tables in the normal way.  

commit   : 071049919566c22a276ae6441097c436e382a679    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 2 Aug 2016 22:33:56 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 2 Aug 2016 22:33:56 -0400    

Dmitry Igrishin  

commit   : c6ea616ff702862fc6923323a49dd24a0e0ae2d9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Aug 2016 18:39:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Aug 2016 18:39:14 -0400    

This is apparently harmless on Windows, but on Unix it results in an  
assertion failure.  We'd not noticed because this code doesn't get  
used on Unix unless you build with -DEXEC_BACKEND.  Bug was evidently  
introduced by sloppy refactoring in commit 31c453165.  
  
Thomas Munro  
  
Discussion: <CAEepm=1VOnbVx4wsgQFvj94hu9jVt2nVabCr7QiooUSvPJXkgQ@mail.gmail.com>  

commit   : a253a88594f6805168261ea1986df1cd6b9b25e0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Aug 2016 17:13:10 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 2 Aug 2016 17:13:10 -0400    

Discussion: 20160702155517.GD18610@momjian.us  
  
Reviewed-by: Christoph Berg  
  
Backpatch-through: 9.1  

commit   : b6a97b91ffe8e0c6b6557eb4aef85bcbd423ad5f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Aug 2016 16:39:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Aug 2016 16:39:16 -0400    

As noted by Alvaro, there are CHECK_FOR_INTERRUPTS() calls in the shm_mq.c  
functions called by HandleParallelMessages().  I believe they're all  
unreachable since we always pass nowait = true, but it doesn't seem like  
a great idea to assume that no such call will ever be reachable from  
HandleParallelMessages().  If that did happen, there would be a risk of a  
recursive call to HandleParallelMessages(), which it does not appear to be  
designed for --- for example, there's nothing that would prevent  
out-of-order processing of received messages.  And certainly such cases  
cannot easily be tested.  So let's prevent it by holding off interrupts for  
the duration of the function.  Back-patch to 9.5 which contains identical  
code.  
  
Discussion: <14869.1470083848@sss.pgh.pa.us>  

commit   : c4d3a039f0ea735c4c21831a74b753678c0e6794    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 2 Aug 2016 13:15:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 2 Aug 2016 13:15:35 -0400    

Setting it to 0 is probably not useful in practice, but it allows  
testing of situations without available background worker slots.  

commit   : e2e95f5ef3c17197e319e4bbee70486f6a33e7d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Aug 2016 12:48:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Aug 2016 12:48:51 -0400    

Since -c plus -C requests dropping and recreating the target database  
as a whole, not dropping individual objects in it, we should assume that  
the public schema already exists and need not be created.  The previous  
coding considered only the state of the -c option, so it would emit  
"CREATE SCHEMA public" anyway, leading to an unexpected error in restore.  
  
Back-patch to 9.2.  Older versions did not accept -c with -C so the  
issue doesn't arise there.  (The logic being patched here dates to 8.0,  
cf commit 2193121fa, so it's not really wrong that it didn't consider  
the case at the time.)  
  
Note that versions before 9.6 will still attempt to emit REVOKE/GRANT  
on the public schema; but that happens without -c/-C too, and doesn't  
seem to be the focus of this complaint.  I considered extending this  
stanza to also skip the public schema's ACL, but that would be a  
misfeature, as it'd break cases where users intentionally changed that  
ACL.  The real fix for this aspect is Stephen Frost's work to not dump  
built-in ACLs, and that's not going to get back-ported.  
  
Per bugs #13804 and #14271.  Solution found by David Johnston and later  
rediscovered by me.  
  
Report: <20151207163520.2628.95990@wrigleys.postgresql.org>  
Report: <20160801021955.1430.47434@wrigleys.postgresql.org>  

commit   : e9888c2a48d490ae75d8692db1b1f12c3740c21b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 2 Aug 2016 12:35:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 2 Aug 2016 12:35:35 -0400    

commit   : f6ced51f9188ad5806219471a0b40a91dde923aa    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 2 Aug 2016 10:47:03 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 2 Aug 2016 10:47:03 -0400    

commit   : a5fe473ad79d8d2c85a625621c165e8c601274e4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Aug 2016 16:12:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Aug 2016 16:12:01 -0400    

ParallelMessagePending *must* be marked volatile, because it's set  
by a signal handler.  On the other hand, it's pointless for  
HandleParallelMessageInterrupt to save/restore errno; that must be,  
and is, done at the outer level of the SIGUSR1 signal handler.  
  
Calling CHECK_FOR_INTERRUPTS() inside HandleParallelMessages, which itself  
is called from CHECK_FOR_INTERRUPTS(), seems both useless and hazardous.  
The comment claiming that this is needed to handle the error queue going  
away is certainly misguided, in any case.  
  
Improve a couple of error message texts, and use  
ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE to report loss of parallel worker  
connection, since that's what's used in e.g. tqueue.c.  (Maybe it would be  
worth inventing a dedicated ERRCODE for this type of failure?  But I do not  
think ERRCODE_INTERNAL_ERROR is appropriate.)  
  
Minor stylistic cleanups.  

commit   : 887feefe87b9099eeeec2967ec31ce20df4dfa9b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Aug 2016 15:13:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Aug 2016 15:13:53 -0400    

This coding pattern creates a race condition, because if an interesting  
interrupt happens after we've checked InterruptPending but before we reset  
our latch, the latch-setting done by the signal handler would get lost,  
and then we might block at WaitLatch in the next iteration without ever  
noticing the interrupt condition.  You can put the CHECK_FOR_INTERRUPTS  
before WaitLatch or after ResetLatch, but not between them.  
  
Aside from fixing the bugs, add some explanatory comments to latch.h  
to perhaps forestall the next person from making the same mistake.  
  
In HEAD, also replace gather_readnext's direct call of  
HandleParallelMessages with CHECK_FOR_INTERRUPTS.  It does not seem clean  
or useful for this one caller to bypass ProcessInterrupts and go straight  
to HandleParallelMessages; not least because that fails to consider the  
InterruptPending flag, resulting in useless work both here  
(if InterruptPending isn't set) and in the next CHECK_FOR_INTERRUPTS call  
(if it is).  
  
This thinko seems to have been introduced in the initial coding of  
storage/ipc/shm_mq.c (commit ec9037df2), and then blindly copied into all  
the subsequent parallel-query support logic.  Back-patch relevant hunks  
to 9.4 to extirpate the error everywhere.  
  
Discussion: <1661.1469996911@sss.pgh.pa.us>  

commit   : dd5eb805d5e5384963f09c9986845a544ef41810    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 2 Aug 2016 02:43:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 2 Aug 2016 02:43:17 +0900