PostgreSQL 9.6.0 commit log

Stamp 9.6.0.

  
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    

Click here for diff

  
  

Translation updates

  
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    

Click here for diff

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

Document has_type_privilege().

  
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    

Click here for diff

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

Do a final round of updates on the 9.6 release notes.

  
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    

Click here for diff

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

Install TAP test infrastructure so it’s available for extension testing.

  
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    

Click here for diff

  
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>  
  

Doc: fix examples of # operators so they actually work.

  
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    

Click here for diff

  
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>  
  

Fix incorrect logic for excluding range constructor functions in pg_dump.

  
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    

Click here for diff

  
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>  
  

Remove useless code.

  
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    

Click here for diff

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

Don’t trust CreateFileMapping() to clear the error code on success.

  
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    

Click here for diff

  
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>  
  

Avoid using PostmasterRandom() for DSM control segment ID.

  
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    

Click here for diff

  
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>  
  

Be sure to rewind the tuplestore read pointer in non-leader CTEScan nodes.

  
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    

Click here for diff

  
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>  
  

Add more parallel query documentation.

  
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    

Click here for diff

  
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    

Click here for diff

  
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>  
  

Fix pgbench’s calculation of average latency, when -T is not used.

  
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    

Click here for diff

  
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>  
  

doc: Fix documentation to match actual make output

  
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    

Click here for diff

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

doc: Correct ALTER USER MAPPING example

  
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    

Click here for diff

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

Re-add translation markers that were lost

  
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    

Click here for diff

  
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.  
  

Use PostmasterRandom(), not random(), for DSM control segment ID.

  
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    

Click here for diff

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

Retry DSM control segment creation if Windows indicates access denied.

  
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    

Click here for diff

  
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>  
  

Fix outdated comments, GIST search queue is not an RBTree anymore.

  
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    

Click here for diff

  
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.  
  

Fix latency calculation when there are \sleep commands in the script.

  
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    

Click here for diff

  
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>  
  

MSVC: Include pg_recvlogical in client-only install.

  
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    

Click here for diff

  
MauMau, reviewed by Michael Paquier  
  

Update recovery_min_apply_delay docs for remote_apply mode.

  
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    

Click here for diff

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

Fix ecpg -? option on Windows, add -V alias for –version.

  
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    

Click here for diff

  
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>  
  

Fix building with LibreSSL.

  
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    

Click here for diff

  
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>  
  

Make min_parallel_relation_size’s default value platform-independent.

  
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    

Click here for diff

  
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>  
  

pg_buffercache: Allow huge allocations.

  
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    

Click here for diff

  
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  
  

Support OpenSSL 1.1.0.

  
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    

Click here for diff

  
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>  
  

Fix and clarify comments on replacement selection.

  
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    

Click here for diff

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

Docs: assorted minor cleanups.

  
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    

Click here for diff

  
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  
  

Fix copy/pasto in file identification

  
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    

Click here for diff

  
Daniel Gustafsson  
  

Raise max setting of checkpoint_timeout to 1d

  
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    

Click here for diff

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

Improve unreachability recognition in elog() macro.

  
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    

Click here for diff

  
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.  
  

Fix miserable coding in pg_stat_get_activity().

  
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    

Click here for diff

  
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.  
  

Fix locking a tuple updated by an aborted (sub)transaction

  
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    

Click here for diff

  
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  
  

Fix corruption of 2PC recovery with subxacts

  
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    

Click here for diff

  
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  
  

Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL

  
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    

Click here for diff

  
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  
  

Correct TABLESAMPLE docs

  
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    

Click here for diff

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

Fix mdtruncate() to close fd.c handle of deleted segments.

  
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    

Click here for diff

  
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  
  

Fix two src/test/modules Makefiles

  
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    

Click here for diff

  
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.  
  

Allow pg_dump to dump non-extension members of an extension-owned schema.

  
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    

Click here for diff

  
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>  
  

Don’t print database’s tablespace in pg_dump -C –no-tablespaces output.

  
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    

Click here for diff

  
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>  
  

Fix minor memory leak in Standby startup

  
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    

Click here for diff

  
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  
  

9.6 release notes: correct summary item about freeze

  
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    

Click here for diff

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

Doc: minor documentation improvements about extensions.

  
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    

Click here for diff

  
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.  
  

Doc: small improvements for documentation about VACUUM freezing.

  
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    

Click here for diff

  
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>  
  

Guard against possible memory allocation botch in batchmemtuples().

  
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    

Click here for diff

  
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>  
  

Add regression test coverage for non-default timezone abbreviation sets.

  
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    

Click here for diff

  
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.  
  

Remove vestigial references to “zic” in favor of “IANA database”.

  
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    

Click here for diff

  
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.  
  

Update release notes to mention need for ALTER EXTENSION UPDATE.

  
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    

Click here for diff

  
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.  
  

Fix corrupt GIN_SEGMENT_ADDITEMS WAL records on big-endian hardware.

  
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    

Click here for diff

  
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>  
  

Fix wording of logical decoding concepts

  
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    

Click here for diff

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

Don’t require dynamic timezone abbreviations to match underlying time zone.

  
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    

Click here for diff

  
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>  
  

Prevent starting a standalone backend with standby_mode on.

  
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    

Click here for diff

  
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>  
  

Update comments to reflect code rearrangement.

  
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    

Click here for diff

  
Commit f9143d102ffd0947ca904c62b1d3d6fd587e0c80 falsified these.  
  
KaiGai Kohei  
  

Fix initdb misbehavior when user mis-enters superuser password.

  
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    

Click here for diff

  
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.  
  

Stamp 9.6rc1.

  
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    

Click here for diff

  
  

Translation updates

  
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    

Click here for diff

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

Doc: improve 9.6 description of SP-GiST traverse values.

  
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    

Click here for diff

  
Sync relevant parts of commit d2ddee63b back to 9.6 branch.  
  

Fix pg_receivexlog –synchronous

  
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    

Click here for diff

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

Fix pg_xlogdump so that it handles cross-page XLP_FIRST_IS_CONTRECORD record.

  
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    

Click here for diff

  
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  
  

Fix stray reference to the old genbki.sh script.

  
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    

Click here for diff

  
Per Tomas Vondra.  
  

Make another editorial pass over the 9.6 release notes.

  
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    

Click here for diff

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

Update 9.6 release notes through today.

  
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    

Click here for diff

  
  

Add macros to make AllocSetContextCreate() calls simpler and safer.

  
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    

Click here for diff

  
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>  
  

Add a nonlocalized version of the severity field to client error messages.

  
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    

Click here for diff

  
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>  
  

Fix potential memory leakage from HandleParallelMessages().

  
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    

Click here for diff

  
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>  
  

Put static forward declarations in elog.c back into same order as code.

  
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    

Click here for diff

  
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.  
  

Fix assorted small bugs in ThrowErrorData().

  
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    

Click here for diff

  
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.  
  

Fix logic for adding “parallel worker” context line to worker errors.

  
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    

Click here for diff

  
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>  
  

Fix instability in parallel regression tests.

  
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    

Click here for diff

  
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>  
  

Fix small query-lifespan memory leak in bulk updates.

  
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    

Click here for diff

  
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>  
  

doc: more replacement of with something better

  
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    

Click here for diff

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

Fix improper repetition of previous results from a hashed aggregate.

  
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    

Click here for diff

  
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>  
  

Remove unnecessary #include.

  
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    

Click here for diff

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

Build libpgfeutils before pg_isready.

  
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    

Click here for diff

  
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.  
  

Suppress compiler warnings in non-cassert builds.

  
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    

Click here for diff

  
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.  
  

doc: fix incorrect ‘literal’ tags

  
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    

Click here for diff

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

doc: fix typo in recent patch

  
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    

Click here for diff

  
Reported-by: Jeff Janes  
  
Backpatch-through: 9.6  
  

Fix possible sorting error when aborting use of abbreviated keys.

  
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    

Click here for diff

  
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.  
  

Guard against parallel-restricted functions in VALUES expressions.

  
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    

Click here for diff

  
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).  
  

reorderbuffer: preserve errno while reporting error

  
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    

Click here for diff

  
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.  
  

doc: requirepeer is a way to avoid spoofing

  
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    

Click here for diff

  
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  
  

Add alternative output for ON CONFLICT toast isolation test.

  
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    

Click here for diff

  
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  
  

Update line count totals for psql help displays.

  
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    

Click here for diff

  
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.  
  

In plpgsql, don’t try to convert int2vector or oidvector to expanded array.

  
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    

Click here for diff

  
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>  
  

Update Windows timezone mapping from Windows 7 and 10

  
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    

Click here for diff

  
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  
  

Fix deletion of speculatively inserted TOAST on conflict

  
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    

Click here for diff

  
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  
  

Properly re-initialize replication slot shared memory upon creation.

  
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    

Click here for diff

  
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  
  

Fix -e option in contrib/intarray/bench/bench.pl.

  
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    

Click here for diff

  
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>  
  

Disable update_process_title by default on Windows

  
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    

Click here for diff

  
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  
  

docs: my third pass over the 9.6 release notes

  
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    

Click here for diff

  
Backpatch-through: 9.6  
  

Suppress -Wunused-result warning for strtol().

  
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    

Click here for diff

  
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>  
  

Fix assorted places in psql to print version numbers >= 10 in new style.

  
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    

Click here for diff

  
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.  
  

doc: Remove some confusion from pg_archivecleanup doc

  
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    

Click here for diff

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

Fix typos

  
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    

Click here for diff

  
From: Alexander Law <exclusion@gmail.com>  
  

Fix possible crash due to incorrect allocation context.

  
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    

Click here for diff

  
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.  
  

Doc: copy-editing in create_access_method.sgml.

  
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    

Click here for diff

  
Improve shaky English grammar.  And markup.  
  

Doc: remove out-of-date claim that pg_am rows must be inserted by hand.

  
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    

Click here for diff

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

Disable parallel query by default.

  
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    

Click here for diff

  
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.  
  

Final pgindent + perltidy run for 9.6.

  
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    

Click here for diff

  
  

Simplify the process of perltidy’ing our Perl files.

  
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    

Click here for diff

  
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.  
  

Remove bogus dependencies on NUMERIC_MAX_PRECISION.

  
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    

Click here for diff

  
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>  
  

Fix assorted bugs in contrib/bloom.

  
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    

Click here for diff

  
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>  
  

Add SQL-accessible functions for inspecting index AM properties.

  
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    

Click here for diff

  
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>  
  

Doc: clarify that DROP … CASCADE is recursive.

  
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    

Click here for diff

  
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>  
  

Fix inappropriate printing of never-measured times in EXPLAIN.

  
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    

Click here for diff

  
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>  
  

Code cleanup in SyncRepWaitForLSN()

  
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    

Click here for diff

  
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.  
  

Correct TABLESAMPLE docs

  
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    

Click here for diff

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

Add ID property to replication slots’ sect2

  
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    

Click here for diff

  
  

Trivial cosmetic cleanup in bloom/blutils.c.

  
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    

Click here for diff

  
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).  
  

Fix busted Assert for CREATE MATVIEW … WITH NO DATA.

  
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    

Click here for diff

  
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>  
  

docs: my second pass over the 9.6 release notes

  
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    

Click here for diff

  
  

Doc: write some for adminpack.

  
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    

Click here for diff

  
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().  
  

Fix typo

  
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    

Click here for diff

  
  

docs: my first pass over the 9.6 release notes

  
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    

Click here for diff

  
  

Doc: clarify description of CREATE/ALTER FUNCTION … SET FROM CURRENT.

  
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    

Click here for diff

  
Per discussion with David Johnston.  
  

Stamp 9.6beta4.

  
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    

Click here for diff

  
  

doc: update list of pg_trgm authors

  
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    

Click here for diff

  
Author: Oleg Bartunov  
  

Update 9.6 release notes through today.

  
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    

Click here for diff

  
  

Last-minute updates for release notes.

  
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    

Click here for diff

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

Fix several one-byte buffer over-reads in to_number

  
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    

Click here for diff

  
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.  
  

Translation updates

  
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    

Click here for diff

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

Fix two errors with nested CASE/WHEN constructs.

  
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    

Click here for diff

  
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  
  

Obstruct shell, SQL, and conninfo injection via database and role names.

  
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    

Click here for diff

  
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  
  

Promote pg_dumpall shell/connstr quoting functions to src/fe_utils.

  
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    

Click here for diff

  
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  
  

Fix Windows shell argument quoting.

  
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    

Click here for diff

  
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  
  

Reject, in pg_dumpall, names containing CR or LF.

  
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    

Click here for diff

  
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  
  

Field conninfo strings throughout src/bin/scripts.

  
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    

Click here for diff

  
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  
  

Introduce a psql “\connect -reuse-previous=on|off” option.

  
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    

Click here for diff

  
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  
  

Sort out paired double quotes in \connect, \password and \crosstabview.

  
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    

Click here for diff

  
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  
  

doc: Update benchmark results

  
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    

Click here for diff

  
From: Alexander Law <exclusion@gmail.com>  
  

Make format() error messages consistent again

  
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    

Click here for diff

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

Update 9.6 release notes through today.

  
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    

Click here for diff

  
  

Correct column name in information schema

  
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    

Click here for diff

  
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>  
  

Release notes for 9.5.4, 9.4.9, 9.3.14, 9.2.18, 9.1.23.

  
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    

Click here for diff

  
  

doc: Move mention of rsync of temp tables to better place

  
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    

Click here for diff

  
  

Fix misestimation of n_distinct for a nearly-unique column with many nulls.

  
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    

Click here for diff

  
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>  
  

Fix crash when pg_get_viewdef_name_ext() is passed a non-view relation.

  
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    

Click here for diff

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

Fix TOAST access failure in RETURNING queries.

  
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    

Click here for diff

  
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>  
  

Avoid crashing in GetOldestSnapshot() if there are no known snapshots.

  
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    

Click here for diff

  
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>  
  

Don’t propagate a null subtransaction snapshot up to parent transaction.

  
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    

Click here for diff

  
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>  
  

First-draft release notes for 9.5.4.

  
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    

Click here for diff

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

In B-tree page deletion, clean up properly after page deletion failure.

  
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    

Click here for diff

  
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>  
  

Teach libpq to decode server version correctly from future servers.

  
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    

Click here for diff

  
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>  
  

Fix copy-and-pasteo in 81c766b3fd41c78c634d78ebae8d316808dfc630.

  
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    

Click here for diff

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

Make array_to_tsvector() sort and de-duplicate the given strings.

  
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    

Click here for diff

  
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>  
  

Fix ts_delete(tsvector, text[]) to cope with duplicate array entries.

  
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    

Click here for diff

  
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>  
  

Re-pgindent tsvector_op.c.

  
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    

Click here for diff

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

docs: re-add spaces before units removed

  
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    

Click here for diff

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

Update time zone data files to tzdata release 2016f.

  
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    

Click here for diff

  
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.  
  

Change InitToastSnapshot to a macro.

  
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    

Click here for diff

  
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.  
  

Fix hard to hit race condition in heapam’s tuple locking code.

  
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    

Click here for diff

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

docs: mention rsync of temp and unlogged tables

  
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    

Click here for diff

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

Fix bogus coding in WaitForBackgroundWorkerShutdown().

  
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    

Click here for diff

  
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>  
  

doc: Move indexterms to avoid whitespace issue in man pages

  
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    

Click here for diff

  
  

Prevent “snapshot too old” from trying to return pruned TOAST tuples.

  
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    

Click here for diff

  
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.  
  

Make INSERT-from-multiple-VALUES-rows handle targetlist indirection better.

  
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    

Click here for diff

  
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>  
  

Do not let PostmasterContext survive into background workers.

  
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    

Click here for diff

  
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>  
  

Add missing casts in information schema

  
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    

Click here for diff

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

doc: Remove documentation of nonexistent information schema columns

  
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    

Click here for diff

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

Fix assorted problems in recovery tests

  
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    

Click here for diff

  
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  
  

doc: Change recommendation to put NOTIFY into a rule

  
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    

Click here for diff

  
Suggest a statement trigger instead.  
  

Add OldSnapshotTimeMapLock to wait_event table in docs.

  
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    

Click here for diff

  
Ashutosh Sharma with minor fixes by me.  
  

C comment: fix typo

  
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    

Click here for diff

  
Author: Amit Langote  
  

doc: Remove slightly confusing xreflabels

  
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    

Click here for diff

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

Small wording tweaks

  
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    

Click here for diff

  
Dmitry Igrishin  
  

Remove duplicate InitPostmasterChild() call while starting a bgworker.

  
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    

Click here for diff

  
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>  
  

doc: OS collation changes can break indexes

  
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    

Click here for diff

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

Block interrupts during HandleParallelMessages().

  
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    

Click here for diff

  
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>  
  

Change minimum max_worker_processes from 1 to 0

  
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    

Click here for diff

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

Fix pg_dump’s handling of public schema with both -c and -C options.

  
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    

Click here for diff

  
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>  
  

doc: Whitespace fixes in man pages

  
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    

Click here for diff

  
  

Consistently capitalize names of recovery tests

  
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    

Click here for diff

  
  

Minor cleanup for access/transam/parallel.c.

  
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    

Click here for diff

  
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.  
  

Don’t CHECK_FOR_INTERRUPTS between WaitLatch and ResetLatch.

  
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    

Click here for diff

  
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>  
  

Remove unused arguments from pg_replication_origin_xact_reset function.

  
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    

Click here for diff

  
The document specifies that pg_replication_origin_xact_reset function  
doesn't have any argument variables. But previously it was actually  
defined so as to have two argument variables, though they were not  
used at all. That is, the pg_proc entry for that function was incorrect.  
This patch fixes the pg_proc entry and removes those two arguments  
from the function definition.  
  
No back-patch because this change needs a catalog version bump  
although the issue exists in 9.5 as well. Instead, a note about those  
unused argument variables will be added to 9.5 document later.  
  
Catalog version bumped due to the change of pg_proc.  
  

pg_rewind docs: clarify handling of remote servers

  
commit   : 878bd9accb553f6eee32af8acdb7ee3e54a74e23    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 1 Aug 2016 12:52:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 1 Aug 2016 12:52:22 -0400    

Click here for diff

  
  

Fixed array checking code for “unsigned long long” datatypes in libecpg.

  
commit   : 3ebc88e568053fa16766e05155eb005cc72978db    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Mon, 1 Aug 2016 06:36:27 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Mon, 1 Aug 2016 06:36:27 +0200    

Click here for diff

  
  

Fix pg_basebackup so that it accepts 0 as a valid compression level.

  
commit   : 74d8c95b7456faefdd4244acf854361711fb42ce    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 1 Aug 2016 17:36:14 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 1 Aug 2016 17:36:14 +0900    

Click here for diff

  
The help message for pg_basebackup specifies that the numbers 0 through 9  
are accepted as valid values of -Z option. But, previously -Z 0 was rejected  
as an invalid compression level.  
  
Per discussion, it's better to make pg_basebackup treat 0 as valid  
compression level meaning no compression, like pg_dump.  
  
Back-patch to all supported versions.  
  
Reported-By: Jeff Janes  
Reviewed-By: Amit Kapila  
Discussion: CAMkU=1x+GwjSayc57v6w87ij6iRGFWt=hVfM0B64b1_bPVKRqg@mail.gmail.com  
  

Doc: remove claim that hash index creation depends on effective_cache_size.

  
commit   : 11653cd87f66fc55ab79683a3ba7e6fe1a299596    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 31 Jul 2016 18:32:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 31 Jul 2016 18:32:34 -0400    

Click here for diff

  
This text was added by commit ff213239c, and not long thereafter obsoleted  
by commit 4adc2f72a (which made the test depend on NBuffers instead); but  
nobody noticed the need for an update.  Commit 9563d5b5e adds some further  
dependency on maintenance_work_mem, but the existing verbiage seems to  
cover that with about as much precision as we really want here.  Let's  
just take it all out rather than leaving ourselves open to more errors of  
omission in future.  (That solution makes this change back-patchable, too.)  
  
Noted by Peter Geoghegan.  
  
Discussion: <CAM3SWZRVANbj9GA9j40fAwheQCZQtSwqTN1GBTVwRrRbmSf7cg@mail.gmail.com>  
  

Code review for tqueue.c: fix memory leaks, speed it up, other fixes.

  
commit   : a9ed875fdc2c44b5793a07727274786b417fc924    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 31 Jul 2016 16:05:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 31 Jul 2016 16:05:12 -0400    

Click here for diff

  
When doing record typmod remapping, tqueue.c did fresh catalog lookups  
for each tuple it processed, which was pretty horrible performance-wise  
(it seemed to about halve the already none-too-quick speed of bulk reads  
in parallel mode).  Worse, it insisted on putting bits of that data into  
TopMemoryContext, from where it never freed them, causing a  
session-lifespan memory leak.  (I suppose this was coded with the idea  
that the sender process would quit after finishing the query ---  
but the receiver uses the same code.)  
  
Restructure to avoid repetitive catalog lookups and to keep that data  
in a query-lifespan context, in or below the context where the  
TQueueDestReceiver or TupleQueueReader itself lives.  
  
Fix some other bugs such as continuing to use a tupledesc after  
releasing our refcount on it.  Clean up cavalier datatype choices  
(typmods are int32, please, not int, and certainly not Oid).  Improve  
comments and error message wording.  
  

Correctly handle owned sequences with extensions

  
commit   : f9e439b1ca81e3305b677d93c67299549625370c    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sun, 31 Jul 2016 10:57:15 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sun, 31 Jul 2016 10:57:15 -0400    

Click here for diff

  
With the refactoring of pg_dump to handle components, getOwnedSeqs needs  
to be a bit more intelligent regarding which components to dump when.  
Specifically, we can't simply use the owning table's components as the  
set of components to dump as the table might only be including certain  
components while all components of the sequence should be dumped, for  
example, when the table is a member of an extension while the sequence  
is not.  
  
Handle this by combining the set of components to be dumped for the  
sequence explicitly and those to be dumped for the table when setting  
the components to be dumped for the sequence.  
  
Also add a number of regression tests around this to, hopefully, catch  
any future changes which break the expected behavior.  
  
Discovered by: Philippe BEAUDOIN  
Reviewed by: Michael Paquier  
  

doc: improve wording of Error Message Style Guide

  
commit   : 6335c80ef417b58f657fe9bc21f99edd79511f30    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Jul 2016 21:34:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Jul 2016 21:34:28 -0400    

Click here for diff

  
Reported-by: Daniel Gustafsson  
  
Discussion: 48DB4EDA-96F8-4B2F-99C4-110900FC7540@yesql.se  
  
Author: Daniel Gustafsson  
  

pgbench docs: fix incorrect “last two” fields text

  
commit   : 9e765bb10fcb1438806bc139e243871234990423    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Jul 2016 16:59:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Jul 2016 16:59:34 -0400    

Click here for diff

  
Reported-by: Alexander Law  
  
Discussion: 5786638C.8080508@gmail.com  
  
Backpatch-through: 9.4  
  

docs: properly capitalize and space kB, MB, GB, TB

  
commit   : ca0c37b56f4a80ad758774e34c86cc4335583d29    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Jul 2016 12:27:27 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Jul 2016 12:27:27 -0400    

Click here for diff

  
  

Fix worst memory leaks in tqueue.c.

  
commit   : af33039317ddc4a0e38a02e2255c2bf453115fd2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Jul 2016 19:31:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Jul 2016 19:31:06 -0400    

Click here for diff

  
TupleQueueReaderNext() leaks like a sieve if it has to do any tuple  
disassembly/reconstruction.  While we could try to clean up its allocations  
piecemeal, it seems like a better idea just to insist that it should be run  
in a short-lived memory context, so that any transient space goes away  
automatically.  I chose to have nodeGather.c switch into its existing  
per-tuple context before the call, rather than inventing a separate  
context inside tqueue.c.  
  
This is sufficient to stop all leakage in the simple case I exhibited  
earlier today (see link below), but it does not deal with leaks induced  
in more complex cases by tqueue.c's insistence on using TopMemoryContext  
for data that it's not actually trying hard to keep track of.  That issue  
is intertwined with another major source of inefficiency, namely failure  
to cache lookup results across calls, so it seems best to deal with it  
separately.  
  
In passing, improve some comments, and modify gather_readnext's method for  
deciding when it's visited all the readers so that it's more obviously  
correct.  (I'm not actually convinced that the previous code *is*  
correct in the case of a reader deletion; it certainly seems fragile.)  
  
Discussion: <32763.1469821037@sss.pgh.pa.us>  
  

Fix tqueue.c’s range-remapping code.

  
commit   : bf4ae685ae6f37b7fe83336abacf44298431b2f0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Jul 2016 14:13:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Jul 2016 14:13:19 -0400    

Click here for diff

  
It's depressingly clear that nobody ever tested this.  
  

Fix pq_putmessage_noblock() to not block.

  
commit   : 80b346c2084928c11b6f9e495a7e9d559d96703d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Jul 2016 12:52:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Jul 2016 12:52:57 -0400    

Click here for diff

  
An evident copy-and-pasteo in commit 2bd9e412f broke the non-blocking  
aspect of pq_putmessage_noblock(), causing it to behave identically to  
pq_putmessage().  That function is nowadays used only in walsender.c,  
so that the net effect was to cause walsenders to hang up waiting for  
the receiver in situations where they should not.  
  
Kyotaro Horiguchi  
  
Patch: <20160728.185228.58375982.horiguchi.kyotaro@lab.ntt.co.jp>  
  

Eliminate a few more user-visible “cache lookup failed” errors.

  
commit   : 3153b1a52f8f2d1efe67306257aec15aaaf9e94c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 29 Jul 2016 12:06:18 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 29 Jul 2016 12:06:18 -0400    

Click here for diff

  
Michael Paquier  
  

Documentation spell checking and markup improvements

  
commit   : 5676da2d01bb6ba437cf05d748f04b3d31676922    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 28 Jul 2016 22:46:15 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 28 Jul 2016 22:46:15 -0400    

Click here for diff

  
  

Guard against empty buffer in gets_fromFile()’s check for a newline.

  
commit   : ed0b228d7a6b5186adc099f6a31dc33c499ff077    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 18:57:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 18:57:24 -0400    

Click here for diff

  
Per the fgets() specification, it cannot return without reading some data  
unless it reports EOF or error.  So the code here assumed that the data  
buffer would necessarily be nonempty when we go to check for a newline  
having been read.  However, Agostino Sarubbo noticed that this could fail  
to be true if the first byte of the data is a NUL (\0).  The fgets() API  
doesn't really work for embedded NULs, which is something I don't feel  
any great need for us to worry about since we generally don't allow NULs  
in SQL strings anyway.  But we should not access off the end of our own  
buffer if the case occurs.  Normally this would just be a harmless read,  
but if you were unlucky the byte before the buffer would contain '\n'  
and we'd overwrite it with '\0', and if you were really unlucky that  
might be valuable data and psql would crash.  
  
Agostino reported this to pgsql-security, but after discussion we concluded  
that it isn't worth treating as a security bug; if you can control the  
input to psql you can do far more interesting things than just maybe-crash  
it.  Nonetheless, it is a bug, so back-patch to all supported versions.  
  

Teach parser to transform “x IS [NOT] DISTINCT FROM NULL” to a NullTest.

  
commit   : 8d19d0e139238cdcb3f1f7e1adc4ff959562822f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 17:23:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 17:23:03 -0400    

Click here for diff

  
Now that we've nailed down the principle that NullTest with !argisrow  
is fully equivalent to SQL's IS [NOT] DISTINCT FROM NULL, let's teach  
the parser about it.  This produces a slightly more compact parse tree  
and is much more amenable to optimization than a DistinctExpr, since  
the planner knows a good deal about NullTest and next to nothing about  
DistinctExpr.  
  
I'm not sure that there are all that many queries in the wild that could  
be improved by this, but at least one source of such cases is the patch  
just made to postgres_fdw to emit IS [NOT] DISTINCT FROM NULL when  
IS [NOT] NULL isn't semantically correct.  
  
No back-patch, since to the extent that this does affect planning results,  
it might be considered undesirable plan destabilization.  
  

Message style improvements

  
commit   : ef5d4a3cfacb009526aac3e01a26f4b54d70bfd7    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 28 Jul 2016 16:18:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 28 Jul 2016 16:18:35 -0400    

Click here for diff

  
  

Fix assorted fallout from IS [NOT] NULL patch.

  
commit   : 9492cf86e40288395a2ec6d81f7f5417e0e1b4fa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 16:09:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 16:09:15 -0400    

Click here for diff

  
Commits 4452000f3 et al established semantics for NullTest.argisrow that  
are a bit different from its initial conception: rather than being merely  
a cache of whether we've determined the input to have composite type,  
the flag now has the further meaning that we should apply field-by-field  
testing as per the standard's definition of IS [NOT] NULL.  If argisrow  
is false and yet the input has composite type, the construct instead has  
the semantics of IS [NOT] DISTINCT FROM NULL.  Update the comments in  
primnodes.h to clarify this, and fix ruleutils.c and deparse.c to print  
such cases correctly.  In the case of ruleutils.c, this merely results in  
cosmetic changes in EXPLAIN output, since the case can't currently arise  
in stored rules.  However, it represents a live bug for deparse.c, which  
would formerly have sent a remote query that had semantics different  
from the local behavior.  (From the user's standpoint, this means that  
testing a remote nested-composite column for null-ness could have had  
unexpected recursive behavior much like that fixed in 4452000f3.)  
  
In a related but somewhat independent fix, make plancat.c set argisrow  
to false in all NullTest expressions constructed to represent "attnotnull"  
constructs.  Since attnotnull is actually enforced as a simple null-value  
check, this is a more accurate representation of the semantics; we were  
previously overpromising what it meant for composite columns, which might  
possibly lead to incorrect planner optimizations.  (It seems that what the  
SQL spec expects a NOT NULL constraint to mean is an IS NOT NULL test, so  
arguably we are violating the spec and should fix attnotnull to do the  
other thing.  If we ever do, this part should get reverted.)  
  
Back-patch, same as the previous commit.  
  
Discussion: <10682.1469566308@sss.pgh.pa.us>  
  

Improve documentation about CREATE TABLE … LIKE.

  
commit   : 46b773d4fe0f0c880a1073cb5366efa02efa8ef8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 13:26:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 13:26:58 -0400    

Click here for diff

  
The docs failed to explain that LIKE INCLUDING INDEXES would not preserve  
the names of indexes and associated constraints.  Also, it wasn't mentioned  
that EXCLUDE constraints would be copied by this option.  The latter  
oversight seems enough of a documentation bug to justify back-patching.  
  
In passing, do some minor copy-editing in the same area, and add an entry  
for LIKE under "Compatibility", since it's not exactly a faithful  
implementation of the standard's feature.  
  
Discussion: <20160728151154.AABE64016B@smtp.hushmail.com>  
  

Register atexit hook only once in pg_upgrade.

  
commit   : d9e74959a7fabe57e38bdda430aa662445bd1dd6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 11:39:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 11:39:10 -0400    

Click here for diff

  
start_postmaster() registered stop_postmaster_atexit as an atexit(3)  
callback each time through, although the obvious intention was to do  
so only once per program run.  The extra registrations were harmless,  
so long as we didn't exceed ATEXIT_MAX, but still it's a bug.  
  
Artur Zakirov, with bikeshedding by Kyotaro Horiguchi and me  
  
Discussion: <d279e817-02b5-caa6-215f-cfb05dce109a@postgrespro.ru>  
  

Fix incorrect description of udt_privileges view in documentation.

  
commit   : de8c92e6caf0cd8683b23a222d4bd88a90496840    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 28 Jul 2016 22:34:42 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 28 Jul 2016 22:34:42 +0900    

Click here for diff

  
The description of udt_privileges view contained an incorrect copy-pasted word.  
  
Back-patch to 9.2 where udt_privileges view was added.  
  
Author: Alexander Law  
  

tqueue.c’s record-typmod hashtables need the HASH_BLOBS option.

  
commit   : e1a93dd6ae114669669e3a77167dc3d3bd91e035    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 02:08:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2016 02:08:52 -0400    

Click here for diff

  
The keys are integers, not strings.  The code accidentally worked on  
little-endian machines, at least up to 256 distinct record types within  
a session, but failed utterly on big-endian.  This was unexpectedly  
exposed by a test case added by commit 4452000f3, which apparently is the  
only parallelizable query in the regression suite that uses more than one  
anonymous record type.  Fortunately, buildfarm member mandrill is  
big-endian and is running with force_parallel_mode on, so it failed.  
  

Fix cost_rescan() to account for multi-batch hashing correctly.

  
commit   : 69995c3b3fd64361bb4d3938315f3e88ccc01e53    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Jul 2016 17:44:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Jul 2016 17:44:34 -0400    

Click here for diff

  
cost_rescan assumed that we don't need to rebuild the hash table when  
rescanning a hash join.  However, that's currently only true for  
single-batch joins; for a multi-batch join we must charge full freight.  
  
This probably has escaped notice because we'd be unlikely to put a hash  
join on the inside of a nestloop anyway.  Nonetheless, it's wrong.  
Fix in HEAD, but don't backpatch for fear of destabilizing plans in  
stable releases.  
  

Fix thinko in copyParamList.

  
commit   : b31875b1fe7131ac29f118efd81c9aba7255eced    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Jul 2016 10:16:26 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Jul 2016 10:16:26 -0400    

Click here for diff

  
There's no point in consulting retval->paramMask; it's always NULL.  
Instead, we should consult from->paramMask.  
  
Reported by Andrew Gierth.  
  

Allow functions that return sets of tuples to return simple NULLs.

  
commit   : d8411a6c8b6e5f74b362ef2496723f7f88593737    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Jul 2016 21:33:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Jul 2016 21:33:49 -0400    

Click here for diff

  
ExecMakeTableFunctionResult(), which is used in SELECT FROM function(...)  
cases, formerly treated a simple NULL output from a function that both  
returnsSet and returnsTuple as a violation of the SRF protocol.  What seems  
better is to treat a NULL output as equivalent to ROW(NULL,NULL,...).  
Without this, cases such as SELECT FROM unnest(...) on an array of  
composite are vulnerable to unexpected and not-very-helpful failures.  
Old code comments here suggested an alternative of just ignoring  
simple-NULL outputs, but that doesn't seem very principled.  
  
This change had been hung up for a long time due to uncertainty about  
how much we wanted to buy into the equivalence of simple NULL and  
ROW(NULL,NULL,...).  I think that's been mostly resolved by the discussion  
around bug #14235, so let's go ahead and do it.  
  
Per bug #7808 from Joe Van Dyk.  Although this is a pretty old report,  
fixing it smells a bit more like a new feature than a bug fix, and the  
lack of other similar complaints suggests that we shouldn't take much risk  
of destabilization by back-patching.  (Maybe that could be revisited once  
this patch has withstood some field usage.)  
  
Andrew Gierth and Tom Lane  
  
Report: <E1TurJE-0006Es-TK@wrigleys.postgresql.org>  
  

Change various deparsing functions to return NULL for invalid input.

  
commit   : 976b24fb477464907737d28cdf18e202fa3b1a5b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 26 Jul 2016 16:07:02 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 26 Jul 2016 16:07:02 -0400    

Click here for diff

  
Previously, some functions returned various fixed strings and others  
failed with a cache lookup error.  Per discussion, standardize on  
returning NULL.  Although user-exposed "cache lookup failed" error  
messages might normally qualify for bug-fix treatment, no back-patch;  
the risk of breaking user code which is accustomed to the current  
behavior seems too high.  
  
Michael Paquier  
  

Repair damage done by citext–1.1–1.2.sql.

  
commit   : fe5e3fce798dccf3f298b65c5d9a132e9646712a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 26 Jul 2016 15:32:57 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 26 Jul 2016 15:32:57 -0400    

Click here for diff

  
That script is incorrect in that it sets the combine function for  
max(citext) twice instead of setting the combine function for  
max(citext) once and the combine functon for min(citext) once.  The  
consequence is that if you install 1.0 or 1.1 and then update to 1.2,  
you end up with min(citext) not having a combine function, contrary to  
what was intended.  If you install 1.2 directly, you're OK.  
  
Fix things up by defining a new 1.3 version.  Upgrading from 1.2 to  
1.3 won't change anything for people who first installed the 1.2  
version, but people upgrading from 1.0 or 1.1 will get the right  
catalog contents once they reach 1.3.  
  
Report and patch by David Rowley, reviewed by Andreas Karlsson.  
  

Fix constant-folding of ROW(…) IS [NOT] NULL with composite fields.

  
commit   : 4452000f310b8c1c947ee724618c1bc31ed20242    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Jul 2016 15:25:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Jul 2016 15:25:02 -0400    

Click here for diff

  
The SQL standard appears to specify that IS [NOT] NULL's tests of field  
nullness are non-recursive, ie, we shouldn't consider that a composite  
field with value ROW(NULL,NULL) is null for this purpose.  
ExecEvalNullTest got this right, but eval_const_expressions did not,  
leading to weird inconsistencies depending on whether the expression  
was such that the planner could apply constant folding.  
  
Also, adjust the docs to mention that IS [NOT] DISTINCT FROM NULL can be  
used as a substitute test if a simple null check is wanted for a rowtype  
argument.  That motivated reordering things so that IS [NOT] DISTINCT FROM  
is described before IS [NOT] NULL.  In HEAD, I went a bit further and added  
a table showing all the comparison-related predicates.  
  
Per bug #14235.  Back-patch to all supported branches, since it's certainly  
undesirable that constant-folding should change the semantics.  
  
Report and patch by Andrew Gierth; assorted wordsmithing and revised  
regression test cases by me.  
  
Report: <20160708024746.1410.57282@wrigleys.postgresql.org>  
  

Fix improper example of using psql() function in TAP tests documentation.

  
commit   : c1a95425780ef8e72c2f65504a7e90bcb223ca4a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 26 Jul 2016 21:17:38 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 26 Jul 2016 21:17:38 +0900    

Click here for diff

  
In an example of TAP test scripts, there is the test checking whether  
the result of the query is expected or not. But, in previous example,  
the exit code of psql instead of the query result was checked unexpectedly.  
  
Author: Ildar Musin  
  

Fix typo

  
commit   : 43c2c404978a89e9e5ea51aca5759a35f3f302f9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 25 Jul 2016 22:07:53 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 25 Jul 2016 22:07:53 -0400    

Click here for diff

  
  

Message style improvements

  
commit   : 40fcfec82cf695d520f2dd91ee437fa75dea4ca7    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 25 Jul 2016 22:07:44 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 25 Jul 2016 22:07:44 -0400    

Click here for diff

  
  

Fix typo in comment.

  
commit   : 1804d1555f56fcad4ce62e160bab17bdff6c94aa    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 25 Jul 2016 17:51:26 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 25 Jul 2016 17:51:26 +0900    

Click here for diff

  
Author: Masahiko Sawada  
  

Give recovery tests more time to finish

  
commit   : 2a0f89cd717ce6d49cdc47850577823682167e87    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Jul 2016 01:34:35 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Jul 2016 01:34:35 -0400    

Click here for diff

  
These tests are currently only running in buildfarm member hamster,  
which is purposefully very slow.  This suite has failed a couple of  
times recently because of timeouts, so increase the allowed number of  
iterations to avoid spurious failures.  
  
Author: Michaël Paquier  
  

Make the AIX case of Makefile.shlib safe for parallel make.

  
commit   : e8564ef034333c6ba6fd3d0c6ecf18214a4e988b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 23 Jul 2016 20:30:03 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 23 Jul 2016 20:30:03 -0400    

Click here for diff

  
Use our typical approach, from src/backend/parser.  Back-patch to 9.1  
(all supported versions).  
  

Correctly set up aggregate FILTER expression in partial-aggregation plans.

  
commit   : 6d85bb1ba79c2792214df9fa17bcc8fac229c11c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Jul 2016 20:16:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Jul 2016 20:16:48 -0400    

Click here for diff

  
The aggfilter expression should be removed from the parent (combining)  
Aggref, since it's not supposed to apply the filter, and indeed cannot  
because any Vars used in the filter would not be available after the  
lower-level aggregation step.  Per report from Jeff Janes.  
  
(This has been broken since the introduction of partial aggregation,  
I think.  The error became obvious after commit 59a3795c2, when setrefs.c  
began processing the parent Aggref's fields normally and thus would detect  
such Vars.  The special-case coding previously used in setrefs.c skipped  
over the parent's aggfilter field without processing it.  That was broken  
in its own way because no other setrefs.c processing got applied either;  
though since the executor would not execute the filter expression, only  
initialize it, that oversight might not have had any visible symptoms at  
present.)  
  
Report: <CAMkU=1xfuPf2edAe4ZGXTmJpU7jxuKukKyvNtEXwu35B7dvejg@mail.gmail.com>  
  

Fix regression tests to work in Welsh locale.

  
commit   : 9d7abca901f855d96d823b6edb893b2b4ccf8c2f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Jul 2016 15:41:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Jul 2016 15:41:39 -0400    

Click here for diff

  
Welsh (cy_GB) apparently sorts 'dd' after 'f', creating problems  
analogous to the odd sorting of 'aa' in Danish.  Adjust regression  
test case to not use data that provokes that.  
  
Jeff Janes  
  
Patch: <CAMkU=1zx-pqcfSApL2pYDQurPOCfcYU0wJorsmY1OrYPiXRbLw@mail.gmail.com>  
  

Remove GetUserMappingId() and GetUserMappingById().

  
commit   : 13bf801a255aaa18c43f0d17e24ffdb03a77ca31    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Jul 2016 11:32:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Jul 2016 11:32:23 -0400    

Click here for diff

  
These functions were added in commits fbe5a3fb7 and a104a017f,  
but commit 45639a052 removed their only callers.  Put the related  
code in foreign.c back to the way it was in 9.5, to avoid pointless  
cross-version diffs.  
  
Etsuro Fujita  
  
Patch: <d674a3f1-6b63-519c-ef3f-f3188ed6a178@lab.ntt.co.jp>  
  

Make contrib regression tests safe for Danish locale.

  
commit   : d70d119151d8e3442500be5e372439ef8805ec2b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jul 2016 16:52:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jul 2016 16:52:35 -0400    

Click here for diff

  
In btree_gin and citext, avoid some not-particularly-interesting  
dependencies on the sorting of 'aa'.  In tsearch2, use COLLATE "C" to  
remove an uninteresting dependency on locale sort order (and thereby  
allow removal of a variant expected-file).  
  
Also, in citext, avoid assuming that lower('I') = 'i'.  This isn't relevant  
to Danish but it does fail in Turkish.  
  

Make pltcl regression tests safe for Danish locale.

  
commit   : 95810ed8ee4223cfbad257f2d5f5f7d7da60c971    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jul 2016 14:24:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jul 2016 14:24:07 -0400    

Click here for diff

  
Another peculiarity of Danish locale is that it has an unusual idea  
of how to sort upper vs. lower case.  One of the pltcl test cases has  
an issue with that.  Now that COLLATE works in all supported branches,  
we can just change the test to be locale-independent, and get rid of  
the variant expected file that used to support non-C locales.  
  

Make core regression tests safe for Danish locale.

  
commit   : b3399cb0f68855886aa1a13a246fa5fc46e304e8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jul 2016 13:11:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jul 2016 13:11:00 -0400    

Click here for diff

  
Some tests added in 9.5 depended on 'aa' sorting before 'bb', which  
doesn't hold true in Danish.  Use slightly different test data to  
avoid the problem.  
  
Jeff Janes  
  
Report: <CAMkU=1w-cEDbA+XHdNb=YS_4wvZbs66Ni9KeSJKAJGNJyOsgQw@mail.gmail.com>  
  

Remove unused structure member.

  
commit   : 1091402b5aa4873cf8321e204f929731765c82bc    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 21 Jul 2016 11:53:44 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 21 Jul 2016 11:53:44 -0400    

Click here for diff

  
Michael Paquier  
  

Fix typos

  
commit   : 094ea692ee46c2af8c4d249b8fae6e4289102828    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jul 2016 10:39:18 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Jul 2016 10:39:18 +0200    

Click here for diff

  
Alexander Law  
  

Remove very-obsolete estimates of shmem usage from postgresql.conf.sample.

  
commit   : 79a84743096d661c6d085f40065c4b13b63acf6c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Jul 2016 18:41:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Jul 2016 18:41:30 -0400    

Click here for diff

  
runtime.sgml used to contain a table of estimated shared memory consumption  
rates for max_connections and some other GUCs.  Commit 390bfc643 removed  
that on the well-founded grounds that (a) we weren't maintaining the  
entries well and (b) it no longer mattered so much once we got out from  
under SysV shmem limits.  But it missed that there were even-more-obsolete  
versions of some of those numbers in comments in postgresql.conf.sample.  
Remove those too.  Back-patch to 9.3 where the aforesaid commit went in.  
  

Add comment & docs about no vacuum truncation with sto.

  
commit   : 1c15aac53f3421fd38ae145118d3204f055ba955    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 19 Jul 2016 16:25:53 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 19 Jul 2016 16:25:53 -0500    

Click here for diff

  
Omission noted by Andres Freund.  
  

Stamp 9.6beta3.

  
commit   : b11e9bbc41d1906360f1fbaab133118e703de75a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jul 2016 16:54:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jul 2016 16:54:26 -0400    

Click here for diff

  
  

Doc: improve discussion of plpgsql’s GET DIAGNOSTICS, other minor fixes.

  
commit   : ade64d05a0c9c77def776f64ea399697c3cd7f61    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jul 2016 16:52:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jul 2016 16:52:06 -0400    

Click here for diff

  
9.4 added a second description of GET DIAGNOSTICS that was totally  
independent of the existing one, resulting in each description lying to the  
extent that it claimed the set of status items it described was complete.  
Fix that, and do some minor markup improvement.  
  
Also some other small fixes per bug #14258 from Dilian Palauzov.  
  
Discussion: <20160718181437.1414.40802@wrigleys.postgresql.org>  
  

Doc: fix table of BRIN operator strategy numbers.

  
commit   : 82bbfc75c1bc3338b7208f1a7664878de0d3c59b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jul 2016 13:32:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Jul 2016 13:32:45 -0400    

Click here for diff

  
brin-extensibility-inclusion-table was confused in places about the  
difference between strategy 4 (RTOverRight) and strategy 5 (RTRight).  
  
Alexander Law  
  

Fix typos in comments and debug message

  
commit   : 55d57359f2ebebabd0387b437c9e3ef80312582f    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 18 Jul 2016 18:46:57 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 18 Jul 2016 18:46:57 +0200    

Click here for diff

  
Antonin Houska  
  

Translation updates

  
commit   : 7d676065690d5101d95a6b34797ee2a93514a7c3    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Jul 2016 12:07:49 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Jul 2016 12:07:49 -0400    

Click here for diff

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

Clear all-frozen visibilitymap status when locking tuples.

  
commit   : eca0f1db14ac92d91d54eca8eeff2d15ccd797fa    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 18 Jul 2016 02:01:13 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 18 Jul 2016 02:01:13 -0700    

Click here for diff

  
Since a892234 & fd31cd265 the visibilitymap's freeze bit is used to  
avoid vacuuming the whole relation in anti-wraparound vacuums. Doing so  
correctly relies on not adding xids to the heap without also unsetting  
the visibilitymap flag.  Tuple locking related code has not done so.  
  
To allow selectively resetting all-frozen - to avoid pessimizing  
heap_lock_tuple - allow to selectively reset the all-frozen with  
visibilitymap_clear(). To avoid having to use  
visibilitymap_get_status (e.g. via VM_ALL_FROZEN) inside a critical  
section, have visibilitymap_clear() return whether any bits have been  
reset.  
  
There's a remaining issue (denoted by XXX): After the PageIsAllVisible()  
check in heap_lock_tuple() and heap_lock_updated_tuple_rec() the page  
status could theoretically change. Practically that currently seems  
impossible, because updaters will hold a page level pin already.  Due to  
the next beta coming up, it seems better to get the required WAL magic  
bump done before resolving this issue.  
  
The added flags field fields to xl_heap_lock and xl_heap_lock_updated  
require bumping the WAL magic. Since there's already been a catversion  
bump since the last beta, that's not an issue.  
  
Reviewed-By: Robert Haas, Amit Kapila and Andres Freund  
Author: Masahiko Sawada, heavily revised by Andres Freund  
Discussion: CAEepm=3fWAbWryVW9swHyLTY4sXVf0xbLvXqOwUoDiNCx9mBjQ@mail.gmail.com  
Backpatch: -  
  

Remove obsolete comment.

  
commit   : 65632082b7eb3c7d56f1b42e1df452d0f66bc189    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Jul 2016 19:18:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Jul 2016 19:18:19 -0400    

Click here for diff

  
Peter Geoghegan  
  

Establish conventions about global object names used in regression tests.

  
commit   : 18555b1323bd225c7882e80723c52f25ce60afed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Jul 2016 18:42:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Jul 2016 18:42:31 -0400    

Click here for diff

  
To ensure that "make installcheck" can be used safely against an existing  
installation, we need to be careful about what global object names  
(database, role, and tablespace names) we use; otherwise we might  
accidentally clobber important objects.  There's been a weak consensus that  
test databases should have names including "regression", and that test role  
names should start with "regress_", but we didn't have any particular rule  
about tablespace names; and neither of the other rules was followed with  
any consistency either.  
  
This commit moves us a long way towards having a hard-and-fast rule that  
regression test databases must have names including "regression", and that  
test role and tablespace names must start with "regress_".  It's not  
completely there because I did not touch some test cases in rolenames.sql  
that test creation of special role names like "session_user".  That will  
require some rethinking of exactly what we want to test, whereas the intent  
of this patch is just to hit all the cases in which the needed renamings  
are cosmetic.  
  
There is no enforcement mechanism in this patch either, but if we don't  
add one we can expect that the tests will soon be violating the convention  
again.  Again, that's not such a cosmetic change and it will require  
discussion.  (But I did use a quick-hack enforcement patch to find these  
cases.)  
  
Discussion: <16638.1468620817@sss.pgh.pa.us>  
  

doc: Supply XSLT template for superscript element in man pages

  
commit   : 7482fc4600ee97f8b2570e87b8c216a83b918065    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 17 Jul 2016 17:01:07 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 17 Jul 2016 17:01:07 -0400    

Click here for diff

  
The default is no decoration, which looks confusing, for example on the  
CREATE SEQUENCE man page.  
  

Use correct symbol for minimum int64 value

  
commit   : f36ca9af05dd0468cdee28fbdbded690a10ff08b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 17 Jul 2016 09:15:37 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 17 Jul 2016 09:15:37 -0400    

Click here for diff

  
The old code used SEQ_MINVALUE to get the smallest int64 value.  This  
was done as a convenience to avoid having to deal with INT64_IS_BUSTED,  
but that is obsolete now.  Also, it is incorrect because the smallest  
int64 value is actually SEQ_MINVALUE-1.  Fix by using PG_INT64_MIN.  
  

Correctly dump database and tablespace ACLs

  
commit   : 47f5bb9f539a7fff089724b1cbacc31613031895    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sun, 17 Jul 2016 09:04:46 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sun, 17 Jul 2016 09:04:46 -0400    

Click here for diff

  
Dump out the appropriate GRANT/REVOKE commands for databases and  
tablespaces from pg_dumpall to replicate what the current state is.  
  
This was broken during the changes to buildACLCommands for 9.6+  
servers for pg_init_privs.  
  

Update 9.6 release notes through today.

  
commit   : fe03f2896292e6b21828490c76bda64cf75e7867    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2016 18:39:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2016 18:39:47 -0400    

Click here for diff

  
  

Improve test case exercising the sorting path for hash index build.

  
commit   : 606ccc5e7e97914073f991b077712645e125d531    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2016 16:25:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2016 16:25:43 -0400    

Click here for diff

  
On second thought, we should probably do at least a minimal check that  
the constructed index is valid, since the big problem with the most  
recent breakage was not whether the sorting was correct but that the  
index had incorrect hash codes placed in it.  
  

Add regression test case exercising the sorting path for hash index build.

  
commit   : 9563d5b5e4c75e676d73a45546bd47b77c2bd739    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2016 15:30:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2016 15:30:15 -0400    

Click here for diff

  
We've broken this code path at least twice in the past, so it's prudent  
to have a test case that covers it.  To allow exercising the code path  
without creating a very large (and slow to run) test case, redefine the  
sort threshold to be bounded by maintenance_work_mem as well as the number  
of available buffers.  While at it, fix an ancient oversight that when  
building a temp index, the number of available buffers is not NBuffers but  
NLocBuffer.  Also, if assertions are enabled, apply a direct test that the  
sort actually does return the tuples in the expected order.  
  
Peter Geoghegan  
  
Patch: <CAM3SWZTBAo4hjbBd780+MrOKiKp_TMo1N3A0Rw9_im8gbD7fQA@mail.gmail.com>  
  

Fix crash in close_ps() for NaN input coordinates.

  
commit   : 278148907a971ec7fa4ffb24248103d8012155d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2016 14:42:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2016 14:42:37 -0400    

Click here for diff

  
The Assert() here seems unreasonably optimistic.  Andreas Seltenreich  
found that it could fail with NaNs in the input geometries, and it  
seems likely to me that it might fail in corner cases due to roundoff  
error, even for ordinary input values.  As a band-aid, make the function  
return SQL NULL instead of crashing.  
  
Report: <87d1md1xji.fsf@credativ.de>  
  

Clarify usage of clientcert authentication option.

  
commit   : 745513c70282180afd83c666e43bdb0b6fb8c688    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2016 14:12:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2016 14:12:44 -0400    

Click here for diff

  
For some reason this option wasn't discussed at all in client-auth.sgml.  
Document it there, and be more explicit about its relationship to the  
"cert" authentication method.  Per gripe from Srikanth Venkatesh.  
  
I failed to resist the temptation to do some minor wordsmithing in the  
same area, too.  
  
Discussion: <20160713110357.1410.30407@wrigleys.postgresql.org>  
  

Advance PG_CONTROL_VERSION.

  
commit   : 99dd8b05aa5647a59f30ca67e67e2e3377f50094    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2016 12:49:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2016 12:49:14 -0400    

Click here for diff

  
This should have been done in commit 73c986adde5d73a5 which added several  
new fields to pg_control, and again in commit 5028f22f6eb05798 which  
changed the CRC algorithm, but it wasn't.  It's far too late to fix it in  
the 9.5 branch, but let's do so in 9.6, so that if a 9.6 postmaster is  
started against a 9.4-era pg_control it will complain about a versioning  
problem rather than a CRC failure.  We already forced initdb/pg_upgrade  
for beta3, so there's no downside to doing this now.  
  
Discussion: <7615.1468598094@sss.pgh.pa.us>  
  

Fix torn-page, unlogged xid and further risks from heap_update().

  
commit   : bfa2ab56bb8c512dc8613ee3ff0936568a1c8418    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 15 Jul 2016 17:49:48 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 15 Jul 2016 17:49:48 -0700    

Click here for diff

  
When heap_update needs to look for a page for the new tuple version,  
because the current one doesn't have sufficient free space, or when  
columns have to be processed by the tuple toaster, it has to release the  
lock on the old page during that. Otherwise there'd be lock ordering and  
lock nesting issues.  
  
To avoid concurrent sessions from trying to update / delete / lock the  
tuple while the page's content lock is released, the tuple's xmax is set  
to the current session's xid.  
  
That unfortunately was done without any WAL logging, thereby violating  
the rule that no XIDs may appear on disk, without an according WAL  
record.  If the database were to crash / fail over when the page level  
lock is released, and some activity lead to the page being written out  
to disk, the xid could end up being reused; potentially leading to the  
row becoming invisible.  
  
There might be additional risks by not having t_ctid point at the tuple  
itself, without having set the appropriate lock infomask fields.  
  
To fix, compute the appropriate xmax/infomask combination for locking  
the tuple, and perform WAL logging using the existing XLOG_HEAP_LOCK  
record. That allows the fix to be backpatched.  
  
This issue has existed for a long time. There appears to have been  
partial attempts at preventing dangers, but these never have fully been  
implemented, and were removed a long time ago, in  
11919160 (cf. HEAP_XMAX_UNLOGGED).  
  
In master / 9.6, there's an additional issue, namely that the  
visibilitymap's freeze bit isn't reset at that point yet. Since that's a  
new issue, introduced only in a892234f830, that'll be fixed in a  
separate commit.  
  
Author: Masahiko Sawada and Andres Freund  
Reported-By: Different aspects by Thomas Munro, Noah Misch, and others  
Discussion: CAEepm=3fWAbWryVW9swHyLTY4sXVf0xbLvXqOwUoDiNCx9mBjQ@mail.gmail.com  
Backpatch: 9.1/all supported versions  
  

Make HEAP_LOCK/HEAP2_LOCK_UPDATED replay reset HEAP_XMAX_INVALID.

  
commit   : a4d357bfbd56bd876817fb74f46525dbb3184bc2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 15 Jul 2016 14:37:06 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 15 Jul 2016 14:37:06 -0700    

Click here for diff

  
0ac5ad5 started to compress infomask bits in WAL records. Unfortunately  
the replay routines for XLOG_HEAP_LOCK/XLOG_HEAP2_LOCK_UPDATED forgot to  
reset the HEAP_XMAX_INVALID (and some other) hint bits.  
  
Luckily that's not problematic in the majority of cases, because after a  
crash/on a standby row locks aren't meaningful. Unfortunately that does  
not hold true in the presence of prepared transactions. This means that  
after a crash, or after promotion, row level locks held by a prepared,  
but not yet committed, prepared transaction might not be enforced.  
  
Discussion: 20160715192319.ubfuzim4zv3rqnxv@alap3.anarazel.de  
Backpatch: 9.3, the oldest branch on which 0ac5ad5 is present.  
  

Avoid invalidating all foreign-join cached plans when user mappings change.

  
commit   : 45639a0525a58a2700cf46d4c934d6de78349dac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Jul 2016 17:22:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Jul 2016 17:22:56 -0400    

Click here for diff

  
We must not push down a foreign join when the foreign tables involved  
should be accessed under different user mappings.  Previously we tried  
to enforce that rule literally during planning, but that meant that the  
resulting plans were dependent on the current contents of the  
pg_user_mapping catalog, and we had to blow away all cached plans  
containing any remote join when anything at all changed in pg_user_mapping.  
This could have been improved somewhat, but the fact that a syscache inval  
callback has very limited info about what changed made it hard to do better  
within that design.  Instead, let's change the planner to not consider user  
mappings per se, but to allow a foreign join if both RTEs have the same  
checkAsUser value.  If they do, then they necessarily will use the same  
user mapping at runtime, and we don't need to know specifically which one  
that is.  Post-plan-time changes in pg_user_mapping no longer require any  
plan invalidation.  
  
This rule does give up some optimization ability, to wit where two foreign  
table references come from views with different owners or one's from a view  
and one's directly in the query, but nonetheless the same user mapping  
would have applied.  We'll sacrifice the first case, but to not regress  
more than we have to in the second case, allow a foreign join involving  
both zero and nonzero checkAsUser values if the nonzero one is the same as  
the prevailing effective userID.  In that case, mark the plan as only  
runnable by that userID.  
  
The plancache code already had a notion of plans being userID-specific,  
in order to support RLS.  It was a little confused though, in particular  
lacking clarity of thought as to whether it was the rewritten query or just  
the finished plan that's dependent on the userID.  Rearrange that code so  
that it's clearer what depends on which, and so that the same logic applies  
to both RLS-injected role dependency and foreign-join-injected role  
dependency.  
  
Note that this patch doesn't remove the other issue mentioned in the  
original complaint, which is that while we'll reliably stop using a foreign  
join if it's disallowed in a new context, we might fail to start using a  
foreign join if it's now allowed, but we previously created a generic  
cached plan that didn't use one.  It was agreed that the chance of winning  
that way was not high enough to justify the much larger number of plan  
invalidations that would have to occur if we tried to cause it to happen.  
  
In passing, clean up randomly-varying spelling of EXPLAIN commands in  
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to  
leak into the committed tests.  
  
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the  
previous attempt at ensuring we wouldn't push down foreign joins that  
span permissions contexts.  
  
Etsuro Fujita and Tom Lane  
  
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>  
  

Avoid serializability errors when locking a tuple with a committed update

  
commit   : 533e9c6b0628f6557ddcaf3e5177081878ea7cb6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 Jul 2016 14:17:20 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 Jul 2016 14:17:20 -0400    

Click here for diff

  
When key-share locking a tuple that has been not-key-updated, and the  
update is a committed transaction, in some cases we raised  
serializability errors:  
    ERROR:  could not serialize access due to concurrent update  
  
Because the key-share doesn't conflict with the update, the error is  
unnecessary and inconsistent with the case that the update hasn't  
committed yet.  This causes problems for some usage patterns, even if it  
can be claimed that it's sufficient to retry the aborted transaction:  
given a steady stream of updating transactions and a long locking  
transaction, the long transaction can be starved indefinitely despite  
multiple retries.  
  
To fix, we recognize that HeapTupleSatisfiesUpdate can return  
HeapTupleUpdated when an updating transaction has committed, and that we  
need to deal with that case exactly as if it were a non-committed  
update: verify whether the two operations conflict, and if not, carry on  
normally.  If they do conflict, however, there is a difference: in the  
HeapTupleBeingUpdated case we can just sleep until the concurrent  
transaction is gone, while in the HeapTupleUpdated case this is not  
possible and we must raise an error instead.  
  
Per trouble report from Olivier Dony.  
  
In addition to a couple of test cases that verify the changed behavior,  
I added a test case to verify the behavior that remains unchanged,  
namely that errors are raised when a update that modifies the key is  
used.  That must still generate serializability errors.  One  
pre-existing test case changes behavior; per discussion, the new  
behavior is actually the desired one.  
  
Discussion: https://www.postgresql.org/message-id/560AA479.4080807@odoo.com  
  https://www.postgresql.org/message-id/20151014164844.3019.25750@wrigleys.postgresql.org  
  
Backpatch to 9.3, where the problem appeared.  
  

Fix parsing NOT sequence in tsquery

  
commit   : 00f304ce2dd86f4b76606225b41e0854a3362628    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 15 Jul 2016 20:01:41 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 15 Jul 2016 20:01:41 +0300    

Click here for diff

  
Digging around bug #14245 I found that commit  
6734a1cacd44f5b731933cbc93182b135b167d0c missed that NOT operation is  
right associative in opposite to all other. This miss is resposible for  
tsquery parser fail on sequence of NOT operations  
  

Fix nested NOT operation cleanup in tsquery.

  
commit   : 19d290155d084754eeb5ebb2569654da06073ee8    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 15 Jul 2016 19:22:18 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 15 Jul 2016 19:22:18 +0300    

Click here for diff

  
During normalization of tsquery tree it tries to simplify nested NOT  
operations but there it's obvioulsy missed that subsequent node could be  
a leaf node (value node)  
  
Bug #14245: Segfault on weird to_tsquery  
Reported by David Kellum.  
  

Improve documentation about search_path for SECURITY DEFINER functions.

  
commit   : ce150e7e0fc1a127fee7933d71f4204a79ecce04    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Jul 2016 10:58:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Jul 2016 10:58:39 -0400    

Click here for diff

  
Clarify that the reason for recommending that pg_temp be put last is to  
prevent temporary tables from capturing unqualified table names.  Per  
discussion with Albe Laurenz.  
  
Discussion: <A737B7A37273E048B164557ADEF4A58B5386C6E1@ntex2010i.host.magwien.gv.at>  
  

Adjust spellings of forms of “cancel”

  
commit   : 63cfdb8dde7f25a095af03aa204580fea55c6c07    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Jul 2016 22:48:26 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Jul 2016 22:48:26 -0400    

Click here for diff

  
  

doc: Fix typos

  
commit   : 3aed52a622b1c83abc45c6a7c0ef6dbb9adaa7e1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Jul 2016 22:28:58 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Jul 2016 22:28:58 -0400    

Click here for diff

  
From: Alexander Law <exclusion@gmail.com>  
  

Fix GiST index build for NaN values in geometric types.

  
commit   : 1acf7572554515b99ef6e783750aaea8777524ec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Jul 2016 18:45:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Jul 2016 18:45:59 -0400    

Click here for diff

  
GiST index build could go into an infinite loop when presented with boxes  
(or points, circles or polygons) containing NaN component values.  This  
happened essentially because the code assumed that x == x is true for any  
"double" value x; but it's not true for NaNs.  The looping behavior was not  
the only problem though: we also attempted to sort the items using simple  
double comparisons.  Since NaNs violate the trichotomy law, qsort could  
(in principle at least) get arbitrarily confused and mess up the sorting of  
ordinary values as well as NaNs.  And we based splitting choices on box size  
calculations that could produce NaNs, again resulting in undesirable  
behavior.  
  
To fix, replace all comparisons of doubles in this logic with  
float8_cmp_internal, which is NaN-aware and is careful to sort NaNs  
consistently, higher than any non-NaN.  Also rearrange the box size  
calculation to not produce NaNs; instead it should produce an infinity  
for a box with NaN on one side and not-NaN on the other.  
  
I don't by any means claim that this solves all problems with NaNs in  
geometric values, but it should at least make GiST index insertion work  
reliably with such data.  It's likely that the index search side of things  
still needs some work, and probably regular geometric operations too.  
But with this patch we're laying down a convention for how such cases  
ought to behave.  
  
Per bug #14238 from Guang-Dih Lei.  Back-patch to 9.2; the code used before  
commit 7f3bd86843e5aad8 is quite different and doesn't lock up on my simple  
test case, nor on the submitter's dataset.  
  
Report: <20160708151747.1426.60150@wrigleys.postgresql.org>  
Discussion: <28685.1468246504@sss.pgh.pa.us>  
  

Remove reference to range mode in pg_xlogdump error

  
commit   : 00e0b67a584b51aac12e4279a31fa5a1130fe05f    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 14 Jul 2016 15:39:01 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 14 Jul 2016 15:39:01 +0200    

Click here for diff

  
pg_xlogdump doesn't have any other mode, so it's just confusing to  
include this in the error message as it indicates there might be another  
mode.  
  

Minor test adjustment.

  
commit   : 56a997413391337f7fb9926144d6b6fa831b9d22    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jul 2016 15:36:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jul 2016 15:36:25 -0400    

Click here for diff

  
Dept of second thoughts: given the RESET SESSION AUTHORIZATION that  
was just added by commit cec550139, we don't need the reconnection  
that used to be here.  Might as well buy back a few microseconds.  
  

Add a regression test case to improve code coverage for tuplesort.

  
commit   : cec55013943d160538334ee19ef5db429a085969    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jul 2016 15:23:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jul 2016 15:23:56 -0400    

Click here for diff

  
Test the external-sort code path in CLUSTER for two different scenarios:  
multiple-pass external sorting, and the best case for replacement  
selection, where only one run is produced, so that no merge is required.  
This test would have caught the bug fixed in commit 1b0fc8507, at  
least when run with valgrind enabled.  
  
In passing, add a short-circuit test in plan_cluster_use_sort() to make  
dead certain that it selects sorting when enable_indexscan is off.  As  
things stand, that would happen anyway, but it seems like good future  
proofing for this test.  
  
Peter Geoghegan  
  
Discussion: <CAM3SWZSgxehDkDMq1FdiW2A0Dxc79wH0hz1x-TnGy=1BXEL+nw@mail.gmail.com>  
  

Fix obsolete header-file reference in pg_buffercache docs.

  
commit   : 91c0eb5040cde36a62a34e9b3a80d82db64eb98f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jul 2016 11:17:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jul 2016 11:17:15 -0400    

Click here for diff

  
Commit 2d0019049 moved enum ForkNumber from relfilenode.h into relpath.h,  
but missed updating this documentation reference.  
  
Alexander Law  
  

Add missing hyphen

  
commit   : 42ec6c2da699e8e0b1774988fa97297a2cdf716c    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Wed, 13 Jul 2016 09:17:35 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Wed, 13 Jul 2016 09:17:35 -0400    

Click here for diff

  
Pointed out by Alexander Law  
  

Add serial comma and quoting to message

  
commit   : 5d4050064bf3f2be056a4a887ec11aa14d0d2562    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 12 Jul 2016 18:37:34 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 12 Jul 2016 18:37:34 -0400    

Click here for diff

  
  

Put some things in a better order in psql help

  
commit   : b9fc9f7c3c4096aca69261af305c679ffe74c32b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 12 Jul 2016 18:10:16 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 12 Jul 2016 18:10:16 -0400    

Click here for diff

  
  

Allow IMPORT FOREIGN SCHEMA within pl/pgsql.

  
commit   : baebab3ace480477f210dadc4633d8d119dfa978    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Jul 2016 18:06:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Jul 2016 18:06:50 -0400    

Click here for diff

  
Since IMPORT FOREIGN SCHEMA has an INTO clause, pl/pgsql needs to be  
aware of that and avoid capturing the INTO as an INTO-variables clause.  
This isn't hard, though it's annoying to have to make IMPORT a plpgsql  
keyword just for this.  (Fortunately, we have the infrastructure now  
to make it an unreserved keyword, so at least this shouldn't break any  
existing pl/pgsql code.)  
  
Per report from Merlin Moncure.  Back-patch to 9.5 where IMPORT FOREIGN  
SCHEMA was introduced.  
  
Report: <CAHyXU0wpHf2bbtKGL1gtUEFATCY86r=VKxfcACVcTMQ70mCyig@mail.gmail.com>  
  

doc: Fix typo

  
commit   : d3fbd5929ce5cb7468635aac30c2abf02b7d474a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 12 Jul 2016 13:30:48 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 12 Jul 2016 13:30:48 -0400    

Click here for diff

  
From: Alexander Law <exclusion@gmail.com>  
  

  
commit   : 4d042999f94a4bc41b86baca5920cd4829e16895    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jul 2016 18:14:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jul 2016 18:14:29 -0400    

Click here for diff

  
We have, for a very long time, allowed the same subplan (same member of the  
PlannedStmt.subplans list) to be referenced by more than one SubPlan node;  
this avoids problems for cases such as subplans within an IndexScan's  
indxqual and indxqualorig fields.  However, EXPLAIN had not gotten the memo  
and would print each reference as though it were an independent identical  
subplan.  To fix, track plan_ids of subplans we've printed and don't print  
the same plan_id twice.  Per report from Pavel Stehule.  
  
BTW: the particular case of IndexScan didn't cause visible duplication  
in a plain EXPLAIN, only EXPLAIN ANALYZE, because in the former case we  
short-circuit executor startup before the indxqual field is processed by  
ExecInitExpr.  That seems like it could easily lead to other EXPLAIN  
problems in future, but it's not clear how to avoid it without breaking  
the "EXPLAIN a plan using hypothetical indexes" use-case.  For now I've  
left that issue alone.  
  
Although this is a longstanding bug, it's purely cosmetic (no great harm  
is done by the repeat printout) and we haven't had field complaints before.  
So I'm hesitant to back-patch it, especially since there is some small risk  
of ABI problems due to the need to add a new field to ExplainState.  
  
In passing, rearrange order of fields in ExplainState to be less random,  
and update some obsolete comments about when/where to initialize them.  
  
Report: <CAFj8pRAimq+NK-menjt+3J4-LFoodDD8Or6=Lc_stcFD+eD4DA@mail.gmail.com>  
  

Improve output of psql’s \df+ command.

  
commit   : a670c24c382693c4f75e99c9292b2ed0f0d40a72    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jul 2016 12:35:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jul 2016 12:35:03 -0400    

Click here for diff

  
Add display of proparallel (parallel-safety) when the server is >= 9.6,  
and display of proacl (access privileges) for all server versions.  
Minor tweak of column ordering to keep related columns together.  
  
Michael Paquier  
  
Discussion: <CAB7nPqTR3Vu3xKOZOYqSm-+bSZV0kqgeGAXD6w5GLbkbfd5Q6w@mail.gmail.com>  
  

doc: Update URL for PL/PHP

  
commit   : 740bf396a1d5cc41a8398076a9de1485c497c49c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Jul 2016 12:10:10 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Jul 2016 12:10:10 -0400    

Click here for diff

  
  

Add missing newline in error message

  
commit   : ae7d78c3e24d7991a8f76f4676c015df3d143d63    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 11 Jul 2016 13:53:17 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 11 Jul 2016 13:53:17 +0200    

Click here for diff

  
  

Fix start WAL filename for concurrent backups from standby

  
commit   : 87d84d67bb15752c79a1c07e603126830642ac84    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 11 Jul 2016 12:02:31 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 11 Jul 2016 12:02:31 +0200    

Click here for diff

  
On a standby, ThisTimelineID is always 0, so we would generate a  
filename in timeline 0 even for other timelines. Instead, use starttli  
which we have retreived from the controlfile.  
  
Report by: Francesco Canovai in bug #14230  
Author: Marco Nenciarini  
Reviewed by: Michael Paquier and Amit Kapila  
  

Revert “Add some temporary code to record stack usage at server process exit.”

  
commit   : 96112ee7c60557bb192a9aa07b514db2400fd45e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Jul 2016 12:44:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Jul 2016 12:44:20 -0400    

Click here for diff

  
This reverts commit 88cf37d2a86d5b66380003d7c3384530e3f91e40 as well  
as follow-on commits ea9c4a16d5ad88a1d28d43ef458e3209b53eb106 and  
c57562725d219c4249b82f4a4fb5aaeee3ae0d53.  We've learned about as much  
as we can from the buildfarm.  
  

Fix TAP tests and MSVC scripts for pathnames with spaces.

  
commit   : 30b2731bd21741a6370afba330cea31c75da3bdb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Jul 2016 16:47:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Jul 2016 16:47:38 -0400    

Click here for diff

  
Change assorted places in our Perl code that did things like  
	system("prog $path/file");  
to do it more like  
	system('prog', "$path/file");  
which is safe against spaces and other special characters in the path  
variable.  The latter was already the prevailing style, but a few bits  
of code hadn't gotten this memo.  Back-patch to 9.4 as relevant.  
  
Michael Paquier, Kyotaro Horiguchi  
  
Discussion: <20160704.160213.111134711.horiguchi.kyotaro@lab.ntt.co.jp>  
  

Improve recording of IA64 stack data.

  
commit   : c57562725d219c4249b82f4a4fb5aaeee3ae0d53    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Jul 2016 15:00:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Jul 2016 15:00:22 -0400    

Click here for diff

  
Examination of the results from anole and gharial suggests that we're  
only managing to track the size of one of the two stacks of IA64 machines.  
Some googling gave the answer: on HPUX11, the register stack is reported  
as a page type I don't see in pstat.h on my HPUX10 box.  Let's try  
testing for that.  
  

Add more temporary code to record stack usage at server process exit.

  
commit   : ea9c4a16d5ad88a1d28d43ef458e3209b53eb106    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jul 2016 16:38:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jul 2016 16:38:22 -0400    

Click here for diff

  
After a look at preliminary results from commit 88cf37d2a86d5b66,  
I realized it'd be a good idea to spew out the maximum depth measurement  
seen by check_stack_depth.  So add some quick-n-dirty code to do that.  
Like the previous commit, this will be reverted once we've gathered  
a set of buildfarm runs with it.  
  

Docs: minor improvements for documentation about plpgsql triggers.

  
commit   : 769159fd393f006f29879a71a5f2b3049251b4d9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jul 2016 13:23:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jul 2016 13:23:09 -0400    

Click here for diff

  
Fabien Coelho, some further wordsmithing by me  
  

Docs: improve examples about not repeating table name in UPDATE … SET.

  
commit   : 8ba4ccda457530c65f5f08cb4665c23ce355381d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jul 2016 12:46:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jul 2016 12:46:04 -0400    

Click here for diff

  
Alexander Law  
  

Docs: typo fix.

  
commit   : 262c1b2e1663c3e71e061b40a3e807740866532d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jul 2016 12:40:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jul 2016 12:40:51 -0400    

Click here for diff

  
Etsuro Fujita  
  

Add some temporary code to record stack usage at server process exit.

  
commit   : 88cf37d2a86d5b66380003d7c3384530e3f91e40    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jul 2016 12:01:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jul 2016 12:01:08 -0400    

Click here for diff

  
This patch is meant to gather information from the buildfarm members, and  
will be reverted in a day or so.  The idea is to try to find out the  
high-water stack consumption while running the regression tests,  
particularly on IA64 which is suspected to use much more stack than other  
architectures.  On machines with pmap, we can use that; but the IA64 farm  
members are running HPUX, so also include some bespoke code for HPUX.  
(I've tested the latter on HPUX 10/HPPA; not entirely sure it will work  
on HPUX 11/IA64, but we'll soon find out.)  
  
Discussion: <CAM-w4HMwwcwaVvYcAH0_FGtG5GeXdYVRfvG81pXnSJWHnCfosQ@mail.gmail.com>  
  

Typo fix, buils -> builds

  
commit   : e8bde9e2538a25b4a5deea569c4c48244c1a7e40    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 8 Jul 2016 09:26:53 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 8 Jul 2016 09:26:53 -0400    

Click here for diff

  
Pointed out by Alexander Law.  
  

Fix missing parenthesis in docs

  
commit   : 51dc30856efdbf8a8e56428f9c2bef21c694fb1c    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 8 Jul 2016 10:06:45 +0300    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 8 Jul 2016 10:06:45 +0300    

Click here for diff

  
Author: Alexander Law  
  

Fix typo in comment.

  
commit   : 3edcdbcc4d012093147b50220a7dab57c380d549    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 7 Jul 2016 16:13:37 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 7 Jul 2016 16:13:37 -0400    

Click here for diff

  
Amit Langote  
  

Properly adjust pointers when tuples are moved during CLUSTER.

  
commit   : 1b0fc85077aadb3f4a965aff35c136398d859624    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 7 Jul 2016 13:47:16 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 7 Jul 2016 13:47:16 -0400    

Click here for diff

  
Otherwise, when we abandon incremental memory accounting and use  
batch allocation for the final merge pass, we might crash.  This  
has been broken since 0011c0091e886b874e485a46ff2c94222ffbf550.  
  
Peter Geoghegan, tested by Noah Misch  
  

Fix a prototype which is inconsistent with the function definition.

  
commit   : b22934dc032d7b2a297c2d35dc10fd403c8de631    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 7 Jul 2016 13:46:51 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 7 Jul 2016 13:46:51 -0400    

Click here for diff

  
Peter Geoghegan  
  

Clarify resource utilization of parallel query.

  
commit   : d1f822e58597cac5000bf69b893cc236c5ef5fcb    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 7 Jul 2016 11:18:51 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 7 Jul 2016 11:18:51 -0400    

Click here for diff

  
temp_file_limit is a per-process limit, not a per-session limit across  
all cooperating parallel processes; change wording accordingly, per a  
suggestion from Tom Lane.  
  
Also, document under max_parallel_workers_per_gather the fact that each  
process involved in a parallel query may use as many resources as a  
separate session.  Caveat emptor.  
  
Per a complaint from Peter Geoghegan.  
  

Reduce stack space consumption in tzload().

  
commit   : 62c8421e87b33b2e94f8a7842e1dd9aa1a286ffc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jul 2016 11:28:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jul 2016 11:28:17 -0400    

Click here for diff

  
While syncing our timezone code with IANA's updates in commit 1c1a7cbd6,  
I'd chosen not to adopt the code they conditionally compile under #ifdef  
ALL_STATE.  The main thing that that drives is that the space for gmtime  
and localtime timezone definitions isn't statically allocated, but is  
malloc'd on first use.  I reasoned we didn't need that logic: we don't have  
localtime() at all, and we always initialize TimeZone to GMT so we always  
need that one.  But there is one other thing ALL_STATE does, which is to  
make tzload() malloc its transient workspace instead of just declaring it  
as a local variable.  It turns out that that local variable occupies 78K.  
Even worse is that, at least for common US timezone settings, there's a  
recursive call to parse the "posixrules" zone name, making peak stack  
consumption to select a time zone upwards of 150K.  That's an uncomfortably  
large fraction of our STACK_DEPTH_SLOP safety margin, and could result in  
outright crashes if we try to reduce STACK_DEPTH_SLOP as has been discussed  
recently.  Furthermore, this means that the postmaster's peak stack  
consumption is several times that of a backend running typical queries  
(since, except on Windows, backends inherit the timezone GUC values and  
don't ever run this code themselves unless you do SET TIMEZONE).  That's  
completely backwards from a safety perspective.  
  
Hence, adopt the ALL_STATE rather than non-ALL_STATE variant of tzload(),  
while not changing the other code aspects that symbol controls.  The  
risk of an ENOMEM error from malloc() seems less than that of a SIGSEGV  
from stack overrun.  
  
This should probably get back-patched along with 1c1a7cbd6 and followon  
fixes, whenever we decide we have enough confidence in the updates to do  
that.  
  

Rename pg_stat_wal_receiver.conn_info to conninfo.

  
commit   : 60d50769b70ca5030711f70c86d7a2d3bcf34963    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 7 Jul 2016 12:59:39 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 7 Jul 2016 12:59:39 +0900    

Click here for diff

  
Per discussion on pgsql-hackers, conninfo is better as the column name  
because it's more commonly used in PostgreSQL.  
  
Catalog version bumped due to the change of pg_proc.  
  
Author: Michael Paquier  
  

Fix typos

  
commit   : 397bf6eed81bfaacb84065b912a8968a179b4166    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 6 Jul 2016 21:18:03 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 6 Jul 2016 21:18:03 -0400    

Click here for diff

  
  

doc: Fix option order in man pages and fix typos

  
commit   : 9b7bb106e023ced822d5ed4846d445737e54e118    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 6 Jul 2016 21:09:26 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 6 Jul 2016 21:09:26 -0400    

Click here for diff

  
  

Fix typo in comment.

  
commit   : 1109164913caf7fa64e75e0b9fa64f7ba5fe5753    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 6 Jul 2016 18:59:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 6 Jul 2016 18:59:17 +0900    

Click here for diff

  
Author: Masahiko Sawada  
  

Fix failure to handle conflicts in non-arbiter exclusion constraints.

  
commit   : 9c810a2edccaffe0ff48b50d31c47a155e4f9815    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Jul 2016 16:09:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Jul 2016 16:09:11 -0400    

Click here for diff

  
ExecInsertIndexTuples treated an exclusion constraint as subject to  
noDupErr processing even when it was not listed in arbiterIndexes, and  
would therefore not error out for a conflict in such a constraint, instead  
returning it as an arbiter-index failure.  That led to an infinite loop in  
ExecInsert, since ExecCheckIndexConstraints ignored the index as-intended  
and therefore didn't throw the expected error.  To fix, make the exclusion  
constraint code path use the same condition as the index_insert call does  
to decide whether no-error-for-duplicates behavior is appropriate.  While  
at it, refactor a little bit to avoid unnecessary list_member_oid calls.  
(That surely wouldn't save anything worth noticing, but I find the code  
a bit clearer this way.)  
  
Per bug report from Heikki Rauhala.  Back-patch to 9.5 where ON CONFLICT  
was introduced.  
  
Report: <4C976D6B-76B4-434C-8052-D009F7B7AEDA@reaktor.fi>  
  

Typo fix.

  
commit   : 29a2195de645759d66ee7e77c4c05b2c4aeb6729    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2016 18:43:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2016 18:43:43 -0400    

Click here for diff

  
  

Allow RTE_SUBQUERY rels to be considered parallel-safe.

  
commit   : 110a6dbdebebac9401b43a8fc223e6ec43cd4d10    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2016 18:24:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2016 18:24:49 -0400    

Click here for diff

  
There isn't really any reason not to; the original comments here were  
partly confused about subplans versus subquery-in-FROM, and partly  
dependent on restrictions that no longer apply now that subqueries return  
Paths not Plans.  Depending on what's inside the subquery, it might fail  
to produce any parallel_safe Paths, but that's fine.  
  
Tom Lane and Robert Haas  
  

Fix up parallel-safety marking for appendrels.

  
commit   : 4ea9948e58a57316330acb1701f979bc1e872f50    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2016 17:57:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2016 17:57:28 -0400    

Click here for diff

  
The previous coding assumed that the value derived by  
set_rel_consider_parallel() for an appendrel parent would be accurate for  
all the appendrel's children; but this is not so, for example because one  
child might scan a temp table.  Instead, apply set_rel_consider_parallel()  
to each child rel as well as the parent, and then take the AND of the  
results as controlling parallel safety for the appendrel as a whole.  
  
(We might someday be able to deal more intelligently than this with cases  
in which some of the childrels are parallel-safe and others not, but that's  
for later.)  
  
Robert Haas and Tom Lane  
  

Allow treating TABLESAMPLE scans as parallel-safe.

  
commit   : 2c6e6471af9f5b6e4d1b25814a86a1dbd2eb928a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2016 16:55:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2016 16:55:27 -0400    

Click here for diff

  
This was the intention all along, but an extraneous "return;" in  
set_rel_consider_parallel() caused sampled rels to never be marked  
consider_parallel.  
  
Since we don't have any partial tablesample path/plan type yet, there's  
no possibility of parallelizing the sample scan itself; but this fix  
allows such a scan to appear below a parallel join, for example.  
  

Set correct cost data in Gather node added by force_parallel_mode.

  
commit   : 0e495c5e2f97aa7e2323705a6daed73cdd6c168c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2016 15:35:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2016 15:35:29 -0400    

Click here for diff

  
We were just leaving the cost fields zeroes, which produces obviously bogus  
output with force_parallel_mode = on.  With force_parallel_mode = regress,  
the zeroes are hidden, but I wonder if they wouldn't still confuse add-on  
code such as auto_explain.  
  

Round rowcount estimate for a partial path to an integer.

  
commit   : c89d507649df9fbc21617e02ab4d5e765a28b7df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2016 14:53:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2016 14:53:37 -0400    

Click here for diff

  
I'd been wondering why I was sometimes seeing fractional rowcount  
estimates in parallel-query situations, and this seems to be the  
reason.  (You won't see the fractional parts in EXPLAIN, because it  
prints rowcounts with %.0f, but they are apparent in the debugger.)  
A fractional rowcount is not any saner for a partial path than any  
other kind of path, and it's equally likely to break cost estimation  
for higher paths, so apply clamp_row_est() like we do in other places.  
  

PL/Python: Report argument parsing errors using exceptions

  
commit   : 3a4a33ad49e7887b104a29323e4ea625d164a139    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 2 Jul 2016 22:53:14 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 2 Jul 2016 22:53:14 -0400    

Click here for diff

  
Instead of calling PLy_elog() for reporting Python argument parsing  
errors, generate appropriate exceptions.  This matches the existing plpy  
functions and is more consistent with the behavior of the Python  
argument parsing routines.  
  

Fix failure to mark all aggregates with appropriate transtype.

  
commit   : 420c1661630c96ad10f58ca967d5f561bb404cf9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Jul 2016 13:23:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Jul 2016 13:23:02 -0400    

Click here for diff

  
In commit 915b703e1 I gave get_agg_clause_costs() the responsibility of  
marking Aggref nodes with the appropriate aggtranstype.  I failed to notice  
that where it was being called from, it might see only a subset of the  
Aggref nodes that were in the original targetlist.  Specifically, if there  
are duplicate aggregate calls in the tlist, either make_sort_input_target  
or make_window_input_target might put just a single instance into the  
grouping_target, and then only that instance would get marked.  Fix by  
moving the call back into grouping_planner(), before we start building  
assorted PathTargets from the query tlist.  Per report from Stefan Huehner.  
  
Report: <20160702131056.GD3165@huehner.biz>  
  

doc: mention dependency on collation libraries

  
commit   : b54f7a9ac9646845138f6851fdf3097e22daa383    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 2 Jul 2016 11:22:36 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 2 Jul 2016 11:22:36 -0400    

Click here for diff

  
Document that index storage is dependent on the operating system's  
collation library ordering, and any change in that ordering can create  
invalid indexes.  
  
Discussion: 20160617154311.GB19359@momjian.us  
  
Backpatch-through: 9.1  
  

Fix some interrelated planner issues with initPlans and Param munging.

  
commit   : 7b67a0a49c19a566ee735f3b156677dab11bd902    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jul 2016 20:05:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jul 2016 20:05:55 -0400    

Click here for diff

  
In commit 68fa28f77 I tried to teach SS_finalize_plan() to cope with  
initPlans attached anywhere in the plan tree, by dint of moving its  
handling of those into the recursion in finalize_plan().  It turns out that  
that doesn't really work: if a lower-level plan node emits an initPlan  
output parameter in its targetlist, it's legitimate for upper levels to  
reference those Params --- and at the point where this code runs, those  
references look just like the Param itself, so finalize_plan() quite  
properly rejects them as being in the wrong place.  We could lobotomize  
the checks enough to allow that, probably, but then it's not clear that  
we'd have any meaningful check for misplaced Params at all.  What seems  
better, at least in the near term, is to tweak standard_planner() a bit  
so that initPlans are never placed anywhere but the topmost plan node  
for a query level, restoring the behavior that occurred pre-9.6.  Possibly  
we can do better if this code is ever merged into setrefs.c: then it would  
be possible to check a Param's placement only when we'd failed to replace  
it with a Var referencing a child plan node's targetlist.  
  
BTW, I'm now suspicious that finalize_plan is doing the wrong thing by  
returning the node's allParam rather than extParam to be incorporated  
in the parent node's set of used parameters.  However, it makes no  
difference given that initPlans only appear at top level, so I'll leave  
that alone for now.  
  
Another thing that emerged from this is that standard_planner() needs  
to check for initPlans before deciding that it's safe to stick a Gather  
node on top in force_parallel_mode mode.  We previously guarded against  
that by deciding the plan wasn't wholePlanParallelSafe if any subplans  
had been found, but after commit 5ce5e4a12 it's necessary to have this  
substitute test, because path parallel_safe markings don't account for  
initPlans.  (Normally, we'd have decided the paths weren't safe anyway  
due to appearances of SubPlan nodes, Params, or CTE scans somewhere in  
the tree --- but it's possible for those all to be optimized away while  
initPlans still remain.)  
  
Per fuzz testing by Andreas Seltenreich.  
  
Report: <874m89rw7x.fsf@credativ.de>  
  

Improve WritebackContextInit() comment and prototype argument names.

  
commit   : 48bfeb244ff280bad9a81c67442065ae8fcda6b8    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 1 Jul 2016 14:27:53 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 1 Jul 2016 14:27:53 -0700    

Click here for diff

  
Author: Masahiko Sawada  
Discussion: CAD21AoBD=Of1OzL90Xx4Q-3j=-2q7=S87cs75HfutE=eCday2w@mail.gmail.com  
  

Provide and use a makefile target to build all generated headers.

  
commit   : 548af97fcec5543603c20b61fec60f8147a05b29    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jul 2016 15:08:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jul 2016 15:08:55 -0400    

Click here for diff

  
As of 9.6, pg_regress doesn't build unless storage/lwlocknames.h has been  
created; but there was nothing forcing that to happen if you just went into  
src/test/regress/ and built there.  We previously had a similar complaint  
about plpython.  
  
To fix in a way that won't break next time we invent a generated header,  
make src/backend/Makefile expose a phony target for updating all the  
include files it builds, and invoke that before building pg_regress or  
plpython.  In principle, maybe we ought to invoke that everywhere; but  
it would add a lot of usually-useless make cycles, so let's just do it  
in the places where people have complained.  
  
I made a couple of cosmetic adjustments in src/backend/Makefile as well,  
to deal with the generated headers in consistent orders.  
  
Michael Paquier and Tom Lane  
  
Report: <31398.1467036827@sss.pgh.pa.us>  
Report: <20150916200959.GB32090@msg.df7cb.de>  
  

walreceiver: tweak pg_stat_wal_receiver behavior

  
commit   : 1bdae16fca884a9190dc330790e7a63c04989fa3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Jul 2016 13:53:46 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 1 Jul 2016 13:53:46 -0400    

Click here for diff

  
There are two problems in the original coding: one is that if one  
walreceiver process exits, the ready_to_display flag remains set in  
shared memory, exposing the conninfo of the next walreceiver before  
obfuscating.  Fix by having WalRcvDie reset the flag.  
  
Second, the sleep-and-retry behavior that waited until walreceiver had  
set ready_to_display wasn't liked; the preference is to have it return  
no data instead, so let's do that.  
  
Bugs in 9ed551e0a reported by Fujii Masao and Michël Paquier.  
  
Author: Michaël Paquier  
  

Rethink the GetForeignUpperPaths API (again).

  
commit   : 9e703987a8a1961af8edd751169a8ae1055890eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jul 2016 13:12:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jul 2016 13:12:34 -0400    

Click here for diff

  
In the previous design, the GetForeignUpperPaths FDW callback hook was  
called before we got around to labeling upper relations with the proper  
consider_parallel flag; this meant that any upper paths created by an FDW  
would be marked not-parallel-safe.  While that's probably just as well  
right now, we aren't going to want it to be true forever.  Hence, abandon  
the idea that FDWs should be allowed to inject upper paths before the core  
code has gotten around to creating the relevant upper relation.  (Well,  
actually they still can, but it's on their own heads how well it works.)  
Instead, adopt the same API already designed for create_upper_paths_hook:  
we call GetForeignUpperPaths after each upperrel has been created and  
populated with the paths the core planner knows how to make.  
  

Set consider_parallel correctly for upper planner rels.

  
commit   : 5ce5e4a12ee7175cd3fc356d9d38307e1d715827    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 1 Jul 2016 11:43:19 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 1 Jul 2016 11:43:19 -0400    

Click here for diff

  
Commit 3fc6e2d7f5b652b417fa6937c34de2438d60fa9f introduced new "upper"  
RelOptInfo structures but didn't set consider_parallel for them  
correctly, a point I completely missed when reviewing it.  Later,  
commit e06a38965b3bcdaa881e7e06892d4d8ab6c2c980 made the situation  
worse by doing it incorrectly for the grouping relation.  Try to  
straighten all of that out.  Along the way, get rid of the annoying  
wholePlanParallelSafe flag, which was only necessarily because of  
the fact that upper planning stages didn't use paths at the time  
that code was written.  
  
The most important immediate impact of these changes is that  
force_parallel_mode will provide useful test coverage in quite a few  
more scenarios than it did previously, but it's also necessary  
preparation for fixing some problems related to subqueries.  
  
Patch by me, reviewed by Tom Lane.  
  

Be more paranoid in ruleutils.c’s get_variable().

  
commit   : 0daeba0e927bfcb3d0ed9d510b84e555fc1e2741    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jul 2016 11:40:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jul 2016 11:40:22 -0400    

Click here for diff

  
We were merely Assert'ing that the Var matched the RTE it's supposedly  
from.  But if the user passes incorrect information to pg_get_expr(),  
the RTE might in fact not match; this led either to Assert failures  
or core dumps, as reported by Chris Hanks in bug #14220.  To fix, just  
convert the Asserts to test-and-elog.  Adjust an existing test-and-elog  
elsewhere in the same function to be consistent in wording.  
  
(If we really felt these were user-facing errors, we might promote them to  
ereport's; but I can't convince myself that they're worth translating.)  
  
Back-patch to 9.3; the problematic code doesn't exist before that, and  
a quick check says that 9.2 doesn't crash on such cases.  
  
Michael Paquier and Thomas Munro  
  
Report: <20160629224349.1407.32667@wrigleys.postgresql.org>  
  

postgres_fdw: Fix cache lookup failure while creating error context.

  
commit   : 86437ddf8c8da6fff49bdf08a22af3460e078eeb    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 1 Jul 2016 11:29:25 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 1 Jul 2016 11:29:25 -0400    

Click here for diff

  
This is fallout from join pushdown; get_relid_attribute_name can't  
handle an attribute number of 0, indicating a whole-row reference,  
and shouldn't be called in that case.  
  
Etsuro Fujita, reviewed by Ashutosh Bapat  
  

postgres_fdw: Remove schema-qualification from cast to text.

  
commit   : 5f3499b2b5455a2966faee30fd3f6d2776219858    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 1 Jul 2016 10:13:06 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 1 Jul 2016 10:13:06 -0400    

Click here for diff

  
As pointed out by Ashutosh Bapat, the header comments for this file  
say that schema-qualification is needed for all and only those types  
outside pg_catalog.  pg_catalog.text is not outside pg_catalog.  
  

Fix crash bug in RestoreSnapshot.

  
commit   : 4f9f495889d3d410195c9891b58228727b340189    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 1 Jul 2016 08:51:58 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 1 Jul 2016 08:51:58 -0400    

Click here for diff

  
If serialized_snapshot->subxcnt > 0 and serialized_snapshot->xcnt == 0,  
the old coding would do the wrong thing and crash.  This can happen  
on standby servers.  
  
Report by Andreas Seltenreich.  Patch by Thomas Munro, reviewed by  
Amit Kapila and tested by Andreas Seltenreich.  
  

Fix several mistakes around parallel workers and client_encoding.

  
commit   : 10c0558ffefcd12bf1d3dc35587eba41d1ce4571    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Jun 2016 18:35:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Jun 2016 18:35:32 -0400    

Click here for diff

  
Previously, workers sent data to the leader using the client encoding.  
That mostly worked, but the leader the converted the data back to the  
server encoding.  Since not all encoding conversions are reversible,  
that could provoke failures.  Fix by using the database encoding for  
all communication between worker and leader.  
  
Also, while temporary changes to GUC settings, as from the SET clause  
of a function, are in general OK for parallel query, changing  
client_encoding this way inside of a parallel worker is not OK.  
Previously, that would have confused the leader; with these changes,  
it would not confuse the leader, but it wouldn't do anything either.  
So refuse such changes in parallel workers.  
  
Also, the previous code naively assumed that when it received a  
NotifyResonse from the worker, it could pass that directly back to the  
user.  But now that worker-to-leader communication always uses the  
database encoding, that's clearly no longer correct - though,  
actually, the old way was always broken for V2 clients.  So  
disassemble and reconstitute the message instead.  
  
Issues reported by Peter Eisentraut.  Patch by me, reviewed by  
Peter Eisentraut.  
  

Fix typo in ReorderBufferIterTXNInit().

  
commit   : f8c58554db48fe004938a8a34a42afb78157b66c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Jun 2016 12:37:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Jun 2016 12:37:02 -0400    

Click here for diff

  
This looks like it would cause changes from subtransactions to be missed  
by the iterator being constructed, if those changes had been spilled to  
disk previously.  This implies that large subtransactions might be lost  
(in whole or in part) by logical replication.  Found and fixed by  
Petru-Florin Mihancea, per bug #14208.  
  
Report: <20160622144830.5791.22512@wrigleys.postgresql.org>  
  

Dodge compiler bug in Visual Studio 2013.

  
commit   : 3154e16737ad17b2c63529e3df627bb5eb3bb3be    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jun 2016 19:07:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jun 2016 19:07:19 -0400    

Click here for diff

  
VS2013 apparently has a problem with taking the address of a formal  
parameter in some cases.  We do that elsewhere without trouble, but  
in this case the address is being passed to a subroutine that will  
probably get inlined, so maybe the combination of those things is  
what tickles the bug.  Anyway, introducing an extra copy of the  
parameter value is enough to work around it.  Per trouble report  
from Umair Shahid.  
  
Report: <CAM184AcjqKYZSdQqBHDrnENXHhW=mXbUC46QYPJ=nAh0gUHCGA@mail.gmail.com>  
  

Fix some infelicities in EXPLAIN output for parallel query plans.

  
commit   : 8ebb69f85445177575684a0ba5cfedda8d840a91    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jun 2016 18:51:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jun 2016 18:51:20 -0400    

Click here for diff

  
In non-text output formats, parallelized aggregates were reporting  
"Partial" or "Finalize" as a field named "Operation", which might be all  
right in the absence of any context --- but other plan node types use that  
field to report SQL-visible semantics, such as Select/Insert/Update/Delete.  
So that naming choice didn't seem good to me.  I changed it to "Partial  
Mode".  
  
Also, the field did not appear at all for a non-parallelized Agg plan node,  
which is contrary to expectation in non-text formats.  We're notionally  
producing objects that conform to a schema, so the set of fields for a  
given node type and EXPLAIN mode should be well-defined.  I set it up to  
fill in "Simple" in such cases.  
  
Other fields that were added for parallel query, namely "Parallel Aware"  
and Gather's "Single Copy", had not gotten the word on that point either.  
Make them appear always in non-text output.  
  
Also, the latter two fields were nominally producing boolean output, but  
were getting it wrong, because bool values shouldn't be quoted in JSON or  
YAML.  Somehow we'd not needed an ExplainPropertyBool formatting subroutine  
before 9.6; but now we do, so invent it.  
  
Discussion: <16002.1466972724@sss.pgh.pa.us>  
  

Update rules.out to match commit 9ed551e0a.

  
commit   : 0584df32f577ef05fc2a682a97d3c81387eccdb9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jun 2016 17:13:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jun 2016 17:13:29 -0400    

Click here for diff

  
Per buildfarm.  
  

Add conninfo to pg_stat_wal_receiver

  
commit   : 9ed551e0a4fdb046d8e5ea779adfd3e184d5dc0d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 29 Jun 2016 16:57:17 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 29 Jun 2016 16:57:17 -0400    

Click here for diff

  
Commit b1a9bad9e744 introduced a stats view to provide insight into the  
running WAL receiver, but neglected to include the connection string in  
it, as reported by Michaël Paquier.  This commit fixes that omission.  
(Any security-sensitive information is not disclosed).  
  
While at it, close the mild security hole that we were exposing the  
password in the connection string in shared memory.  This isn't  
user-accessible, but it still looks like a good idea to avoid having the  
cleartext password in memory.  
  
Author: Michaël Paquier, Álvaro Herrera  
Review by: Vik Fearing  
  
Discussion: https://www.postgresql.org/message-id/CAB7nPqStg4M561obo7ryZ5G+fUydG4v1Ajs1xZT1ujtu+woRag@mail.gmail.com  
  

Fix match_foreign_keys_to_quals for FKs linking to unused rtable entries.

  
commit   : b32e63506cfec8c8bd3237ec5043de7414564d10    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jun 2016 16:02:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jun 2016 16:02:08 -0400    

Click here for diff

  
Since get_relation_foreign_keys doesn't try to determine whether RTEs  
are actually part of the query semantics, it might make FK info records  
linking to RTEs that won't have a RelOptInfo at all.  Cope with that.  
Per bug #14219 from Andrew Gierth.  
  
Report: <20160629183338.1397.43514@wrigleys.postgresql.org>  
  

Adjust text search documentation for recent commits.

  
commit   : 4242a715c3fca1a8fa31f810b7cffa88b4d4e439    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jun 2016 15:00:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jun 2016 15:00:25 -0400    

Click here for diff

  
Fix some now-obsolete statements that were overlooked in commits  
6734a1cac, 3dbbd0f02, 028350f61.  Document the behavior of <0>.  
Also do a little bit of rearranging and copy-editing for clarity.  
  

Fix obsolete comment.

  
commit   : 8dee039fa1e7b373a20985d80dbe1a5dbfd1eb2b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 29 Jun 2016 13:12:50 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 29 Jun 2016 13:12:50 -0400    

Click here for diff

  
Commit 3bd261ca18c67eafe18088e58fab511e3b965418 should have updated  
this, but didn't.  
  
Extracted from a larger patch by Piotr Stefaniak.  
  

Document precedence of FTS operators in tsquery

  
commit   : 73e6bea603548810769fd8ac8b19342f759ef07d    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Wed, 29 Jun 2016 17:59:36 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Wed, 29 Jun 2016 17:59:36 +0300    

Click here for diff

  
Oleg Bartunov  
  

  
commit   : 8a395e0b9a2118453df3d9c31ddb43f811315ddd    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 Jun 2016 16:16:06 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 Jun 2016 16:16:06 -0400    

Click here for diff

  
Reported-by: Manlio Perillo  
  
Bug: 14016  
  
Discussion: 20160311163928.6674.94707@wrigleys.postgresql.org  
  
Reviewed-by: David G. Johnston  
  

doc: update effective_io_concurrency for SSDs

  
commit   : 46eafc8855d7c21e2c1a45faa77a3d5a2fc2c8b2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 Jun 2016 16:09:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 Jun 2016 16:09:04 -0400    

Click here for diff

  
SSDs are no longer exotic, so recommend a default in the hundreds for  
them.  
  

Remove unused arguments in two GiST subroutines

  
commit   : b78364df1850a09ece442a138118f4be1a451366    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 Jun 2016 16:01:13 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 Jun 2016 16:01:13 -0400    

Click here for diff

  
These arguments became unused in commit 2c03216d8311.  Noticed while  
skimming code for unrelated development.  
  
This is cosmetic, so no backpatch.  
  

doc: remove GIN vs. GiST performance mention

  
commit   : 8e1ad1b37c7afdf99815f9ed1ca255264e0b3f9e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 Jun 2016 16:00:40 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 Jun 2016 16:00:40 -0400    

Click here for diff

  
This is a followup to commit 6d8b2aa83af70e20323caf23961667dc4c149276.  
  

doc: in binary mode mention, say “encoding conversion”

  
commit   : 69769a3a6e7c09270aba3094d3ff6df771adf977    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 Jun 2016 14:21:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 Jun 2016 14:21:43 -0400    

Click here for diff

  
Used to say "character set conversion"  
  
Reported-by: Tatsuo Ishii  
  
Discussion: 20160618.210417.343199294611427151.t-ishii@sraoss.co.jp  
  

doc: remove mention of UT1 in representing time

  
commit   : 675684fc23fd4287966694b1f108846bc14b6895    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 Jun 2016 13:49:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 28 Jun 2016 13:49:37 -0400    

Click here for diff

  
UT1 was incorrectly specified as our time representation.  (UT1 is  
astronomical time.)  We are not actually UTC either because we ignore  
leap seconds.  
  
Reported-by: Thomas Munro  
  
Discussion: CAEepm=3-TW9PLwGZhqjSSiEQ9UzJEKE-HELQDzRE0QUSCp8dgw@mail.gmail.com  
  

Don’t apply sortgroupref labels to a tlist that might not match.

  
commit   : c12f02ffc94faac09eae254b3bf114c153f116f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jun 2016 10:43:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jun 2016 10:43:11 -0400    

Click here for diff

  
If we need to use a gating Result node for pseudoconstant quals,  
create_scan_plan() intentionally suppresses use_physical_tlist's checks  
on whether there are matches for sortgroupref labels, on the grounds that  
we don't need matches because we can label the Result's projection output  
properly.  However, it then called apply_pathtarget_labeling_to_tlist  
anyway.  This oversight was harmless when written, but in commit aeb9ae645  
I made that function throw an error if there was no match.  Thus, the  
combination of a table scan, pseudoconstant quals, and a non-simple-Var  
sortgroupref column threw the dreaded "ORDER/GROUP BY expression not found  
in targetlist" error.  To fix, just skip applying the labeling in this  
case.  Per report from Rushabh Lathia.  
  
Report: <CAGPqQf2iLB8t6t-XrL-zR233DFTXxEsfVZ4WSqaYfLupEoDxXA@mail.gmail.com>  
  

Fix mistakes in pg_visibility documentation.

  
commit   : 957616dbaef0e7f182e6260483bca79a38ae247f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 27 Jun 2016 17:54:28 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 27 Jun 2016 17:54:28 -0400    

Click here for diff

  
Michael Paquier  
  

Fix CREATE MATVIEW/CREATE TABLE AS … WITH NO DATA to not plan the query.

  
commit   : 874fe3aea121b4ceb186d59ba6956e2f7d5aa0bb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Jun 2016 15:57:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Jun 2016 15:57:21 -0400    

Click here for diff

  
Previously, these commands always planned the given query and went through  
executor startup before deciding not to actually run the query if WITH NO  
DATA is specified.  This behavior is problematic for pg_dump because it  
may cause errors to be raised that we would rather not see before a  
REFRESH MATERIALIZED VIEW command is issued.  See for example bug #13907  
from Marian Krucina.  This change is not sufficient to fix that particular  
bug, because we also need to tweak pg_dump to issue the REFRESH later,  
but it's a necessary step on the way.  
  
A user-visible side effect of doing things this way is that the returned  
command tag for WITH NO DATA cases will now be "CREATE MATERIALIZED VIEW"  
or "CREATE TABLE AS", not "SELECT 0".  We could preserve the old behavior  
but it would take more code, and arguably that was just an implementation  
artifact not intended behavior anyhow.  
  
In 9.5 and HEAD, also get rid of the static variable CreateAsReladdr, which  
was trouble waiting to happen; there is not any prohibition on nested  
CREATE commands.  
  
Back-patch to 9.3 where CREATE MATERIALIZED VIEW was introduced.  
  
Michael Paquier and Tom Lane  
  
Report: <20160202161407.2778.24659@wrigleys.postgresql.org>  
  

Change predecence of phrase operator.

  
commit   : 6734a1cacd44f5b731933cbc93182b135b167d0c    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 27 Jun 2016 20:55:24 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 27 Jun 2016 20:55:24 +0300    

Click here for diff

  
<-> operator now have higher predecence than & (AND) operator. This change  
was motivated by unexpected difference of similar queries:  
'a & b <-> c'::tsquery and 'b <-> c & a'. Before first query means  
(a & b) <-> c and second one - '(b <-> c) & a', now phrase operator evaluates  
first.  
  
Per suggestion from Tom Lane 32260.1465402409@sss.pgh.pa.us  
  

Do not fallback to AND for FTS phrase operator.

  
commit   : 3dbbd0f02a257d8d5c4cba14726371505f2e7266    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 27 Jun 2016 20:47:32 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 27 Jun 2016 20:47:32 +0300    

Click here for diff

  
If there is no positional information of lexemes then phrase operator will not  
fallback to AND operator. This change makes needing to modify TS_execute()  
interface, because somewhere (in indexes, for example) positional information  
is unaccesible and in this cases we need to force fallback to AND.  
  
Per discussion c19fcfec308e6ccd952cdde9e648b505@mail.gmail.com  
  

Make exact distance match for FTS phrase operator

  
commit   : 028350f619f7688e0453fcd2c4b25abe9ba30fa7    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 27 Jun 2016 20:41:00 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 27 Jun 2016 20:41:00 +0300    

Click here for diff

  
Phrase operator now requires exact distance betweens lexems instead of  
less-or-equal.  
  
Per discussion c19fcfec308e6ccd952cdde9e648b505@mail.gmail.com  
  

Avoid making a separate pass over the query to check for partializability.

  
commit   : f1993038a4f0ce5fbeb7b562b2acd571bf6b567b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Jun 2016 15:55:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Jun 2016 15:55:01 -0400    

Click here for diff

  
It's rather silly to make a separate pass over the tlist + HAVING qual,  
and a separate set of visits to the syscache, when get_agg_clause_costs  
already has all the required information in hand.  This nets out as less  
code as well as fewer cycles.  
  

Rethink node-level representation of partial-aggregation modes.

  
commit   : 19e972d5580c655423572e3c870e47b5b7c346f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Jun 2016 14:33:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Jun 2016 14:33:38 -0400    

Click here for diff

  
The original coding had three separate booleans representing partial  
aggregation behavior, which was confusing, unreadable, and error-prone,  
not least because the booleans weren't always listed in the same order.  
It was also inadequate for the allegedly-desirable future extension to  
support intermediate partial aggregation, because we'd need separate  
markers for serialization and deserialization in such a case.  
  
Merge these bools into an enum "AggSplit" to provide symbolic names for  
the supported operating modes (and document what those are).  By assigning  
the values of the enum constants carefully, we can treat AggSplit values  
as options bitmasks so that tests of what to do aren't noticeably more  
expensive than before.  
  
While at it, get rid of Aggref.aggoutputtype.  That's not needed since  
commit 59a3795c2 got rid of setrefs.c's special-purpose Aggref comparison  
code, and it likewise seemed more confusing than helpful.  
  
Assorted comment cleanup as well (there's still more that I want to do  
in that line).  
  
catversion bump for change in Aggref node contents.  Should be the last  
one for partial-aggregation changes.  
  
Discussion: <29309.1466699160@sss.pgh.pa.us>  
  

Simplify planner’s final setup of Aggrefs for partial aggregation.

  
commit   : 59a3795c2589a0e6dfe4d9a886de9423b3f8b057    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Jun 2016 12:08:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Jun 2016 12:08:12 -0400    

Click here for diff

  
Commit e06a38965's original coding for constructing the execution-time  
expression tree for a combining aggregate was rather messy, involving  
duplicating quite a lot of code in setrefs.c so that it could inject  
a nonstandard matching rule for Aggrefs.  Get rid of that in favor of  
explicitly constructing a combining Aggref with a partial Aggref as input,  
then allowing setref's normal matching logic to match the partial Aggref  
to the output of the lower plan node and hence replace it with a Var.  
  
In passing, rename and redocument make_partialgroup_input_target to have  
some connection to what it actually does.  
  

Fix handling of multixacts predating pg_upgrade

  
commit   : e3ad3ffa68193dd889a9cea9d840bf4613bd680b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 24 Jun 2016 18:29:28 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 24 Jun 2016 18:29:28 -0400    

Click here for diff

  
After pg_upgrade, it is possible that some tuples' Xmax have multixacts  
corresponding to the old installation; such multixacts cannot have  
running members anymore.  In many code sites we already know not to read  
them and clobber them silently, but at least when VACUUM tries to freeze  
a multixact or determine whether one needs freezing, there's an attempt  
to resolve it to its member transactions by calling GetMultiXactIdMembers,  
and if the multixact value is "in the future" with regards to the  
current valid multixact range, an error like this is raised:  
    ERROR:  MultiXactId 123 has not been created yet -- apparent wraparound  
and vacuuming fails.  Per discussion with Andrew Gierth, it is completely  
bogus to try to resolve multixacts coming from before a pg_upgrade,  
regardless of where they stand with regards to the current valid  
multixact range.  
  
It's possible to get from under this problem by doing SELECT FOR UPDATE  
of the problem tuples, but if tables are large, this is slow and  
tedious, so a more thorough solution is desirable.  
  
To fix, we realize that multixacts in xmax created in 9.2 and previous  
have a specific bit pattern that is never used in 9.3 and later (we  
already knew this, per comments and infomask tests sprinkled in various  
places, but we weren't leveraging this knowledge appropriately).  
Whenever the infomask of the tuple matches that bit pattern, we just  
ignore the multixact completely as if Xmax wasn't set; or, in the case  
of tuple freezing, we act as if an unwanted value is set and clobber it  
without decoding.  This guarantees that no errors will be raised, and  
that the values will be progressively removed until all tables are  
clean.  Most callers of GetMultiXactIdMembers are patched to recognize  
directly that the value is a removable "empty" multixact and avoid  
calling GetMultiXactIdMembers altogether.  
  
To avoid changing the signature of GetMultiXactIdMembers() in back  
branches, we keep the "allow_old" boolean flag but rename it to  
"from_pgupgrade"; if the flag is true, we always return an empty set  
instead of looking up the multixact.  (I suppose we could remove the  
argument in the master branch, but I chose not to do so in this commit).  
  
This was broken all along, but the error-facing message appeared first  
because of commit 8e9a16ab8f7f and was partially fixed in a25c2b7c4db3.  
This fix, backpatched all the way back to 9.3, goes approximately in the  
same direction as a25c2b7c4db3 but should cover all cases.  
  
Bug analysis by Andrew Gierth and Álvaro Herrera.  
  
A number of public reports match this bug:  
  https://www.postgresql.org/message-id/20140330040029.GY4582@tamriel.snowman.net  
  https://www.postgresql.org/message-id/538F3D70.6080902@publicrelay.com  
  https://www.postgresql.org/message-id/556439CF.7070109@pscs.co.uk  
  https://www.postgresql.org/message-id/SG2PR06MB0760098A111C88E31BD4D96FB3540@SG2PR06MB0760.apcprd06.prod.outlook.com  
  https://www.postgresql.org/message-id/20160615203829.5798.4594@wrigleys.postgresql.org  
  

Fix building of large (bigger than shared_buffers) hash indexes.

  
commit   : 8cf739de850f596777be14aeb430359cf59cf47c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Jun 2016 16:57:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Jun 2016 16:57:36 -0400    

Click here for diff

  
When the index is predicted to need more than NBuffers buckets,  
CREATE INDEX attempts to sort the index entries by hash key before  
insertion, so as to reduce thrashing.  This code path got broken by  
commit 9f03ca915196dfc8, which overlooked that _hash_form_tuple() is not  
just an alias for index_form_tuple().  The index got built anyway, but  
with garbage data, so that searches for pre-existing tuples always  
failed.  Fix by refactoring to separate construction of the indexable  
data from calling index_form_tuple().  
  
Per bug #14210 from Daniel Newman.  Back-patch to 9.5 where the  
bug was introduced.  
  
Report: <20160623162507.17237.39471@wrigleys.postgresql.org>  
  

postgres_fdw: Fix incorrect NULL handling in join pushdown.

  
commit   : 9e9c38e15947f4f3ed478f8b70e74b55e31fe950    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Jun 2016 15:06:19 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Jun 2016 15:06:19 -0400    

Click here for diff

  
something.* IS NOT NULL means that every attribute of the row is not  
NULL, not that the row itself is non-NULL (e.g. because it's coming  
from below an outer join.  Use (somevar.*)::pg_catalog.text IS NOT  
NULL instead.  
  
Ashutosh Bapat, per a report by Rushabh Lathia.  Reviewed by  
Amit Langote and Etsuro Fujita.  Schema-qualification added by me.  
  

postgres_fdw: Remove useless return statement.

  
commit   : 267569b24c1782b756cad46ffc8e9b28988e7385    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Jun 2016 14:32:11 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Jun 2016 14:32:11 -0400    

Click here for diff

  
Etsuro Fujita  
  

psql: Improve \crosstabview error messages

  
commit   : bd406af16841384b100c783a5cb36923eec6df6d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 24 Jun 2016 01:08:08 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 24 Jun 2016 01:08:08 -0400    

Click here for diff

  
  

Add tab completion for pager_min_lines to psql.

  
commit   : 562e44972490196884452e632a0a6d0db81b2335    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 23 Jun 2016 16:10:15 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 23 Jun 2016 16:10:15 -0400    

Click here for diff

  
This was inadvertantly omitted from commit  
7655f4ccea570d57c4d473cd66b755c03c904942. Mea culpa.  
  
Backpatched to 9.5 where pager_min_lines was introduced.  
  

Fix small memory leak in partial-aggregate deserialization functions.

  
commit   : bd1693e89e7e6c458d0563f6cc67a7c99a45251a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Jun 2016 10:55:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Jun 2016 10:55:59 -0400    

Click here for diff

  
A deserialize function's result is short-lived data during partial  
aggregation, since we're just going to pass it to the combine function  
and then it's of no use anymore.  However, the built-in deserialize  
functions allocated their results in the aggregate state context,  
resulting in a query-lifespan memory leak.  It's probably not possible for  
this to amount to anything much at present, since the number of leaked  
results would only be the number of worker processes.  But it might become  
a problem in future.  To fix, don't use the same convenience subroutine for  
setting up results that the aggregate transition functions use.  
  
David Rowley  
  
Report: <10050.1466637736@sss.pgh.pa.us>  
  

Improve user-facing documentation for partial/parallel aggregation.

  
commit   : 2d673424faf3e33c5fcca926fbe3f21e16dd0fef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2016 19:14:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2016 19:14:16 -0400    

Click here for diff

  
Add a section to xaggr.sgml, as we have done in the past for other  
extensions to the aggregation functionality.  Assorted wordsmithing  
and other minor improvements.  
  
David Rowley and Tom Lane  
  

Update oidjoins regression test for 9.6.

  
commit   : 63ae052367c350935c3cec3e3c53a1e34a317e96    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2016 17:12:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2016 17:12:55 -0400    

Click here for diff

  
Looks like we had some more catalog drift recently.  
  

Fix type-safety problem with parallel aggregate serial/deserialization.

  
commit   : f8ace5477ef9731ef605f58d313c4cd1548f12d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2016 16:52:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2016 16:52:41 -0400    

Click here for diff

  
The original specification for this called for the deserialization function  
to have signature "deserialize(serialtype) returns transtype", which is a  
security violation if transtype is INTERNAL (which it always would be in  
practice) and serialtype is not (which ditto).  The patch blithely overrode  
the opr_sanity check for that, which was sloppy-enough work in itself,  
but the indisputable reason this cannot be allowed to stand is that CREATE  
FUNCTION will reject such a signature and thus it'd be impossible for  
extensions to create parallelizable aggregates.  
  
The minimum fix to make the signature type-safe is to add a second, dummy  
argument of type INTERNAL.  But to lock it down a bit more and make misuse  
of INTERNAL-accepting functions less likely, let's get rid of the ability  
to specify a "serialtype" for an aggregate and just say that the only  
useful serialtype is BYTEA --- which, in practice, is the only interesting  
value anyway, due to the usefulness of the send/recv infrastructure for  
this purpose.  That means we only have to allow "serialize(internal)  
returns bytea" and "deserialize(bytea, internal) returns internal" as  
the signatures for these support functions.  
  
In passing fix bogus signature of int4_avg_combine, which I found thanks  
to adding an opr_sanity check on combinefunc signatures.  
  
catversion bump due to removing pg_aggregate.aggserialtype and adjusting  
signatures of assorted built-in functions.  
  
David Rowley and Tom Lane  
  
Discussion: <27247.1466185504@sss.pgh.pa.us>  
  

Make “postgres -C guc” print “” not “(null)” for null-valued GUCs.

  
commit   : e45e990e4b547f05bdb46e4596d24abbaef60043    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2016 11:55:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2016 11:55:18 -0400    

Click here for diff

  
Commit 0b0baf262 et al made this case print "(null)" on the grounds that  
that's what happened on platforms that didn't crash.  But neither behavior  
was actually intentional.  What we should print is just an empty string,  
for compatibility with the behavior of SHOW and other ways of examining  
string GUCs.  Those code paths don't distinguish NULL from empty strings,  
so we should not here either.  Per gripe from Alain Radix.  
  
Like the previous patch, back-patch to 9.2 where -C option was introduced.  
  
Discussion: <CA+YdpwxPUADrmxSD7+Td=uOshMB1KkDN7G7cf+FGmNjjxMhjbw@mail.gmail.com>  
  

Improve cleanup in rolenames test

  
commit   : 6a9c51810f1db08de4033cbecd95a83d7b364fd1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 21 Jun 2016 21:52:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 21 Jun 2016 21:52:35 -0400    

Click here for diff

  
Drop test_schema at the end, because that otherwise interferes with the  
collate.linux.utf8 test.  
  

Update comment about allowing GUCs to change scanning.

  
commit   : 3e9df858f0de5f1a37c71f24373caf8c870f6993    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 21 Jun 2016 20:23:20 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 21 Jun 2016 20:23:20 -0400    

Click here for diff

  
Reported-by: David G. Johnston  
  
Discussion: CAKFQuwZZvnxwSq9tNtvL+uyuDKGgV91zR_agtPxQHRWMWQRP8g@mail.gmail.com  
  

Document that dependency tracking doesn’t consider function bodies.

  
commit   : 342921078a76a34fd2f44f121f225126778eb2cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jun 2016 20:07:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jun 2016 20:07:58 -0400    

Click here for diff

  
If there's anyplace in our SGML docs that explains this behavior, I can't  
find it right at the moment.  Add an explanation in "Dependency Tracking"  
which seems like the authoritative place for such a discussion.  Per  
gripe from Michelle Schwan.  
  
While at it, update this section's example of a dependency-related  
error message: they last looked like that in 8.3.  And remove the  
explanation of dependency updates from pre-7.3 installations, which  
is probably no longer worth anybody's brain cells to read.  
  
The bogus error message example seems like an actual documentation bug,  
so back-patch to all supported branches.  
  
Discussion: <20160620160047.5792.49827@wrigleys.postgresql.org>  
  

Refactor planning of projection steps that don’t need a Result plan node.

  
commit   : 8b9d323cb9810109e3e5aab1ead427cbbb7aa77e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jun 2016 18:38:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jun 2016 18:38:20 -0400    

Click here for diff

  
The original upper-planner-pathification design (commit 3fc6e2d7f5b652b4)  
assumed that we could always determine during Path formation whether or not  
we would need a Result plan node to perform projection of a targetlist.  
That turns out not to work very well, though, because createplan.c still  
has some responsibilities for choosing the specific target list associated  
with sorting/grouping nodes (in particular it might choose to add resjunk  
columns for sorting).  We might not ever refactor that --- doing so would  
push more work into Path formation, which isn't attractive --- and we  
certainly won't do so for 9.6.  So, while create_projection_path and  
apply_projection_to_path can tell for sure what will happen if the subpath  
is projection-capable, they can't tell for sure when it isn't.  This is at  
least a latent bug in apply_projection_to_path, which might think it can  
apply a target to a non-projecting node when the node will end up computing  
something different.  
  
Also, I'd tied the creation of a ProjectionPath node to whether or not a  
Result is needed, but it turns out that we sometimes need a ProjectionPath  
node anyway to avoid modifying a possibly-shared subpath node.  Callers had  
to use create_projection_path for such cases, and we added code to them  
that knew about the potential omission of a Result node and attempted to  
adjust the cost estimates for that.  That was uncertainly correct and  
definitely ugly/unmaintainable.  
  
To fix, have create_projection_path explicitly check whether a Result  
is needed and adjust its cost estimate accordingly, though it creates  
a ProjectionPath in either case.  apply_projection_to_path is now mostly  
just an optimized version that can avoid creating an extra Path node when  
the input is known to not be shared with any other live path.  (There  
is one case that create_projection_path doesn't handle, which is pushing  
parallel-safe expressions below a Gather node.  We could make it do that  
by duplicating the GatherPath, but there seems no need as yet.)  
  
create_projection_plan still has to recheck the tlist-match condition,  
which means that if the matching situation does get changed by createplan.c  
then we'll have made a slightly incorrect cost estimate.  But there seems  
no help for that in the near term, and I doubt it occurs often enough,  
let alone would change planning decisions often enough, to be worth  
stressing about.  
  
I added a "dummypp" field to ProjectionPath to track whether  
create_projection_path thinks a Result is needed.  This is not really  
necessary as-committed because create_projection_plan doesn't look at the  
flag; but it seems like a good idea to remember what we thought when  
forming the cost estimate, if only for debugging purposes.  
  
In passing, get rid of the target_parallel parameter added to  
apply_projection_to_path by commit 54f5c5150.  I don't think that's a good  
idea because it involves callers in what should be an internal decision,  
and opens us up to missing optimization opportunities if callers think they  
don't need to provide a valid flag, as most don't.  For the moment, this  
just costs us an extra has_parallel_hazard call when planning a Gather.  
If that starts to look expensive, I think a better solution would be to  
teach PathTarget to carry/cache knowledge of parallel-safety of its  
contents.  
  

Stamp 9.6beta2.

  
commit   : 936b62ddf247c26e8cc4fca34bd8a4c2e65c09fd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jun 2016 16:23:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jun 2016 16:23:47 -0400    

Click here for diff

  
  

Add missing check for malloc failure in plpgsql_extra_checks_check_hook().

  
commit   : 1fe1204e87c467221277d1789f1a530a27e15bd2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jun 2016 15:36:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jun 2016 15:36:54 -0400    

Click here for diff

  
Per report from Andreas Seltenreich.  Back-patch to affected versions.  
  
Report: <874m8nn0hv.fsf@elite.ansel.ydns.eu>  
  

pg_trgm’s set_limit() function is parallel unsafe, not parallel restricted.

  
commit   : e611515dd6b8edad56baa0f3ae31ff637ca54d52    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jun 2016 11:29:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jun 2016 11:29:47 -0400    

Click here for diff

  
Per buildfarm.  Fortunately, it's not quite too late to squeeze this fix  
into the pg_trgm 1.3 update.  
  

docs: clarify use of pg_rewind arguments

  
commit   : 3557b1791b715c6e44e1b7b4b342d1fae54e262e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 20 Jun 2016 11:09:21 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 20 Jun 2016 11:09:21 -0400    

Click here for diff

  
Specifically, --source-pgdata and --source-server.  
  
Discussion: 20160617155108.GC19359@momjian.us  
  
Reviewed-by: Michael Paquier  
  

Fix comparison of similarity to threshold in GIST trigram searches.

  
commit   : 9c852566a3cf4ede40e22e4ca216d12cd4a27117    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jun 2016 10:49:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jun 2016 10:49:19 -0400    

Click here for diff

  
There was some very strange code here, dating to commit b525bf77, that  
purported to work around an ancient gcc bug by forcing a float4 comparison  
to be done as int instead.  Commit 5871b8848 broke that when it changed  
one side of the comparison to "double" but left the comparison code alone.  
Commit f576b17cd doubled down on the weirdness by introducing a "volatile"  
marker, which had nothing to do with the actual problem.  
  
Guess that the gcc bug, even if it's still present in the wild, was  
triggered by comparison of float4's and can be avoided if we store the  
result of cnt_sml() into a double before comparing to the double "nlimit".  
This will at least work correctly on non-broken compilers, and it's way  
more readable.  
  
Per bug #14202 from Greg Navis.  Add a regression test based on his  
example.  
  
Report: <20160620115321.5792.10766@wrigleys.postgresql.org>  
  

Translation updates

  
commit   : 47981a4665dfc9c3808366dff9971daedba32e98    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 20 Jun 2016 09:48:08 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 20 Jun 2016 09:48:08 -0400    

Click here for diff

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

Add missing documentation of pg_roles.rolbypassrls

  
commit   : 4d48adc2b8c9724973334345e2ab8f3e6737ac34    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 20 Jun 2016 10:29:20 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 20 Jun 2016 10:29:20 +0200    

Click here for diff

  
Noted by Lukas Fittl  
  

Docs: improve description of psql’s %R prompt escape sequence.

  
commit   : 705ad7f3b523acae0ddfdebd270b7048b2bb8029    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jun 2016 13:11:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jun 2016 13:11:40 -0400    

Click here for diff

  
Dilian Palauzov pointed out in bug #14201 that the docs failed to mention  
the possibility of %R producing '(' due to an unmatched parenthesis.  
  
He proposed just adding that in the same style as the other options were  
listed; but it seemed to me that the sentence was already nearly  
unintelligible, so I rewrote it a bit more extensively.  
  
Report: <20160619121113.5789.68274@wrigleys.postgresql.org>  
  

Improve error message annotation for GRANT/REVOKE on untrusted PLs.

  
commit   : 9bc3332372f9992875d80f856fd98999e070fe35    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jun 2016 19:38:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jun 2016 19:38:59 -0400    

Click here for diff

  
The annotation for "ERROR: language "foo" is not trusted" used to say  
"HINT: Only superusers can use untrusted languages", which was fairly  
poorly thought out.  For one thing, it's not a hint about what to do,  
but a statement of fact, which makes it errdetail.  But also, this  
fails to clarify things much, because there's a missing step in the  
chain of reasoning.  I think it's more useful to say "GRANT and REVOKE  
are not allowed on untrusted languages, because only superusers can use  
untrusted languages".  
  
It's been like this for a long time, but given the lack of previous  
complaints, I don't think this is worth back-patching.  
  
Discussion: <1417.1466289901@sss.pgh.pa.us>  
  

Update 9.6 release notes through today.

  
commit   : a3f42e85464c4e6ed87a74d8903923e2bd734e0c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jun 2016 18:05:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jun 2016 18:05:27 -0400    

Click here for diff

  
  

Restore foreign-key-aware estimation of join relation sizes.

  
commit   : 100340e2dcd05d6505082a8fe343fb2ef2fa5b2a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jun 2016 15:22:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jun 2016 15:22:34 -0400    

Click here for diff

  
This patch provides a new implementation of the logic added by commit  
137805f89 and later removed by 77ba61080.  It differs from the original  
primarily in expending much less effort per joinrel in large queries,  
which it accomplishes by doing most of the matching work once per query not  
once per joinrel.  Hopefully, it's also less buggy and better commented.  
The never-documented enable_fkey_estimates GUC remains gone.  
  
There remains work to be done to make the selectivity estimates account  
for nulls in FK referencing columns; but that was true of the original  
patch as well.  We may be able to address this point later in beta.  
In the meantime, any error should be in the direction of overestimating  
rather than underestimating joinrel sizes, which seems like the direction  
we want to err in.  
  
Tomas Vondra and Tom Lane  
  
Discussion: <31041.1465069446@sss.pgh.pa.us>  
  

Still another try at fixing scanjoin_target insertion into parallel plans.

  
commit   : 598aa194af2fb7f294ae4b029494a134a44be333    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jun 2016 00:28:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jun 2016 00:28:51 -0400    

Click here for diff

  
The previous code neglected the fact that the scanjoin_target might  
carry sortgroupref labelings that we need to absorb.  Instead, do  
create_projection_path() unconditionally, and tweak the path's cost  
estimate after the fact.  (I'm now convinced that we ought to refactor  
the way we account for sometimes not needing a separate projection step,  
but right now is not the time for that sort of cleanup.)  
  
Problem identified by Amit Kapila, patch by me.  
  

  
commit   : 7e81a18d49f2ffc3397bde2660b255b56d8a6d77    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jun 2016 23:08:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jun 2016 23:08:21 -0400    

Click here for diff

  
As shown by buildfarm reports, dblink_build_sql_insert and  
dblink_build_sql_update are *not* parallel safe, because they  
may attempt to access temporary tables of the local session.  
  
Although dblink_build_sql_delete doesn't actually touch the  
contents of the referenced table, it seems consistent and prudent  
to mark it PARALLEL RESTRICTED too.  
  

Fix handling of argument and result datatypes for partial aggregation.

  
commit   : 915b703e169c38573591e69ae3939a7bf25e90d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jun 2016 21:44:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jun 2016 21:44:37 -0400    

Click here for diff

  
When doing partial aggregation, the args list of the upper (combining)  
Aggref node is replaced by a Var representing the output of the partial  
aggregation steps, which has either the aggregate's transition data type  
or a serialized representation of that.  However, nodeAgg.c blindly  
continued to use the args list as an indication of the user-level argument  
types.  This broke resolution of polymorphic transition datatypes at  
executor startup (though it accidentally failed to fail for the ANYARRAY  
case, which is likely the only one anyone had tested).  Moreover, the  
constructed FuncExpr passed to the finalfunc contained completely wrong  
information, which would have led to bogus answers or crashes for any case  
where the finalfunc examined that information (which is only likely to be  
with polymorphic aggregates using a non-polymorphic transition type).  
  
As an independent bug, apply_partialaggref_adjustment neglected to resolve  
a polymorphic transition datatype before assigning it as the output type  
of the lower-level Aggref node.  This again accidentally failed to fail  
for ANYARRAY but would be unlikely to work in other cases.  
  
To fix the first problem, record the user-level argument types in a  
separate OID-list field of Aggref, and look to that rather than the args  
list when asking what the argument types were.  (It turns out to be  
convenient to include any "direct" arguments in this list too, although  
those are not currently subject to being overwritten.)  
  
Rather than adding yet another resolve_aggregate_transtype() call to fix  
the second problem, add an aggtranstype field to Aggref, and store the  
resolved transition type OID there when the planner first computes it.  
(By doing this in the planner and not the parser, we can allow the  
aggregate's transition type to change from time to time, although no DDL  
support yet exists for that.)  This saves nothing of consequence for  
simple non-polymorphic aggregates, but for polymorphic transition types  
we save a catalog lookup during executor startup as well as several  
planner lookups that are new in 9.6 due to parallel query planning.  
  
In passing, fix an error that was introduced into count_agg_clauses_walker  
some time ago: it was applying exprTypmod() to something that wasn't an  
expression node at all, but a TargetEntry.  exprTypmod silently returned  
-1 so that there was not an obvious failure, but this broke the intended  
sensitivity of aggregate space consumption estimates to the typmod of  
varchar and similar data types.  This part needs to be back-patched.  
  
Catversion bump due to change of stored Aggref nodes.  
  
Discussion: <8229.1466109074@sss.pgh.pa.us>  
  

Docs typo fix.

  
commit   : d30d1acf904b823a7cca59e5d403ae3b299773e9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jun 2016 18:23:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jun 2016 18:23:39 -0400    

Click here for diff

  
Guillaume Lelarge  
  

Finish up XLOG_HINT renaming

  
commit   : 1ca4a1b5d2c633d33161792af1c70e397f879ed9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 17 Jun 2016 18:05:55 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 17 Jun 2016 18:05:55 -0400    

Click here for diff

  
Commit b8fd1a09f3 renamed XLOG_HINT to XLOG_FPI, but neglected two  
places.  
  
Backpatch to 9.3, like that commit.  
  

pg_visibility: Add pg_truncate_visibility_map function.

  
commit   : 71d05a2c7b82379bb1013a0e338906349c54ed85    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 17:37:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 17:37:30 -0400    

Click here for diff

  
This requires some core changes as well so that we can properly  
WAL-log the truncation.  Specifically, it changes the format of the  
XLOG_SMGR_TRUNCATE WAL record, so bump XLOG_PAGE_MAGIC.  
  
Patch by me, reviewed but not fully endorsed by Andres Freund.  
  

Try again to fix the way the scanjoin_target is used with partial paths.

  
commit   : 54f5c5150fa05d7ad15f8406debd5a2b394885b5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 16:25:02 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 16:25:02 -0400    

Click here for diff

  
Commit 04ae11f62e643e07c411c4935ea6af46cb112aa9 removed some broken  
code to apply the scan/join target to partial paths, but its theory  
that this processing step is totally unnecessary turns out to be wrong.  
Put similar code back again, but this time, check for parallel-safety  
and avoid in-place modifications to paths that may already have been  
used as part of some other path.  
  
(This is not an entirely elegant solution to this problem; it might  
be better, for example, to postpone generate_gather_paths for the  
topmost scan/join rel until after the scan/join target has been  
applied.  But this is not the time for such redesign work.)  
  
Amit Kapila and Robert Haas  
  

Add VACUUM (DISABLE_PAGE_SKIPPING) for emergencies.

  
commit   : ede62e56fbe809baa1a7bc3873d82f12ffe7540b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 15:48:57 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 15:48:57 -0400    

Click here for diff

  
If you really want to vacuum every single page in the relation,  
regardless of apparent visibility status or anything else, you can use  
this option.  In previous releases, this behavior could be achieved  
using VACUUM (FREEZE), but because we can now recognize all-frozen  
pages as not needing to be frozen again, that no longer works.  There  
should be no need for routine use of this option, but maybe bugs or  
disaster recovery will necessitate its use.  
  
Patch by me, reviewed by Andres Freund.  
  

  
commit   : 20eb2731b7775f3381939d2667b6aa8ba62ab2c5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 15:09:57 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 15:09:57 -0400    

Click here for diff

  
Almost all functions provided by this extension are PARALLEL  
RESTRICTED.  Mostly, that's because the leader's TCP connections won't  
be shared with the workers, but in some cases like dblink_get_pkey  
it's because they obtain locks which might be released early if taken  
within a parallel worker.  dblink_fdw_validator probably can't be used  
in a query anyway, but there would be no problem from the point of  
view of parallel query if it were, so it's PARALLEL SAFE.  
  
Andreas Karlsson  
  

postgres_fdw: Rephrase comment.

  
commit   : 177c56d608d834ee1b0869e4e6a5b73de4227ea4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 13:01:14 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 13:01:14 -0400    

Click here for diff

  
Per gripe from Thomas Munro, who only complained about a more  
localized problem, but I couldn't resist a bit more wordsmithing.  
  

Fix typo.

  
commit   : 9c188a8454e514e43614e47d69f5eaea820af8c4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 12:55:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 12:55:30 -0400    

Click here for diff

  
Thomas Munro  
  

Remove PID from ‘parallel worker’ context message.

  
commit   : 292794f82b4ebde33ec7f2a572ddd1dedba8ce37    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 09:24:29 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 09:24:29 -0400    

Click here for diff

  
Discussion: <bfd204ab-ab1a-792a-b345-0274a09a4b5f@2ndquadrant.com>  
  

Attempt to fix broken regression test.

  
commit   : 103512cee95b5bd0feb83c225eeff61c58874413    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 08:35:47 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2016 08:35:47 -0400    

Click here for diff

  
In commit 8c1d9d56e9a00680a035b8b333a98ea16b121eb7, I attempted to  
add a regression test that would fail if the target list was pushed  
into a parallel worker, but due to brain fade on my part, it just  
randomly fails whether anything bad or not, because the error check  
inside the parallel_restricted() function tests whether there is  
*any process in the system* that is not connected to a client, not  
whether the process running the query is not connected to a client.  
  
A little experimentation has left me pessimistic about the  
prospects of doing better here in a short amount of time, so let's  
just fall back to checking that the plan is as we expect and leave  
the execution-time check for another day.  
  

Fix validation of overly-long IPv6 addresses.

  
commit   : 4c56f3269a84a81461cc53941e0eee02fc920ab6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jun 2016 17:16:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jun 2016 17:16:32 -0400    

Click here for diff

  
The inet/cidr types sometimes failed to reject IPv6 inputs with too many  
colon-separated fields, instead translating them to '::/0'.  This is the  
result of a thinko in the original ISC code that seems to be as yet  
unreported elsewhere.  Per bug #14198 from Stefan Kaltenbrunner.  
  
Report: <20160616182222.5798.959@wrigleys.postgresql.org>  
  

Fix fuzzy thinking in ReinitializeParallelDSM().

  
commit   : bfb937427be2cfca78e3e076c30e37cddc350f8e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jun 2016 15:20:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jun 2016 15:20:29 -0400    

Click here for diff

  
The fact that no workers were successfully launched in the previous  
iteration does not excuse us from setting up properly to try again.  
This appears to explain crashes I saw in parallel regression testing  
due to error_mqh being NULL when it shouldn't be.  
  
Minor other cosmetic fixes too.  
  

Invent min_parallel_relation_size GUC to replace a hard-wired constant.

  
commit   : 75be66464cb1bffa1e5757907b9a04ad5afc7859    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jun 2016 13:47:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jun 2016 13:47:20 -0400    

Click here for diff

  
The main point of doing this is to allow the cutoff to be set very small,  
even zero, to allow parallel-query behavior to be tested on relatively  
small tables such as we typically use in the regression tests.  But it  
might be of use to users too.  The number-of-workers scaling behavior in  
create_plain_partial_paths() is pretty ad-hoc and subject to change, so  
we won't expose anything about that, but the notion of not considering  
parallel query at all for tables below size X seems reasonably stable.  
  
Amit Kapila, per a suggestion from me  
  
Discussion: <17170.1465830165@sss.pgh.pa.us>  
  

Reword bogus comment

  
commit   : 3b5a2a8856b810ed354fb6dbb7df8d7325ece82f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 16 Jun 2016 12:43:35 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 16 Jun 2016 12:43:35 -0400    

Click here for diff

  
  

Avoid crash in “postgres -C guc” for a GUC with a null string value.

  
commit   : 0b0baf26211a98a8593279fa24635bc4dd9ac99d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jun 2016 12:17:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jun 2016 12:17:03 -0400    

Click here for diff

  
Emit "(null)" instead, which was the behavior all along on platforms  
that don't crash, eg OS X.  Per report from Jehan-Guillaume de Rorthais.  
Back-patch to 9.2 where -C option was introduced.  
  
Michael Paquier  
  
Report: <20160615204036.2d35d86a@firost>  
  

Remove unused prototype

  
commit   : b000afea6596c4dab2f0595ded751659a158b754    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 16 Jun 2016 12:06:51 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 16 Jun 2016 12:06:51 -0400    

Click here for diff

  
Commit 6f56b41ac0cd7 removed function get_pg_database_relfilenode but left  
its prototype in place.  Remove it.  
  

Add regression test for 04ae11f62e643e07c411c4935ea6af46cb112aa9.

  
commit   : 8c1d9d56e9a00680a035b8b333a98ea16b121eb7    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 16 Jun 2016 12:00:55 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 16 Jun 2016 12:00:55 -0400    

Click here for diff

  
The code in this area needs further revision, and it would be best  
not to re-break the things we've already fixed.  
  
Per a gripe from Tom Lane.  
  

Use strftime(“%c”) to format timestamps in psql’s \watch command.

  
commit   : 9901d8ac2e7326f5a705341d304e7c7f0f95a1e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Jun 2016 19:31:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Jun 2016 19:31:08 -0400    

Click here for diff

  
This allows the timestamps to follow local conventions (in particular,  
they respond to the LC_TIME environment setting).  In C locale you get  
the same results as before.  It seems like a good idea to do this now not  
later because we already changed the format of \watch headers for 9.6.  
  
Also, increase the buffer sizes a tad to ensure there's enough space for  
translated strings.  
  
Discussion: <20160612145532.GA22965@postgresql.kr>  
  

Fix regression test for force_parallel_mode=on.

  
commit   : 12f862099d25fc70b412d56f50dcabebff8db44a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 15 Jun 2016 14:59:07 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 15 Jun 2016 14:59:07 -0400    

Click here for diff

  
Commit 14a254fb52423c57059851abafbd1247261f7f03 managed not to  
exercise the code it was intended to test, and the comment explaining  
why no "parallel worker" line showed up in the context wasn't right.  
  
Amit Kapila, tweaked by me per Amit's analysis.  
  

Add integrity-checking functions to pg_visibility.

  
commit   : e472ce9624e0f2083c8fd25ea1acb081be908f8f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 15 Jun 2016 14:33:58 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 15 Jun 2016 14:33:58 -0400    

Click here for diff

  
The new pg_check_visible() and pg_check_frozen() functions can be used to  
verify that the visibility map bits for a relation's data pages match the  
actual state of the tuples on those pages.  
  
Amit Kapila and Robert Haas, reviewed (in earlier versions) by Andres  
Freund.  Additional testing help by Thomas Munro.  
  

Fix lazy_scan_heap so that it won’t mark pages all-frozen too soon.

  
commit   : 38e9f90a227d1e60e7b4691d1a71fefaba6059e5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 15 Jun 2016 14:23:39 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 15 Jun 2016 14:23:39 -0400    

Click here for diff

  
Commit a892234f830e832110f63fc0a2afce2fb21d1584 added a new bit per  
page to the visibility map fork indicating whether the page is  
all-frozen, but incorrectly assumed that if lazy_scan_heap chose to  
freeze a tuple then that tuple would not need to later be frozen  
again. This turns out to be false, because xmin and xmax (and  
conceivably xvac, if dealing with tuples from very old releases) could  
be frozen at separate times.  
  
Thanks to Andres Freund for help in uncovering and tracking down this  
issue.  
  

Mark some functions parallel-unsafe.

  
commit   : c7a25c242ffa29810adc2b5320ec7542fe2928bd    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 15 Jun 2016 11:40:07 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 15 Jun 2016 11:40:07 -0400    

Click here for diff

  
currtid() and currtid2() call GetLatestSnapshot(), which fails in  
parallel mode.  pg_export_snapshot() calls ExportSnapshot() which  
attempts to assign an XID for the current transaction if it does not  
already have one; that, too, will fail in parallel mode.  
  
Andreas Seltenreich  
  

Force idle_in_transaction_session_timeout off in pg_dump and autovacuum.

  
commit   : 8383486f108c650b187358bfe811060627c751c9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Jun 2016 10:52:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Jun 2016 10:52:53 -0400    

Click here for diff

  
We disable statement_timeout and lock_timeout during dump and restore, to  
prevent any global settings that might exist from breaking routine backups.  
Commit c6dda1f48 should have added idle_in_transaction_session_timeout to  
that list, but failed to.  
  
Another place where these timeouts get turned off is autovacuum.  While  
I doubt an idle timeout could fire there, it seems better to be safe than  
sorry.  
  
pg_dump issue noted by Bernd Helmle, the other one found by grepping.  
  
Report: <352F9B77DB5D3082578D17BB@eje.land.credativ.lan>  
  

PL/Python: Clean up extended error reporting docs and tests

  
commit   : f0688d6e6c595cdceef3ad218b86f064f4909b4c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 15 Jun 2016 10:34:11 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 15 Jun 2016 10:34:11 -0400    

Click here for diff

  
Format the example and test code more to Python style standards.  
Improve whitespace.  Improve documentation formatting.  
  

document when PREPARE uses generic plans

  
commit   : fab9d1da4a213fab08fe2d263eedf2408bc4a27a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jun 2016 16:11:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jun 2016 16:11:46 -0400    

Click here for diff

  
Also explain how generic plans are created.  
Link to PREPARE docs from wire-protocol prepare docs.  
  
Reported-by: Jonathan Rogers  
  
Discussion: https://www.postgresql.org/message-id/flat/561E749D.4090301%40socialserve.com  
  

Update xml2 extension for parallel query.

  
commit   : 13e7453135189a32f9f12c4bebd0cd97a0a5d908    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jun 2016 15:49:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jun 2016 15:49:32 -0400    

Click here for diff

  
All functions provided by this extension are PARALLEL SAFE.  
  
Andreas Karlsson  
  

Update uuid-ossp extension for parallel query.

  
commit   : 20f6c3a2a1eeadbf81c4c6cea35e831dc08ae06b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jun 2016 14:56:21 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jun 2016 14:56:21 -0400    

Click here for diff

  
All functions provided by this extension are PARALLEL SAFE.  
  
Andreas Karlsson  
  

Update unaccent extension for parallel query.

  
commit   : 202ac08c081245a680b371d3e7702a60fad9185c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jun 2016 14:55:49 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jun 2016 14:55:49 -0400    

Click here for diff

  
All functions provided by this extension are PARALLEL SAFE.  
  
Andreas Karlsson  
  

Update sslinfo extension for parallel query.

  
commit   : 6b7d11ffda0b51b70978edcb1659cc62aa477f01    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jun 2016 14:52:55 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jun 2016 14:52:55 -0400    

Click here for diff

  
All functions provided by this extension are PARALLEL RESTRICTED,  
because they provide information about the connection state.  Parallel  
workers don't have this information and therefore these functions  
can't be executed in a worker (but they can be present in a query some  
other part of which uses parallelism).  
  
Andreas Karlsson  
  

Update extensions with GIN/GIST support for parallel query.

  
commit   : 2910fc8239fa501b662c5459d7ba16a4bc35e7e8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jun 2016 13:34:37 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jun 2016 13:34:37 -0400    

Click here for diff

  
Commit 749a787c5b25ae33b3d4da0ef12aa05214aa73c7 bumped the extension  
version on all of these extensions already, and we haven't had a  
release since then, so we can make further changes without bumping the  
extension version again.  Take this opportunity to mark all of the  
functions exported by these modules PARALLEL SAFE -- except for  
pg_trgm's set_limit().  Mark that one PARALLEL RESTRICTED, because it  
makes a persistent change to a GUC value.  
  
Note that some of the markings added by this commit don't have any  
effect; for example, gseg_picksplit() isn't likely to be mentioned  
explicitly in a query and therefore it's parallel-safety marking will  
never be consulted.  But this commit just marks everything for  
consistency: if it were somehow used in a query, that would be fine as  
far as parallel query is concerned, since it does not consult any  
backend-private state, attempt to write data, etc.  
  
Andreas Karlsson, with a few revisions by me.  
  

postgres_fdw: Check PlaceHolderVars before pushing down a join.

  
commit   : 131c7e70b4596027992a2f72bfd3765f0fff1b7c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jun 2016 11:48:27 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jun 2016 11:48:27 -0400    

Click here for diff

  
As discovered by Andreas Seltenreich via sqlsmith, it's possible for a  
remote join to need to generate a target list which contains a  
PlaceHolderVar which would need to be evaluated on the remote server.  
This happens when we try to push down a join tree which contains outer  
joins and the nullable side of the join contains a subquery which  
evauates some expression which can go to NULL above the level of the  
join.  Since the deparsing logic can't build a remote query that  
involves subqueries, it fails while trying to produce an SQL query  
that can be sent to the remote side.  Detect such cases and don't try  
to push down the join at all.  
  
It's actually fine to push down the join if the PlaceHolderVar needs  
to be evaluated at the current join level.  This patch makes a small  
change to build_tlist_to_deparse so that this case will work.  
  
Amit Langote, Ashutosh Bapat, and me.  
  

Minor fixes in contrib installation scripts.

  
commit   : 5484c0a9806b3e90b483128bc386054fc432cb65    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Jun 2016 10:47:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Jun 2016 10:47:06 -0400    

Click here for diff

  
Extension scripts should never use CREATE OR REPLACE for initial object  
creation.  If there is a collision with a pre-existing (probably  
user-created) object, we want extension installation to fail, not silently  
overwrite the user's object.  Bloom and sslinfo both violated this precept.  
  
Also fix a number of scripts that had no standard header (the file name  
comment and the \echo...\quit guard).  Probably the \echo...\quit hack  
is less important now than it was in 9.1 days, but that doesn't mean  
that individual extensions get to choose whether to use it or not.  
  
And fix a couple of evident copy-and-pasteos in file name comments.  
  
No need for back-patch: the REPLACE bugs are both new in 9.6, and the  
rest of this is pretty much cosmetic.  
  
Andreas Karlsson and Tom Lane  
  

postgres_fdw: Promote an Assert() to elog().

  
commit   : 332fdbef20b5b5f2588447793dbcc3bb9b88eb51    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jun 2016 08:55:50 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jun 2016 08:55:50 -0400    

Click here for diff

  
Andreas Seltenreich reports that it is possible for a PlaceHolderVar  
to creep into this tlist, and I fear that even after that's fixed we  
might have other, similar bugs in this area either now or in the  
future.  There's a lot of action-at-a-distance here, because the  
validity of this assertion depends on core planner behavior; so, let's  
use elog() to make sure we catch this even in non-assert builds,  
rather than just crashing.  
  

Fix multiple minor infelicities in aclchk.c error reports.

  
commit   : 783cb6e48b29a34b2cefc401a72d4cc86fa6b2a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jun 2016 13:53:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jun 2016 13:53:10 -0400    

Click here for diff

  
pg_type_aclmask reported the wrong type's OID when complaining that  
it could not find a type's typelem.  It also failed to provide a  
suitable errcode when the initially given OID doesn't exist (which  
is a user-facing error, since that OID can be user-specified).  
pg_foreign_data_wrapper_aclmask and pg_foreign_server_aclmask likewise  
lacked errcode specifications.  Trivial cosmetic adjustments too.  
  
The wrong-type-OID problem was reported by Petru-Florin Mihancea in  
bug #14186; the other issues noted by me while reading the code.  
These errors all seem to be aboriginal in the respective routines, so  
back-patch as necessary.  
  
Report: <20160613163159.5798.52928@wrigleys.postgresql.org>  
  

In planner.c, avoid assuming that all PathTargets have sortgrouprefs.

  
commit   : 89d53515e53ea080029894939118365b647489b3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jun 2016 12:59:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jun 2016 12:59:25 -0400    

Click here for diff

  
The struct definition for PathTarget specifies that a NULL sortgrouprefs  
pointer means no sortgroupref labels.  While it's likely that there  
should always be at least one labeled column in the places that were  
unconditionally fetching through the pointer, it seems wiser to adhere to  
the data structure specification and test first.  Add a macro to make this  
convenient.  Per experimentation with running the regression tests with a  
very small parallelization threshold --- the crash I observed may well  
represent a bug elsewhere, but still this coding was not very robust.  
  
Report: <20756.1465834072@sss.pgh.pa.us>  
  

Remove extraneous leading whitespace in Windows build script.

  
commit   : cd9b4f24ce5f24de5112392d5a9db3a8d4208115    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jun 2016 11:50:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jun 2016 11:50:27 -0400    

Click here for diff

  
Apparently, at least some versions of Microsoft's shell fail on variable  
assignments that have leading whitespace.  This instance, introduced in  
commit 680513ab7, managed to escape notice for awhile because it's only  
invoked if building with OpenSSL.  Per bug #14185 from Torben Dannhauer.  
  
Report: <20160613140119.5798.78501@wrigleys.postgresql.org>  
  

Finish pgindent run for 9.6: Perl files.

  
commit   : 3be0a62ffe58f0753d190cbe22acbeb8b4926b85    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Jun 2016 04:19:56 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Jun 2016 04:19:56 -0400    

Click here for diff

  
  

Document the authoritative version of perltidy.

  
commit   : b098abf90537edf0ce9c70e8eb55320baf6e445d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Jun 2016 04:19:44 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Jun 2016 04:19:44 -0400    

Click here for diff

  
Every whole-tree perltidy run has used this version, firmly establishing  
it as the de facto standard.  
  

PL/Python: Rename new keyword arguments of plpy.error() etc.

  
commit   : 020140d84d09e0375824074cead642e3b9435180    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 11 Jun 2016 19:27:49 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 11 Jun 2016 19:27:49 -0400    

Click here for diff

  
Rename schema -> schema_name etc. to remain consistent with C API and  
PL/pgSQL.  
  

Change default of backend_flush_after GUC to 0 (disabled).

  
commit   : 4bc0f165cb4fbd660648c0153485b3d6f55d80ea    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 10 Jun 2016 15:31:11 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 10 Jun 2016 15:31:11 -0700    

Click here for diff

  
While beneficial, both for throughput and average/worst case latency, in  
a significant number of workloads, there are other workloads in which  
backend_flush_after can cause significant performance regressions in  
comparison to < 9.6 releases. The regression is most likely when the hot  
data set is bigger than shared buffers, but significantly smaller than  
the operating system's page cache.  
  
I personally think that the benefit of enabling backend flush control is  
considerably bigger than the potential downsides, but a fair argument  
can be made that not regressing is more important than improving  
performance/latency. As the latter is the consensus, change the default  
to 0.  
  
The other settings introduced in 428b1d6b2 do not have the same  
potential for regressions, so leave them enabled.  
  
Benchmarks leading up to changing the default have been performed by  
Mithun Cy, Ashutosh Sharma and Robert Haas.  
  
Discussion: CAD__OuhPmc6XH=wYRm_+Q657yQE88DakN4=Ybh2oveFasHkoeA@mail.gmail.com  
  

Remove reltarget_has_non_vars flag.

  
commit   : 3303ea1a327b41d3b406d7be7a5ce2901e561066    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Jun 2016 16:20:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Jun 2016 16:20:03 -0400    

Click here for diff

  
Commit b12fd41c6 added a "reltarget_has_non_vars" field to RelOptInfo,  
but failed to maintain it accurately.  Since its only purpose was to skip  
calls to has_parallel_hazard() in the simple case where a rel's targetlist  
is all Vars, and that call is really pretty cheap in that case anyway, it  
seems like this is just a case of premature optimization.  Let's drop the  
flag and do the calls unconditionally until it's proven that we need more  
smarts here.  
  

Refactor to reduce code duplication for function property checking.

  
commit   : 2f153ddfdd318b211590dd5585f65f357d85c2de    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Jun 2016 16:03:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Jun 2016 16:03:37 -0400    

Click here for diff

  
As noted by Andres Freund, we'd accumulated quite a few similar functions  
in clauses.c that examine all functions in an expression tree to see if  
they satisfy some boolean test.  Reduce the duplication by inventing a  
function check_functions_in_node() that applies a simple callback function  
to each SQL function OID appearing in a given expression node.  This also  
fixes some arguable oversights; for example, contain_mutable_functions()  
did not check aggregate or window functions for mutability.  I doubt that  
that represents a live bug at the moment, because we don't really consider  
mutability for aggregates; but it might someday be one.  
  
I chose to put check_functions_in_node() in nodeFuncs.c because it seemed  
like other modules might wish to use it in future.  That in turn forced  
moving set_opfuncid() et al into nodeFuncs.c, as the alternative was for  
nodeFuncs.c to depend on optimizer/setrefs.c which didn't seem very clean.  
  
In passing, teach contain_leaked_vars_walker() about a few more expression  
node types it can safely look through, and improve the rather messy and  
undercommented code in has_parallel_hazard_walker().  
  
Discussion: <20160527185853.ziol2os2zskahl7v@alap3.anarazel.de>  
  

Rename local variable for consistency.

  
commit   : 13761bccb177022c8c0dabc08f3e9acb491b1c96    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 10 Jun 2016 11:24:01 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 10 Jun 2016 11:24:01 -0500    

Click here for diff

  
Pointed out by Robert Haas.  
  

Update pgstattuple extension for parallel query.

  
commit   : a8501ba11931f84c07e014070902d8198fa7dfd9    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 10 Jun 2016 10:42:03 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 10 Jun 2016 10:42:03 -0400    

Click here for diff

  
All functions provided by this extension are PARALLEL SAFE.  
  
Andreas Karlsson  
  

Update pg_stat_statements extension for parallel query.

  
commit   : 496899ccc2fd1b84bd1a8c8b3a7f0c667e5329f0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 10 Jun 2016 10:42:01 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 10 Jun 2016 10:42:01 -0400    

Click here for diff

  
All functions provided by this extension are PARALLEL SAFE.  Given the  
general prohibition against write operations in parallel queries, it is  
perhaps a bit surprising that pg_stat_statements_reset() is parallel safe.  
But since it only modifies shared memory, not the database, it's OK.  
  
Andreas Karlsson  
  

Schema-qualify some references to regprocedure.

  
commit   : 3d8fc8c68c063d52ca678e569f0ecd9385f846e6    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 10 Jun 2016 10:41:58 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 10 Jun 2016 10:41:58 -0400    

Click here for diff

  
Andreas Karlsson, per a gripe from Tom Lane.  
  

Fix interaction between CREATE INDEX and “snapshot too old”.

  
commit   : bf9a60ee3349a2f2dc5fe6d571a8d39cfc634371    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 10 Jun 2016 09:25:31 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 10 Jun 2016 09:25:31 -0500    

Click here for diff

  
Since indexes are created without valid LSNs, an index created  
while a snapshot older than old_snapshot_threshold existed could  
cause queries to return incorrect results when those old snapshots  
were used, if any relevant rows had been subject to early pruning  
before the index was built.  Prevent usage of a newly created index  
until all such snapshots are released, for relations where this can  
happen.  
  
Questions about the interaction of "snapshot too old" with index  
creation were initially raised by Andres Freund.  
  
Reviewed by Robert Haas.  
  

Improve the situation for parallel query versus temp relations.

  
commit   : cae1c788b9b43887e4a4fa51a11c3a8ffa334939    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jun 2016 20:16:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jun 2016 20:16:11 -0400    

Click here for diff

  
Transmit the leader's temp-namespace state to workers.  This is important  
because without it, the workers do not really have the same search path  
as the leader.  For example, there is no good reason (and no extant code  
either) to prevent a worker from executing a temp function that the  
leader created previously; but as things stood it would fail to find the  
temp function, and then either fail or execute the wrong function entirely.  
  
We still prohibit a worker from creating a temp namespace on its own.  
In effect, a worker can only see the session's temp namespace if the leader  
had created it before starting the worker, which seems like the right  
semantics.  
  
Also, transmit the leader's BackendId to workers, and arrange for workers  
to use that when determining the physical file path of a temp relation  
belonging to their session.  While the original intent was to prevent such  
accesses entirely, there were a number of holes in that, notably in places  
like dbsize.c which assume they can safely access temp rels of other  
sessions anyway.  We might as well get this right, as a small down payment  
on someday allowing workers to access the leader's temp tables.  (With  
this change, directly using "MyBackendId" as a relation or buffer backend  
ID is deprecated; you should use BackendIdForTempRelations() instead.  
I left a couple of such uses alone though, as they're not going to be  
reachable in parallel workers until we do something about localbuf.c.)  
  
Move the thou-shalt-not-access-thy-leader's-temp-tables prohibition down  
into localbuf.c, which is where it actually matters, instead of having it  
in relation_open().  This amounts to recognizing that access to temp  
tables' catalog entries is perfectly safe in a worker, it's only the data  
in local buffers that is problematic.  
  
Having done all that, we can get rid of the test in has_parallel_hazard()  
that says that use of a temp table's rowtype is unsafe in parallel workers.  
That test was unduly expensive, and if we really did need such a  
prohibition, that was not even close to being a bulletproof guard for it.  
(For example, any user-defined function executed in a parallel worker  
might have attempted such access.)  
  

Repair a bit of pgindent damage.

  
commit   : 2410a2543e77983dab1f63f48b2adcd23dba994e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 18:09:17 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 18:09:17 -0400    

Click here for diff

  
Inserting line-breaks into the middle of a URL is, to put it mildly, not  
very helpful, so persuade pgindent to leave it alone.  
  

pgindent run for 9.6

  
commit   : 4bc424b968058c7f0aa685821d7039e86faac99c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 18:02:36 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 18:02:36 -0400    

Click here for diff

  
  

Update pgrowlocks extension for parallel query.

  
commit   : 9164deea2f4ac90ee5e008ff41fc5ad4423887b2    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 17:18:20 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 17:18:20 -0400    

Click here for diff

  
The pgrowlocks function provided by this extension is PARALLEL SAFE.  
  
Andreas Karlsson  
  

Update pg_prewarm extension for parallel query.

  
commit   : 6b3586caa810529635a8f77789d88e957b389469    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 17:18:18 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 17:18:18 -0400    

Click here for diff

  
The pg_prewarm function provided by this extension is PARALLEL SAFE.  
  
Andreas Karlsson  
  

Update pg_freespacemap extension for parallel query.

  
commit   : 42d4257a069584e205cafcc175f9f6f8d673237c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 17:18:16 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 17:18:16 -0400    

Click here for diff

  
All functions provided by this extension are PARALLEL SAFE.  
  
Andreas Karlsson  
  

Update pgcrypto extension for parallel query.

  
commit   : 0dbf3ce0e0c0bac2eb84eec70bcd3d728abd5a8c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 17:18:14 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 17:18:14 -0400    

Click here for diff

  
All functions provided by this extension are PARALLEL SAFE.  
  
Andreas Karlsson  
  

Update pg_buffercache extension for parallel query.

  
commit   : 06d7fd6e2975db3273b14116a471f71fef9e0102    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 17:18:12 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 17:18:12 -0400    

Click here for diff

  
The pg_buffercache_pages function provided by this extension is  
PARALLEL SAFE.  
  
Andreas Karlsson  
  

Update pageinspect extension for parallel query.

  
commit   : e3b607cd7a949958bdccb056b5c3cb2389f588ad    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 17:18:09 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 17:18:09 -0400    

Click here for diff

  
All functions provided by this extension are PARALLEL SAFE.  
  
Andreas Karlsson  
  

Handle contrib’s GIN/GIST support function signature changes honestly.

  
commit   : 749a787c5b25ae33b3d4da0ef12aa05214aa73c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jun 2016 16:44:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jun 2016 16:44:25 -0400    

Click here for diff

  
In commits 9ff60273e35cad6e and dbe2328959e12701 I (tgl) fixed the  
signatures of a bunch of contrib's GIN and GIST support functions so that  
they would pass validation by the recently-added amvalidate functions.  
The backend does not actually consult or check those signatures otherwise,  
so I figured this was basically cosmetic and did not require an extension  
version bump.  However, Alexander Korotkov pointed out that that would  
leave us in a pretty messy situation if we ever wanted to redefine those  
functions later, because there wouldn't be a unique way to name them.  
Since we're going to be bumping these extensions' versions anyway for  
parallel-query cleanups, let's take care of this now.  
  
Andreas Karlsson, adjusted for more search-path-safety by me  
  

Don’t generate parallel paths for rels with parallel-restricted outputs.

  
commit   : b12fd41c695b43c76b0a9a4d19ba43b05536440c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 12:40:23 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 12:40:23 -0400    

Click here for diff

  
Such paths are unsafe.  To make it cheaper to detect when this case  
applies, track whether a relation's default PathTarget contains any  
non-Vars.  In most cases, the answer will be no, which enables us to  
determine cheaply that the target list for a proposed path is  
parallel-safe.  However, subquery pull-up can create cases that  
require us to inspect the target list more carefully.  
  
Amit Kapila, reviewed by me.  
  

Yet again update typedefs.list file in preparation for pgindent run

  
commit   : e7bcd983f56136a9580076b60d5c19eb2fd83301    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 12:15:33 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 12:15:33 -0400    

Click here for diff

  
Because the run was delayed, the file had a chance to get out of date.  
  

Clarify documentation of ceil/ceiling/floor functions.

  
commit   : 7feb60c1bb0b1e9c97561171e9194d56694620ad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jun 2016 11:58:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jun 2016 11:58:00 -0400    

Click here for diff

  
Document these as "nearest integer >= argument" and "nearest integer <=  
argument", which will hopefully be less confusing than the old formulation.  
New wording is from Matlab via Dean Rasheed.  
  
I changed the pg_description entries as well as the SGML docs.  In the  
back branches, this will only affect installations initdb'd in the future,  
but it should be harmless otherwise.  
  
Discussion: <CAEZATCW3yzJo-NMSiQs5jXNFbTsCEftZS-Og8=FvFdiU+kYuSA@mail.gmail.com>  
  

Mop-up for parallel degree-ectomy.

  
commit   : e4158319f34ceb2c760761dc93d262513235c344    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jun 2016 11:16:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jun 2016 11:16:26 -0400    

Click here for diff

  
Fix a couple of overlooked uses of "degree" terminology.  Make the parallel  
worker count selection logic in create_plain_partial_paths more robust (in  
particular, it failed with max_parallel_workers_per_gather set to zero).  
  

Eliminate “parallel degree” terminology.

  
commit   : c9ce4a1c61ebf39c03885cc19fe7c32edc04a300    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 09:08:27 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jun 2016 09:08:27 -0400    

Click here for diff

  
This terminology provoked widespread complaints.  So, instead, rename  
the GUC max_parallel_degree to max_parallel_workers_per_gather  
(leaving room for a possible future GUC max_parallel_workers that acts  
as a system-wide limit), and rename the parallel_degree reloption to  
parallel_workers.  Rename structure members to match.  
  
These changes create a dump/restore hazard for users of PostgreSQL  
9.6beta1 who have set the reloption (or applied the GUC using ALTER  
USER or ALTER DATABASE).  
  

  
commit   : 6581e930a8546a764e948ad429fc2e179fc38d09    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jun 2016 00:30:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jun 2016 00:30:59 -0400    

Click here for diff

  
Fix grammar, improve examples, etc.  
  
I did not attempt to document the current behavior concerning distance-zero  
matches, because I think that's broken and needs to change, so I'm not  
going to use up brain cells figuring out how to explain how it works now.  
One way or the other, there's still more to write here.  
  

Fix typo.

  
commit   : f721e94b5f360391fc3ffe183bf697a0441e9184    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 8 Jun 2016 08:37:06 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 8 Jun 2016 08:37:06 -0400    

Click here for diff

  
Amit Langote  
  

Test parallel query essentials in “make check”.

  
commit   : 14a254fb52423c57059851abafbd1247261f7f03    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 7 Jun 2016 23:36:22 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 7 Jun 2016 23:36:22 -0400    

Click here for diff

  
Clément Prévost and Peter Eisentraut  
  

Make psql_crosstab plans more stable

  
commit   : c588df9971f41210d2fad8bf0112a78458de96cb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jun 2016 19:18:31 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jun 2016 19:18:31 -0400    

Click here for diff

  
To achieve this, ANALYZE the data table before querying it, as suggested  
by Tom Lane.  On my system, this enables the test to pass with 128 kB of  
work_mem (a value with which other tests fail -- so it seems good  
enough).  
  
Reported by Michaël Paquier.  
  

nls-global.mk: search build dir for source files, too

  
commit   : 736c95ca1647ae088c4c996218e8ef20a56b1795    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jun 2016 18:55:18 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jun 2016 18:55:18 -0400    

Click here for diff

  
In VPATH builds, the build directory was not being searched for files in  
GETTEXT_FILES, leading to failure to construct the .pot files.  This has  
bit me all along, but never hard enough to get it fixed; I suppose not a  
lot of people uses VPATH and NLS-enabled builds, and those that do,  
don't do "make update-po" often.  
  
This is a longstanding problem, so backpatch all the way back.  
  

Fix thinko in description of table_name parameter

  
commit   : a6dacf6bbb45bbb73a0729022daa47197312c321    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jun 2016 18:18:26 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jun 2016 18:18:26 -0400    

Click here for diff

  
Commit 6820094d1 mixed up types of parent object (table) with type of  
sub-object being commented on.  Noticed while fixing docs for  
COMMENT ON ACCESS METHOD.  
  
Backpatch to 9.5, like that commit.  
  

Add missing translate_columns array entry

  
commit   : 8b3746208ce2a2a2bb057dec09cf09a0c783d91b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jun 2016 18:03:31 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jun 2016 18:03:31 -0400    

Click here for diff

  
This omission caused an assertion error in \dA+.  
  

Fix loose ends for SQL ACCESS METHOD objects

  
commit   : 4f04b66f97f0e0265489f0fe0373ea44c9ad11bf    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jun 2016 17:59:34 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jun 2016 17:59:34 -0400    

Click here for diff

  
COMMENT ON ACCESS METHOD was missing; add it, along psql tab-completion  
support for it.  
  
psql was also missing a way to list existing access methods; the new \dA  
command does that.  
  
Also add tab-completion support for DROP ACCESS METHOD.  
  
Author: Michael Paquier  
Discussion: https://www.postgresql.org/message-id/CAB7nPqTzdZdu8J7EF8SXr_R2U5bSUUYNOT3oAWBZdEoggnwhGA@mail.gmail.com  
  

Revert “Use Foreign Key relationships to infer multi-column join selectivity”.

  
commit   : 77ba610805e7ef9ba9c9a593ea8b1ca8f98f8bcb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Jun 2016 17:21:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Jun 2016 17:21:17 -0400    

Click here for diff

  
This commit reverts 137805f89 as well as the associated commits 015e88942,  
5306df283, and 68d704edb.  We found multiple bugs in this feature, and  
there was concern about possible planner slowdown (though to be fair,  
exhibiting a very large slowdown proved difficult).  The way forward  
requires a considerable rewrite, which may or may not be possible to  
accomplish in time for beta2.  In my judgment reviewing the rewrite will  
be easier to accomplish starting from a clean slate, so let's temporarily  
revert what's there now.  This also leaves us in a safe state if it turns  
out to be necessary to postpone the rewrite to the next development cycle.  
  
Discussion: <20160429102531.GA13701@huehner.biz>  
  

Message style and wording fixes

  
commit   : 5c6d2a5e7c83bf6e157fe4ca0ab9b123012289e9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 7 Jun 2016 14:18:08 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 7 Jun 2016 14:18:08 -0400    

Click here for diff

  
  

doc: Update wording about direct system catalog manipulation

  
commit   : df7cc3976db6980d115d1dc6556f021d9783d579    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 7 Jun 2016 14:15:42 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 7 Jun 2016 14:15:42 -0400    

Click here for diff

  
It was previously suggested that "esoteric" operations such as creating  
a new access method would require direct manipulation of the system  
catalogs, but that example has gone away, and I can't think of a new one  
to replace it, so just put in some weasel wording.  
  

doc: Fix typo

  
commit   : 79616ae73b0ba2fb650a9d8ebc5ce8a088cb3858    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 7 Jun 2016 14:15:21 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 7 Jun 2016 14:15:21 -0400    

Click here for diff

  
  

Correct phrasing in dsm.c comments

  
commit   : 1f74a9088881d5e7e3fc20508bc6fa47beeb6290    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 7 Jun 2016 17:34:33 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 7 Jun 2016 17:34:33 +0100    

Click here for diff

  
  

Improve documentation for contrib/bloom.

  
commit   : cfd4804b1ebed8108ef6caedc76fb6eb37bc9724    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Jun 2016 12:19:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Jun 2016 12:19:18 -0400    

Click here for diff

  
Michael Paquier, David Johnston, Tom Lane  
  
Discussion: <CAB7nPqQB8dcFmY1uodmiJOSZdhBFOx-us-uW6rfYrzhpEiBR2g@mail.gmail.com>  
  

Update lo extension for parallel query.

  
commit   : e7880e5d39d098d40717d23c9162b8e52294792a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jun 2016 11:26:01 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jun 2016 11:26:01 -0400    

Click here for diff

  
The lo_oid function provided by this extension is PARALLEL SAFE.  
  
Andreas Karlsson  
  

Update isn extension for parallel query.

  
commit   : b79b8d8f55522e7bc299efc4a41f02accdeaccbe    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jun 2016 11:25:58 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jun 2016 11:25:58 -0400    

Click here for diff

  
All functions provided by this extension are PARALLEL SAFE.  
  
Andreas Karlsson  
  

Update intagg extension for parallel query.

  
commit   : 1ab194a3a9c6a36a4259be846651eb597a98c862    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jun 2016 11:25:55 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jun 2016 11:25:55 -0400    

Click here for diff

  
All functions provided by this extension are PARALLEL SAFE.  
  
Andreas Karlsson  
  

Update fuzzystrmatch extension for parallel query.

  
commit   : ffab82fbda884bc73485d877dd7d528c4cb15e82    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jun 2016 11:25:53 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jun 2016 11:25:53 -0400    

Click here for diff

  
All functions provided by this extension are PARALLEL SAFE.  
  
Andreas Karlsson  
  

Update earthdistance extension for parallel query.

  
commit   : 50e5226bb3272daac1edb13fce9b8e92be302d64    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jun 2016 11:25:49 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jun 2016 11:25:49 -0400    

Click here for diff

  
All functions provided by this extension are PARALLEL SAFE.  
  
Andreas Karlsson  
  

Update citext extension for parallel query.

  
commit   : a89b4b1be0d3550a7860250ff74dc69730555a1f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jun 2016 11:25:38 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jun 2016 11:25:38 -0400    

Click here for diff

  
All citext functions are PARALLEL SAFE, and a couple of them can  
benefit from having aggregate combine functions.  
  
Andreas Karlsson  
  

Minor typos / copy-editing for snapmgr.c

  
commit   : 40fc4575205dc563b88da1db9a8a75cc4d3b848a    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 7 Jun 2016 11:14:48 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 7 Jun 2016 11:14:48 -0400    

Click here for diff

  
Noticed while reviewing snapshot management.  
  

psql: Add missing file to nls.mk

  
commit   : d8c2dccfdb947d96082fdf4b47ae17656074ad9c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 7 Jun 2016 10:58:46 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 7 Jun 2016 10:58:46 -0400    

Click here for diff

  
crosstabview.c was not added to nls.mk when it was added.  Also remove  
redundant gettext markers, since psql_error() is already registered as a  
gettext keyword.  
  

doc: Refer to table by id

  
commit   : 552346c5502ed93bb97e171f7206ea96f4de3a15    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 7 Jun 2016 10:38:48 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 7 Jun 2016 10:38:48 -0400    

Click here for diff

  
  

pgbench: Fix order in –help output

  
commit   : 298706de2692e3add3cfef2ac02e27f8f237785f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 7 Jun 2016 10:09:24 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 7 Jun 2016 10:09:24 -0400    

Click here for diff

  
The new option --progress-timestamp was just added at the end.  Put it  
in alphabetical order.  
  

Fix simple typo in monitoring docs

  
commit   : 29424a9c666b6722aac7527e388c2b01830a0990    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 7 Jun 2016 15:21:01 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 7 Jun 2016 15:21:01 +0100    

Click here for diff

  
  

pg_dump only selected components of ACCESS METHODs

  
commit   : 562f06f3f0da92e397a2f05e1b9b5bfbde336fb2    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 7 Jun 2016 09:56:02 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 7 Jun 2016 09:56:02 -0400    

Click here for diff

  
dumpAccessMethod() didn't get the memo that we now have a bitfield for  
the components which should be dumped instead of a simple boolean.  
  
Correct that by checking if the relevant bit is set for each component  
being dumped out (and not dumping it out if it isn't set).  
  
This corrects an issue where CREATE ACCESS METHOD commands were being  
included in non-binary-upgrades when an extension included an access  
method (as the bloom extensions does).  
  
Also add a regression test to make sure that we only dump out the  
ACCESS METHOD commands, when they are part of an extension, when doing  
a binary upgrade.  
  
Pointed out by Thom Brown.  
  

PL/Python: Move ereport wrapper test cases to separate file

  
commit   : 83590771241fc89a944ba7703f506f4ca50f7e5f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 7 Jun 2016 09:33:41 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 7 Jun 2016 09:33:41 -0400    

Click here for diff

  
In commit 5c3c3cd0a3046339597a03bc708cb5530dc07059, the new tests were  
apparently just dumped into the first convenient file.  Move them to a  
separate file dedicated to testing that functionality and leave the  
plpython_test test to test basic functionality, as it did before.  
  

Don’t reset changes_since_analyze after a selective-columns ANALYZE.

  
commit   : f64340e7436d0f848a99620196cede947bd61418    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jun 2016 17:44:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jun 2016 17:44:17 -0400    

Click here for diff

  
If we ANALYZE only selected columns of a table, we should not postpone  
auto-analyze because of that; other columns may well still need stats  
updates.  As committed, the counter is left alone if a column list is  
given, whether or not it includes all analyzable columns of the table.  
Per complaint from Tomasz Ostrowski.  
  
It's been like this a long time, so back-patch to all supported branches.  
  
Report: <ef99c1bd-ff60-5f32-2733-c7b504eb960c@ato.waw.pl>  
  

Stop the executor if no more tuples can be sent from worker to leader.

  
commit   : c6dbf1fe79287291bc260cbc06b0de419d2a198c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Jun 2016 14:52:58 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Jun 2016 14:52:58 -0400    

Click here for diff

  
If a Gather node has read as many tuples as it needs (for example, due  
to Limit) it may detach the queue connecting it to the worker before  
reading all of the worker's tuples.  Rather than let the worker  
continue to generate and send all of the results, have it stop after  
sending the next tuple.  
  
More could be done here to stop the worker even quicker, but this is  
about as well as we can hope to do for 9.6.  
  
This is in response to a problem report from Andreas Seltenreich.  
Commit 44339b892a04e94bbb472235882dc6f7023bdc65 should be actually be  
sufficient to fix that example even without this change, but it seems  
better to do this, too, since we might otherwise waste quite a large  
amount of effort in one or more workers.  
  
Discussion: CAA4eK1KOKGqmz9bGu+Z42qhRwMbm4R5rfnqsLCNqFs9j14jzEA@mail.gmail.com  
  
Amit Kapila  
  

shm_mq: After a send fails with SHM_MQ_DETACHED, later ones should too.

  
commit   : 44339b892a04e94bbb472235882dc6f7023bdc65    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Jun 2016 14:35:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Jun 2016 14:35:30 -0400    

Click here for diff

  
Prior to this patch, it was occasionally possible, after shm_mq_sendv  
had previously returned SHM_MQ_DETACHED, for a later shm_mq_sendv  
operation to fail an assertion instead of just again returning  
SHM_MQ_ATTACHED.  From the shm_mq code's point of view, it was  
expecting to be called again with the same arguments, since the  
previous operation had only partially completed.  However, a caller  
who isn't using non-blocking mode won't be prepared to repeat the call  
with the same arguments, and this code shouldn't expect that they  
will.  Repair in such a way that we'll be OK whether the next call  
uses the same arguments or not.  
  
Found by Andreas Seltenreich.  Analysis and sketch of fix by Amit  
Kapila.  Patch by me, reviewed by Amit Kapila.  
  

pg_upgrade: Don’t overwrite existing files.

  
commit   : e191a6900520a28ece9393eec2fdd69f292f12c4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Jun 2016 09:51:56 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Jun 2016 09:51:56 -0400    

Click here for diff

  
For historical reasons, copyFile and rewriteVisibilityMap took a force  
argument which was always passed as true, meaning that any existing  
file should be overwritten.  However, it seems much safer to instead  
fail if a file we need to write already exists.  
  
While we're at it, remove the "force" argument altogether, since it was  
never passed as anything other than true (and now we would never pass  
it as anything other than false, if we kept it).  
  
Noted by Andres Freund during post-commit review of the patch that added  
rewriteVisibilityMap, commit 7087166a88fe0c04fc6636d0d6d6bea1737fc1fb,  
but this also changes the behavior when copying files without rewriting  
them.  
  
Patch by Masahiko Sawada.  
  

Fix typo.

  
commit   : 932b97a0112aa950af51dfb26645cd67d368f1f3    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Jun 2016 07:58:50 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Jun 2016 07:58:50 -0400    

Click here for diff

  
Jim Nasby  
  

pg_upgrade: Improve error checking in rewriteVisibilityMap.

  
commit   : aba8943082f1ccbfb19f2e7ff02ba3be0fcb6c9d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Jun 2016 06:14:21 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 6 Jun 2016 06:14:21 -0400    

Click here for diff

  
In the old logic, if read() were to return an error, we'd silently stop  
rewriting the visibility map at that point in the file.  That's safe,  
but reporting the error is better, so do that instead.  
  
Report by Andres Freund.  Patch by Masahiko Sawada, with one correction  
by me.  
  

Fix whitespace

  
commit   : 6201a8ef3ab1f44853ab3e4b16afeefc969a58bf    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 5 Jun 2016 17:02:56 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 5 Jun 2016 17:02:56 -0400    

Click here for diff

  
  

Properly initialize SortSupport for ORDER BY rechecks in nodeIndexscan.c.

  
commit   : 8a859691d548dc4733b8bb302c624fbc012db534    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jun 2016 11:53:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jun 2016 11:53:06 -0400    

Click here for diff

  
Fix still another bug in commit 35fcb1b3d: it failed to fully initialize  
the SortSupport states it introduced to allow the executor to re-check  
ORDER BY expressions containing distance operators.  That led to a null  
pointer dereference if the sortsupport code tried to use ssup_cxt.  The  
problem only manifests in narrow cases, explaining the lack of previous  
field reports.  It requires a GiST-indexable distance operator that lacks  
SortSupport and is on a pass-by-ref data type, which among core+contrib  
seems to be only btree_gist's interval opclass; and it requires the scan  
to be done as an IndexScan not an IndexOnlyScan, which explains how  
btree_gist's regression test didn't catch it.  Per bug #14134 from  
Jihyun Yu.  
  
Peter Geoghegan  
  
Report: <20160511154904.2603.43889@wrigleys.postgresql.org>  
  

Update contrib/tsearch2/expected/tsearch2_1.out for phrase FTS.

  
commit   : de33af88238696c483ce4c2bb8b395cc72ab6e3b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jun 2016 00:49:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jun 2016 00:49:42 -0400    

Click here for diff

  
Commits bb140506d and 38627f687 didn't bother with this.  
Per buildfarm member magpie.  
  

Fix grammar’s AND/OR flattening to work with operator_precedence_warning.

  
commit   : 05104f693646c0a4ae446e79cb89057497da17e4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jun 2016 19:12:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jun 2016 19:12:29 -0400    

Click here for diff

  
It'd be good for "(x AND y) AND z" to produce a three-child AND node  
whether or not operator_precedence_warning is on, but that failed to  
happen when it's on because makeAndExpr() didn't look through the added  
AEXPR_PAREN node.  This has no effect on generated plans because prepqual.c  
would flatten the AND nest anyway; but it does affect the number of parens  
printed in ruleutils.c, for example.  I'd already fixed some similar  
hazards in parse_expr.c in commit abb164655, but didn't think to search  
gram.y for problems of this ilk.  Per gripe from Jean-Pierre Pelletier.  
  
Report: <fa0535ec6d6428cfec40c7e8a6d11156@mail.gmail.com>  
  

Inline the easy cases in MakeExpandedObjectReadOnly().

  
commit   : d50183c5786a21910bac566d2987f955c7bc1d62    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jun 2016 18:34:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jun 2016 18:34:05 -0400    

Click here for diff

  
This attempts to buy back some of whatever performance we lost from fixing  
bug #14174 by inlining the initial checks in MakeExpandedObjectReadOnly()  
into the callers.  We can do that in a macro without creating multiple-  
evaluation hazards, so it's pretty much free notationally; and the amount  
of code added to callers should be minimal as well.  (Testing a value can't  
take many more instructions than passing it to a subroutine.)  
  
Might as well inline DatumIsReadWriteExpandedObject() while we're at it.  
  
This is an ABI break for callers, so it doesn't seem safe to put into 9.5,  
but I see no reason not to do it in HEAD.  
  

Mark read/write expanded values as read-only in ValuesNext(), too.

  
commit   : 9eaf5be5067571febf323337fc58bcac97b9f5d5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jun 2016 18:07:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jun 2016 18:07:14 -0400    

Click here for diff

  
Further thought about bug #14174 motivated me to try the case of a  
R/W datum being returned from a VALUES list, and sure enough it was  
broken.  Fix that.  
  
Also add a regression test case exercising the same scenario for  
FunctionScan.  That's not broken right now, because the function's  
result will get shoved into a tuplestore between generation and use;  
but it could easily become broken whenever we get around to optimizing  
FunctionScan better.  
  
There don't seem to be any other places where we put the result of  
expression evaluation into a virtual tuple slot that could then be  
the source for Vars of further expression evaluation, so I think  
this is the end of this bug.  
  

Mark read/write expanded values as read-only in ExecProject().

  
commit   : 69f526aa4947135f2570c4ec545f6387d4b14585    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jun 2016 15:14:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jun 2016 15:14:35 -0400    

Click here for diff

  
If a plan node output expression returns an "expanded" datum, and that  
output column is referenced in more than one place in upper-level plan  
nodes, we need to ensure that what is returned is a read-only reference  
not a read/write reference.  Otherwise one of the referencing sites could  
scribble on or even delete the expanded datum before we have evaluated the  
others.  Commit 1dc5ebc9077ab742, which introduced this feature, supposed  
that it'd be sufficient to make SubqueryScan nodes force their output  
columns to read-only state.  The folly of that was revealed by bug #14174  
from Andrew Gierth, and really should have been immediately obvious  
considering that the planner will happily optimize SubqueryScan nodes  
out of the plan without any regard for this issue.  
  
The safest fix seems to be to make ExecProject() force its results into  
read-only state; that will cover every case where a plan node returns  
expression results.  Actually we can delegate this to ExecTargetList()  
since we can recursively assume that plain Vars will not reference  
read-write datums.  That should keep the extra overhead down to something  
minimal.  We no longer need ExecMakeSlotContentsReadOnly(), which was  
introduced only in support of the idea that just a few plan node types  
would need to do this.  
  
In the future it would be nice to have the planner account for this problem  
and inject force-to-read-only expression evaluation nodes into only the  
places where there's a risk of multiple evaluation.  That's not a suitable  
solution for 9.5 or even 9.6 at this point, though.  
  
Report: <20160603124628.9932.41279@wrigleys.postgresql.org>  
  

Remove bogus code to apply PathTargets to partial paths.

  
commit   : 04ae11f62e643e07c411c4935ea6af46cb112aa9    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Jun 2016 14:27:33 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Jun 2016 14:27:33 -0400    

Click here for diff

  
The partial paths that get modified may already have been used as  
part of a GatherPath which appears in the path list, so modifying  
them is not a good idea at this stage - especially because this  
code has no check that the PathTarget is in fact parallel-safe.  
  
When partial aggregation is being performed, this is actually  
harmless because we'll end up replacing the pathtargets here with  
the correct ones within create_grouping_paths().  But if we've got  
a query tree containing only scan/join operations then this can  
result in incorrectly pushing down parallel-restricted target  
list entries.  If those are, for example, references to subqueries,  
that can crash the server; but it's wrong in any event.  
  
Amit Kapila  
  

Mark PostmasterPid as PGDLLIMPORT.

  
commit   : cac8321970e9fd18730b2ca4e15f2c61dd326053    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Jun 2016 13:50:51 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Jun 2016 13:50:51 -0400    

Click here for diff

  
This is so that extensions can use it.  
  
Michael Paquier  
  

Add new snapshot fields to serialize/deserialize functions.

  
commit   : 370a46fc015115bfeccde4eb208d82049f792f9f    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 3 Jun 2016 11:13:28 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 3 Jun 2016 11:13:28 -0500    

Click here for diff

  
The "snapshot too old" condition was not being recognized when  
using a copied snapshot, since the original timestamp and lsn were  
not being passed along.  Noticed when testing the combination of  
"snapshot too old" with parallel query execution.  
  

Fix comment to be more accurate.

  
commit   : 6436a853f11952495f10e62d8b52b465e119155c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Jun 2016 11:51:50 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Jun 2016 11:51:50 -0400    

Click here for diff

  
Now that we skip vacuuming all-frozen pages, this comment needs  
updating.  
  
Masahiko Sawada  
  

Suppress -Wunused-result warnings about write(), again.

  
commit   : 6c72a28e5ce36a964bbcac2fe6b0b7bcd9251667    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jun 2016 11:29:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jun 2016 11:29:20 -0400    

Click here for diff

  
Adopt the same solution as in commit aa90e148ca70a235, but this time  
let's put the ugliness inside the write_stderr() macro, instead of  
expecting each call site to deal with it.  Back-port that decision  
into psql/common.c where I got the macro from in the first place.  
  
Per gripe from Peter Eisentraut.  
  

Fix various common mispellings.

  
commit   : e1623c3959aac707732d7a6ad09adfb5751763b3    
  
author   : Greg Stark <stark@mit.edu>    
date     : Fri, 3 Jun 2016 15:13:36 +0100    
  
committer: Greg Stark <stark@mit.edu>    
date     : Fri, 3 Jun 2016 15:13:36 +0100    

Click here for diff

  
Mostly these are just comments but there are a few in documentation  
and a handful in code and tests. Hopefully this doesn't cause too much  
unnecessary pain for backpatching. I relented from some of the most  
common like "thru" for that reason. The rest don't seem numerous  
enough to cause problems.  
  
Thanks to Kevin Lyda's tool https://pypi.python.org/pypi/misspellings  
  

Measure Bloom index signature-length reloption in bits, not words.

  
commit   : ee4af347ba89b8492d1f86b6456865e1de1d030f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jun 2016 10:52:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jun 2016 10:52:36 -0400    

Click here for diff

  
Per discussion, this is a more understandable and future-proof way of  
exposing the setting to users.  On-disk, we can still store it in words,  
so as to not break on-disk compatibility with beta1.  
  
Along the way, clean up the code associated with Bloom reloptions.  
Provide explicit macros for default and maximum lengths rather than  
having magic numbers buried in multiple places in the code.  Drop  
the adjustBloomOptions() code altogether: it was useless in view of  
the fact that reloptions.c already performed default-substitution and  
range checking for the options.  Rename a couple of macros and types  
for more clarity.  
  
Discussion: <23767.1464926580@sss.pgh.pa.us>  
  

Cosmetic improvements to freeze map code.

  
commit   : fdfaccfa798c1c9993feae1fac6e0f79d72aa7b7    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Jun 2016 08:43:41 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Jun 2016 08:43:41 -0400    

Click here for diff

  
Per post-commit review comments from Andres Freund, improve variable  
names, comments, and in one place, slightly improve the code structure.  
  
Masahiko Sawada  
  

Be conservative about alignment requirements of struct epoll_event.

  
commit   : a3b30763cc8686f5b4cd121ef0bf510c1533ac22    
  
author   : Greg Stark <stark@mit.edu>    
date     : Thu, 2 Jun 2016 19:23:25 +0100    
  
committer: Greg Stark <stark@mit.edu>    
date     : Thu, 2 Jun 2016 19:23:25 +0100    

Click here for diff

  
Use MAXALIGN size/alignment to guarantee that later uses of memory are  
aligned correctly. E.g. epoll_event might need 8 byte alignment on some  
platforms, but earlier allocations like WaitEventSet and WaitEvent might  
not sized to guarantee that when purely using sizeof().  
  
Found by myself while testing on an Sun Ultra 5 (Sparc IIi) with some  
editorializing by Andres Freund.  
  
In passing fix a couple typos in the area  
  

C comment improvement & typo fix.

  
commit   : 4edb7bd2fd6a48f6104c73551423cb208e13e529    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Thu, 2 Jun 2016 12:52:41 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Thu, 2 Jun 2016 12:52:41 -0500    

Click here for diff

  
Thomas Munro  
  

Redesign handling of SIGTERM/control-C in parallel pg_dump/pg_restore.

  
commit   : e652273e073566b67c2fd36a5754b3fad2bc0291    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jun 2016 13:27:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jun 2016 13:27:53 -0400    

Click here for diff

  
Formerly, Unix builds of pg_dump/pg_restore would trap SIGINT and similar  
signals and set a flag that was tested in various data-transfer loops.  
This was prone to errors of omission (cf commit 3c8aa6654); and even if  
the client-side response was prompt, we did nothing that would cause  
long-running SQL commands (e.g. CREATE INDEX) to terminate early.  
Also, the master process would effectively do nothing at all upon receipt  
of SIGINT; the only reason it seemed to work was that in typical scenarios  
the signal would also be delivered to the child processes.  We should  
support termination when a signal is delivered only to the master process,  
though.  
  
Windows builds had no console interrupt handler, so they would just fall  
over immediately at control-C, again leaving long-running SQL commands to  
finish unmolested.  
  
To fix, remove the flag-checking approach altogether.  Instead, allow the  
Unix signal handler to send a cancel request directly and then exit(1).  
In the master process, also have it forward the signal to the children.  
On Windows, add a console interrupt handler that behaves approximately  
the same.  The main difference is that a single execution of the Windows  
handler can send all the cancel requests since all the info is available  
in one process, whereas on Unix each process sends a cancel only for its  
own database connection.  
  
In passing, fix an old problem that DisconnectDatabase tends to send a  
cancel request before exiting a parallel worker, even if nothing went  
wrong.  This is at least a waste of cycles, and could lead to unexpected  
log messages, or maybe even data loss if it happened in pg_restore (though  
in the current code the problem seems to affect only pg_dump).  The cause  
was that after a COPY step, pg_dump was leaving libpq in PGASYNC_BUSY  
state, causing PQtransactionStatus() to report PQTRANS_ACTIVE.  That's  
normally harmless because the next PQexec() will silently clear the  
PGASYNC_BUSY state; but in a parallel worker we might exit without any  
additional SQL commands after a COPY step.  So add an extra PQgetResult()  
call after a COPY to allow libpq to return to PGASYNC_IDLE state.  
  
This is a bug fix, IMO, so back-patch to 9.3 where parallel dump/restore  
were introduced.  
  
Thanks to Kyotaro Horiguchi for Windows testing and code suggestions.  
  
Original-Patch: <7005.1464657274@sss.pgh.pa.us>  
Discussion: <20160602.174941.256342236.horiguchi.kyotaro@lab.ntt.co.jp>  
  

Fix btree mark/restore bug.

  
commit   : 7392eed7c2a327eb1b496f30a64be33404bcf82e    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Thu, 2 Jun 2016 12:23:01 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Thu, 2 Jun 2016 12:23:01 -0500    

Click here for diff

  
Commit 2ed5b87f96d473962ec5230fd820abfeaccb2069 introduced a bug in  
mark/restore, in an attempt to optimize repeated restores to the  
same page.  This caused an assertion failure during a merge join  
which fed directly from an index scan, although the impact would  
not be limited to that case.  Revert the bad chunk of code from  
that commit.  
  
While investigating this bug it was discovered that a particular  
"paranoia" set of the mark position field would not prevent bad  
behavior; it would just make it harder to diagnose.  Change that  
into an assertion, which will draw attention to any future problem  
in that area more directly.  
  
Backpatch to 9.5, where the bug was introduced.  
  
Bug #14169 reported by Shinta Koyanagi.  
Preliminary analysis by Tom Lane identified which commit caused  
the bug.  
  

Clean up some minor inefficiencies in parallel dump/restore.

  
commit   : 763eec6b6d64767f5b2dd1a1fe314923bbc17968    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Jun 2016 16:14:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Jun 2016 16:14:21 -0400    

Click here for diff

  
Parallel dump did a totally pointless query to find out the name of each  
table to be dumped, which it already knows.  Parallel restore runs issued  
lots of redundant SET commands because _doSetFixedOutputState() was invoked  
once per TOC item rather than just once at connection start.  While the  
extra queries are insignificant if you're dumping or restoring large  
tables, it still seems worth getting rid of them.  
  
Also, give the responsibility for selecting the right client_encoding for  
a parallel dump worker to setup_connection() where it naturally belongs,  
instead of having ad-hoc code for that in CloneArchive().  And fix some  
minor bugs like use of strdup() where pg_strdup() would be safer.  
  
Back-patch to 9.3, mostly to keep the branches in sync in an area that  
we're still finding bugs in.  
  
Discussion: <5086.1464793073@sss.pgh.pa.us>  
  

doc: Update version() and current_date output in tutorial

  
commit   : 9ee56dfeee0389d61020db3c6a47bd2690bd040e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 31 May 2016 16:45:02 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 31 May 2016 16:45:02 -0400    

Click here for diff

  
While the version number is automatically updated in the example output,  
the other details looked a bit dated.  
  
suggested by mike2.schneider@gmail.com  
  

Avoid useless closely-spaced writes of statistics files.

  
commit   : 22b27b4c9eda1ef166309be1f5702277e3a805f8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 May 2016 15:54:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 May 2016 15:54:46 -0400    

Click here for diff

  
The original intent in the stats collector was that we should not write out  
stats data oftener than every PGSTAT_STAT_INTERVAL msec.  Backends will not  
make requests at all if they see the existing data is newer than that, and  
the stats collector is supposed to disregard requests having a cutoff_time  
older than its most recently written data, so that close-together requests  
don't result in multiple writes.  But the latter part of that got broken  
in commit 187492b6c2e8cafc, so that if two backends concurrently decide  
the existing stats are too old, the collector would write the data twice.  
(In principle the collector's logic would still merge requests as long as  
the second one arrives before we've actually written data ... but since  
the message collection loop would write data immediately after processing  
a single inquiry message, that never happened in practice, and in any case  
the window in which it might work would be much shorter than  
PGSTAT_STAT_INTERVAL.)  
  
To fix, improve pgstat_recv_inquiry so that it checks whether the cutoff  
time is too old, and doesn't add a request to the queue if so.  This means  
that we do not need DBWriteRequest.request_time, because the decision is  
taken before making a queue entry.  And that means that we don't really  
need the DBWriteRequest data structure at all; an OID list of database  
OIDs will serve and allow removal of some rather verbose and crufty code.  
  
In passing, improve the comments in this area, which have been rather  
neglected.  Also change backend_read_statsfile so that it's not silently  
relying on MyDatabaseId to have some particular value in the autovacuum  
launcher process.  It accidentally worked as desired because MyDatabaseId  
is zero in that process; but that does not seem like a dependency we want,  
especially with no documentation about it.  
  
Although this patch is mine, it turns out I'd rediscovered a known bug,  
for which Tomas Vondra had already submitted a patch that's functionally  
equivalent to the non-cosmetic aspects of this patch.  Thanks to Tomas  
for reviewing this version.  
  
Back-patch to 9.3 where the bug was introduced.  
  
Prior-Discussion: <1718942738eb65c8407fcd864883f4c8@fuzzy.cz>  
Patch: <4625.1464202586@sss.pgh.pa.us>  
  

Fix whitespace

  
commit   : aa14bc41d1b139fc7b8b3cdd23e422fad86a9b9b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 31 May 2016 13:56:25 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 31 May 2016 13:56:25 -0400    

Click here for diff

  
  

Fix typo in CREATE DATABASE syntax synopsis.

  
commit   : 6d69ea33180263403f0377e420e4035105ef8627    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 May 2016 12:05:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 May 2016 12:05:22 -0400    

Click here for diff

  
Misplaced "]", evidently a thinko in commit 213335c14.  
  

Mirror struct Aggref field order in _copyAggref().

  
commit   : 2195c5afaabd4d794c8bbf1bf10d8e4fe54b6145    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 31 May 2016 00:01:03 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 31 May 2016 00:01:03 -0400    

Click here for diff

  
This is cosmetic, and no supported release has the affected fields.  
  

Move memory barrier in UnlockBufHdr to before releasing the lock.

  
commit   : 87a3023c60f4bab551441492652ef19371847fd3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 30 May 2016 15:35:53 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 30 May 2016 15:35:53 -0700    

Click here for diff

  
This bug appears to have been introduced late in the development of  
48354581a4 ("Allow Pin/UnpinBuffer to operate in a lockfree  
manner.").  
  
Found while debugging a bug which turned out to be independent of the  
commit mentioned above.  
  
Backpatch: -  
  

Fix PageAddItem BRIN bug

  
commit   : 975ad4e602ff5793f2e57cfc883780dd5ff645a0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 May 2016 14:47:22 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 May 2016 14:47:22 -0400    

Click here for diff

  
BRIN was relying on the ability to remove a tuple from an index page,  
then putting another tuple in the same line pointer.  But PageAddItem  
refuses to add a tuple beyond the first free item past the last used  
item, and in particular, it rejects an attempt to add an item to an  
empty page anywhere other than the first line pointer.  PageAddItem  
issues a WARNING and indicates to the caller that it failed, which in  
turn causes the BRIN calling code to issue a PANIC, so the whole  
sequence looks like this:  
	WARNING:  specified item offset is too large  
	PANIC:  failed to add BRIN tuple  
  
To fix, create a new function PageAddItemExtended which is like  
PageAddItem except that the two boolean arguments become a flags bitmap;  
the "overwrite" and "is_heap" boolean flags in PageAddItem become  
PAI_OVERWITE and PAI_IS_HEAP flags in the new function, and a new flag  
PAI_ALLOW_FAR_OFFSET enables the behavior required by BRIN.  
PageAddItem() retains its original signature, for compatibility with  
third-party modules (other callers in core code are not modified,  
either).  
  
Also, in the belt-and-suspenders spirit, I added a new sanity check in  
brinGetTupleForHeapBlock to raise an error if an TID found in the revmap  
is not marked as live by the page header.  This causes it to react with  
"ERROR: corrupted BRIN index" to the bug at hand, rather than a hard  
crash.  
  
Backpatch to 9.5.  
  
Bug reported by Andreas Seltenreich as detected by his handy sqlsmith  
fuzzer.  
Discussion: https://www.postgresql.org/message-id/87mvni77jh.fsf@elite.ansel.ydns.eu  
  

Fix missing abort checks in pg_backup_directory.c.

  
commit   : 3c8aa6654a44837a2c60fc6061665df1adfd677c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 May 2016 13:18:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 May 2016 13:18:48 -0400    

Click here for diff

  
Parallel restore from directory format failed to respond to control-C  
in a timely manner, because there were no checkAborting() calls in the  
code path that reads data from a file and sends it to the backend.  
If any worker was in the midst of restoring data for a large table,  
you'd just have to wait.  
  
This fix doesn't do anything for the problem of aborting a long-running  
server-side command, but at least it fixes things for data transfers.  
  
Back-patch to 9.3 where parallel restore was introduced.  
  

Remove pg_dump/parallel.c’s useless “aborting” flag.

  
commit   : 210981a4a9fdd19cb299f248a7ecc25db9bf7d9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 May 2016 13:00:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 May 2016 13:00:09 -0400    

Click here for diff

  
This was effectively dead code, since the places that tested it could not  
be reached after we entered the on-exit-cleanup routine that would set it.  
It seems to have been a leftover from a design in which error abort would  
try to send fresh commands to the workers --- a design which could never  
have worked reliably, of course.  Since the flag is not cross-platform, it  
complicates reasoning about the code's behavior, which we could do without.  
  
Although this is effectively just cosmetic, back-patch anyway, because  
there are some actual bugs in the vicinity of this behavior.  
  
Discussion: <15583.1464462418@sss.pgh.pa.us>  
  

Lots of comment-fixing, and minor cosmetic cleanup, in pg_dump/parallel.c.

  
commit   : 6b3094c26f9ec8688d802e71562e9be714cfe6ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 May 2016 14:02:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 May 2016 14:02:11 -0400    

Click here for diff

  
The commentary in this file was in extremely sad shape.  The author(s)  
had clearly never heard of the project convention that a function header  
comment should provide an API spec of some sort for that function.  Much  
of it was flat out wrong, too --- maybe it was accurate when written, but  
if so it had not been updated to track subsequent code revisions.  Rewrite  
and rearrange to try to bring it up to speed, and annotate some of the  
places where more work is needed.  (I've refrained from actually fixing  
anything of substance ... yet.)  
  
Also, rename a couple of functions for more clarity as to what they do,  
do some very minor code rearrangement, remove some pointless Asserts,  
fix an incorrect Assert in readMessageFromPipe, and add a missing socket  
close in one error exit from pgpipe().  The last would be a bug if we  
tried to continue after pgpipe() failure, but since we don't, it's just  
cosmetic at present.  
  
Although this is only cosmetic, back-patch to 9.3 where parallel.c was  
added.  It's sufficiently invasive that it'll pose a hazard for future  
back-patching if we don't.  
  
Discussion: <25239.1464386067@sss.pgh.pa.us>  
  

Clean up thread management in parallel pg_dump for Windows.

  
commit   : 807b45375beae6563c3833e72d91869e9b9134e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 May 2016 12:02:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 May 2016 12:02:09 -0400    

Click here for diff

  
Since we start the worker threads with _beginthreadex(), we should use  
_endthreadex() to terminate them.  We got this right in the normal-exit  
code path, but not so much during an error exit from a worker.  
In addition, be sure to apply CloseHandle to the thread handle after  
each thread exits.  
  
It's not clear that these oversights cause any user-visible problems,  
since the pg_dump run is about to terminate anyway.  Still, it's clearly  
better to follow Microsoft's API specifications than ignore them.  
  
Also a few cosmetic cleanups in WaitForTerminatingWorkers(), including  
being a bit less random about where to cast between uintptr_t and HANDLE,  
and being sure to clear the worker identity field for each dead worker  
(not that false matches should be possible later, but let's be careful).  
  
Original observation and patch by Armin Schöffmann, cosmetic improvements  
by Michael Paquier and me.  (Armin's patch also included closing sockets  
in ShutdownWorkersHard(), but that's been dealt with already in commit  
df8d2d8c4.)  Back-patch to 9.3 where parallel pg_dump was introduced.  
  
Discussion: <zarafa.570306bd.3418.074bf1420d8f2ba2@root.aegaeon.de>  
  

Fix release-note typo.

  
commit   : d81ecb9b204ae4aaf10b6a056447fe4ee853d195    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 May 2016 11:07:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 May 2016 11:07:23 -0400    

Click here for diff

  
Léonard Benedetti  
  

Fix DROP ACCESS METHOD IF EXISTS.

  
commit   : 83dbde94f726f2517a79b1cea59e57452c36e734    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 May 2016 11:03:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 May 2016 11:03:18 -0400    

Click here for diff

  
The IF EXISTS option was documented, and implemented in the grammar, but  
it didn't actually work for lack of support in does_not_exist_skipping().  
Per bug #14160.  
  
Report and patch by Kouhei Sutou  
  
Report: <20160527070433.19424.81712@wrigleys.postgresql.org>  
  

Be more predictable about reporting “lock timeout” vs “statement timeout”.

  
commit   : 9dd4178cec3ffd825a4bef558632b7cba3e426c5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 May 2016 10:40:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 May 2016 10:40:20 -0400    

Click here for diff

  
If both timeout indicators are set when we arrive at ProcessInterrupts,  
we've historically just reported "lock timeout".  However, some buildfarm  
members have been observed to fail isolationtester's timeouts test by  
reporting "lock timeout" when the statement timeout was expected to fire  
first.  The cause seems to be that the process is allowed to sleep longer  
than expected (probably due to heavy machine load) so that the lock  
timeout happens before we reach the point of reporting the error, and  
then this arbitrary tiebreak rule does the wrong thing.  We can improve  
matters by comparing the scheduled timeout times to decide which error  
to report.  
  
I had originally proposed greatly reducing the 1-second window between  
the two timeouts in the test cases.  On reflection that is a bad idea,  
at least for the case where the lock timeout is expected to fire first,  
because that would assume that it takes negligible time to get from  
statement start to the beginning of the lock wait.  Thus, this patch  
doesn't completely remove the risk of test failures on slow machines.  
Empirically, however, the case this handles is the one we are seeing  
in the buildfarm.  The explanation may be that the other case requires  
the scheduler to take the CPU away from a busy process, whereas the  
case fixed here only requires the scheduler to not give the CPU back  
right away to a process that has been woken from a multi-second sleep  
(and, perhaps, has been swapped out meanwhile).  
  
Back-patch to 9.3 where the isolationtester timeouts test was added.  
  
Discussion: <8693.1464314819@sss.pgh.pa.us>  
  

Make pg_dump error cleanly with -j against hot standby

  
commit   : d74048defcb1f48c5cc5a1b2a8aa0f7da8663394    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 26 May 2016 22:14:23 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 26 May 2016 22:14:23 +0200    

Click here for diff

  
Getting a synchronized snapshot is not supported on a hot standby node,  
and is by default taken when using -j with multiple sessions. Trying to  
do so still failed, but with a server error that would also go in the  
log. Instead, proprely detect this case and give a better error message.  
  

Disable physical tlist if any Var would need multiple sortgroupref labels.

  
commit   : aeb9ae6457865c8949641d71a9523374d843a418    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 May 2016 14:52:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 May 2016 14:52:24 -0400    

Click here for diff

  
As part of upper planner pathification (commit 3fc6e2d7f5b652b4) I redid  
createplan.c's approach to the physical-tlist optimization, in which scan  
nodes are allowed to return exactly the underlying table's columns so as  
to save doing a projection step at runtime.  The logic was intentionally  
more aggressive than before about applying the optimization, which is  
generally a good thing, but Andres Freund found a case in which it got  
too aggressive.  Namely, if any column is referenced more than once in  
the parent plan node's sorting or grouping column list, we can't optimize  
because then that column would need to have more than one ressortgroupref  
label, and we only have space for one.  
  
Add logic to detect this situation in use_physical_tlist(), and also add  
some error checking in apply_pathtarget_labeling_to_tlist(), which this  
example proves was being overly cavalier about whether what it was doing  
made any sense.  
  
The added test case exposes the problem only because we do not eliminate  
duplicate grouping keys.  That might be something to fix someday, but it  
doesn't seem like appropriate post-beta work.  
  
Report: <20160526021235.w4nq7k3gnheg7vit@alap3.anarazel.de>  
  

Fix typo in 9.5 release nodes

  
commit   : d7ef3572a8a17cd6c495d7593ea94a2cf2c076e3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 26 May 2016 11:58:22 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 26 May 2016 11:58:22 -0400    

Click here for diff

  
Noted by 星合 拓馬 (HOSHIAI Takuma)  
  

Make pg_dump behave more sanely when built without HAVE_LIBZ.

  
commit   : cae2bb1986bc8fd409424562638434d588d0201f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 May 2016 11:51:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 May 2016 11:51:04 -0400    

Click here for diff

  
For some reason the code to emit a warning and switch to uncompressed  
output was placed down in the guts of pg_backup_archiver.c.  This is  
definitely too late in the case of parallel operation (and I rather  
wonder if it wasn't too late for other purposes as well).  Put it in  
pg_dump.c's option-processing logic, which seems a much saner place.  
  
Also, the default behavior with custom or directory output format was  
to emit the warning telling you the output would be uncompressed.  This  
seems unhelpful, so silence that case.  
  
Back-patch to 9.3 where parallel dump was introduced.  
  
Kyotaro Horiguchi, adjusted a bit by me  
  
Report: <20160526.185551.242041780.horiguchi.kyotaro@lab.ntt.co.jp>  
  

In Windows pg_dump, ensure idle workers will shut down during error exit.

  
commit   : df8d2d8c42c5731ad997793cb6a59b617532dffa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 May 2016 10:50:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 May 2016 10:50:30 -0400    

Click here for diff

  
The Windows coding of ShutdownWorkersHard() thought that setting termEvent  
was sufficient to make workers exit after an error.  But that only helps  
if a worker is busy and passes through checkAborting().  An idle worker  
will just sit, resulting in pg_dump failing to exit until the user gives up  
and hits control-C.  We should close the write end of the command pipe  
so that idle workers will see socket EOF and exit, as the Unix coding was  
already doing.  
  
Back-patch to 9.3 where parallel pg_dump was introduced.  
  
Kyotaro Horiguchi  
  

Remove option to write USING before opclass name in CREATE INDEX.

  
commit   : b898eb63678d96482c1519c44f8ead073adf9bb7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 May 2016 19:11:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 May 2016 19:11:00 -0400    

Click here for diff

  
Dating back to commit f10b63923, our grammar has allowed "USING" to  
optionally appear before an opclass name in CREATE INDEX (and, lately,  
some related places such as ON CONFLICT specifications).  Nikolay Shaplov  
noticed that this syntax existed but wasn't documented, and proposed  
documenting it.  But what seems like a better idea is to remove the  
production, thereby making the code match the docs not vice versa.  
This isn't our usual modus operandi for such cases, but there are a  
couple of good reasons to proceed this way:  
  
* So far as I can find, this syntax has never been documented anywhere.  
It isn't relied on by any of our own code or test cases, and there seems  
little reason to suppose that it's been used in the wild either.  
  
* Documenting it would mean that there would be two separate uses of  
USING in the CREATE INDEX syntax, the other being "USING access_method".  
That can lead to nothing but confusion.  
  
So, let's just remove it.  On the off chance that somebody somewhere  
is using it, this isn't something to back-patch, but we can fix it  
in HEAD.  
  
Discussion: <1593237.l7oKHRpxSe@nataraj-amd64>  
  

Ensure that backends see up-to-date statistics for shared catalogs.

  
commit   : 52e8fc3e2e66446e5705904cf7d884d5d669591f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 May 2016 17:48:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 May 2016 17:48:15 -0400    

Click here for diff

  
Ever since we split the statistics collector's reports into per-database  
files (commit 187492b6c2e8cafc), backends have been seeing stale statistics  
for shared catalogs.  This is because the inquiry message only prompts the  
collector to write the per-database file for the requesting backend's own  
database.  Stats for shared catalogs are in a separate file for "DB 0",  
which didn't get updated.  
  
In normal operation this was partially masked by the fact that the  
autovacuum launcher would send an inquiry message at least once per  
autovacuum_naptime that asked for "DB 0"; so the shared-catalog stats would  
never be more than a minute out of date.  However the problem becomes very  
obvious with autovacuum disabled, as reported by Peter Eisentraut.  
  
To fix, redefine the semantics of inquiry messages so that both the  
specified DB and DB 0 will be dumped.  (This might seem a bit inefficient,  
but we have no good way to know whether a backend's transaction will look  
at shared-catalog stats, so we have to read both groups of stats whenever  
we request stats.  Sending two inquiry messages would definitely not be  
better.)  
  
Back-patch to 9.3 where the bug was introduced.  
  
Report: <56AD41AC.1030509@gmx.net>  
  

Fix broken error handling in parallel pg_dump/pg_restore.

  
commit   : 9abd64ec997cc5f0bac485aa1585064308f73c83    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 May 2016 12:39:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 May 2016 12:39:57 -0400    

Click here for diff

  
In the original design for parallel dump, worker processes reported errors  
by sending them up to the master process, which would print the messages.  
This is unworkably fragile for a couple of reasons: it risks deadlock if a  
worker sends an error at an unexpected time, and if the master has already  
died for some reason, the user will never get to see the error at all.  
Revert that idea and go back to just always printing messages to stderr.  
This approach means that if all the workers fail for similar reasons (eg,  
bad password or server shutdown), the user will see N copies of that  
message, not only one as before.  While that's slightly annoying, it's  
certainly better than not seeing any message; not to mention that we  
shouldn't assume that only the first failure is interesting.  
  
An additional problem in the same area was that the master failed to  
disable SIGPIPE (at least until much too late), which meant that sending a  
command to an already-dead worker would cause the master to crash silently.  
That was bad enough in itself but was made worse by the total reliance on  
the master to print errors: even if the worker had reported an error, you  
would probably not see it, depending on timing.  Instead disable SIGPIPE  
right after we've forked the workers, before attempting to send them  
anything.  
  
Additionally, the master relies on seeing socket EOF to realize that a  
worker has exited prematurely --- but on Windows, there would be no EOF  
since the socket is attached to the process that includes both the master  
and worker threads, so it remains open.  Make archive_close_connection()  
close the worker end of the sockets so that this acts more like the Unix  
case.  It's not perfect, because if a worker thread exits without going  
through exit_nicely() the closures won't happen; but that's not really  
supposed to happen.  
  
This has been wrong all along, so back-patch to 9.3 where parallel dump  
was introduced.  
  
Report: <2458.1450894615@sss.pgh.pa.us>  
  

Update doc text to reflect new column in MVCC phenomena table.

  
commit   : 627e360358e3beb67cd2f54393835f979c5e30b7    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 25 May 2016 11:17:08 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 25 May 2016 11:17:08 -0500    

Click here for diff

  
Scott Wehrenberg  
  

Do not DROP default roles in pg_dumpall -c

  
commit   : 018eb027f181234be7a580e9502c40ac5ad04f77    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 24 May 2016 23:31:55 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 24 May 2016 23:31:55 -0400    

Click here for diff

  
When pulling the list of roles to drop, exclude roles whose names  
begin with "pg_" (as we do when we are dumping the roles out to  
recreate them).  
  
Also add regression tests to cover pg_dumpall -c and this specific  
issue.  
  
Noticed by Rushabh Lathia.  Patch by me.  
  

Mark wal_level as PGDLLIMPORT.

  
commit   : f5e7b2f910b7cdb51b7369c76627998432ab6821    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 22:48:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 22:48:47 -0400    

Click here for diff

  
Per buildfarm, this is needed to allow extensions to use XLogIsNeeded()  
in Windows builds.  
  

Fix contrib/bloom to work for unlogged indexes.

  
commit   : abaffa907588283f7673fc223857e6966421b8ca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 21:04:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 21:04:23 -0400    

Click here for diff

  
blbuildempty did not do even approximately the right thing: it tried  
to add a metapage to the relation's regular data fork, which already  
has one at that point.  It should look like the ambuildempty methods  
for all the standard index types, ie, initialize a metapage image in  
some transient storage and then write it directly to the init fork.  
To support that, refactor BloomInitMetapage into two functions.  
  
In passing, fix BloomInitMetapage so it doesn't leave the rd_options  
field of the index's relcache entry pointing at transient storage.  
I'm not sure this had any visible consequence, since nothing much  
else is likely to look at a bloom index's rd_options, but it's  
certainly poor practice.  
  
Per bug #14155 from Zhou Digoal.  
  
Report: <20160524144146.22598.42558@wrigleys.postgresql.org>  
  

Qualify table usage in dumpTable() and use regclass

  
commit   : 2e8b4bf80473d0e4a4254b417424e79195a9ce6a    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 24 May 2016 20:10:16 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 24 May 2016 20:10:16 -0400    

Click here for diff

  
All of the other tables used in the query in dumpTable(), which is  
collecting column-level ACLs, are qualified, so we should be qualifying  
the pg_init_privs, the related sub-select against pg_class and the  
other queries added by the pg_dump catalog ACLs work.  
  
Also, use ::regclass (or ::pg_catalog.regclass, where appropriate)  
instead of using a poorly constructed query to get the OID for various  
catalog tables.  
  
Issues identified by Noah and Alvaro, patch by me.  
  

Fetch XIDs atomically during vac_truncate_clog().

  
commit   : 2d2e40e3befd8b9e0d2757554537345b15fa6ea2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 15:47:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 15:47:51 -0400    

Click here for diff

  
Because vac_update_datfrozenxid() updates datfrozenxid and datminmxid  
in-place, it's unsafe to assume that successive reads of those values will  
give consistent results.  Fetch each one just once to ensure sane behavior  
in the minimum calculation.  Noted while reviewing Alexander Korotkov's  
patch in the same area.  
  
Discussion: <8564.1464116473@sss.pgh.pa.us>  
  

Avoid consuming an XID during vac_truncate_clog().

  
commit   : 996d273978c6f21b8b66f7f3bdd979cc37736c7a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 15:20:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 15:20:12 -0400    

Click here for diff

  
vac_truncate_clog() uses its own transaction ID as the comparison point in  
a sanity check that no database's datfrozenxid has already wrapped around  
"into the future".  That was probably fine when written, but in a lazy  
vacuum we won't have assigned an XID, so calling GetCurrentTransactionId()  
causes an XID to be assigned when otherwise one would not be.  Most of the  
time that's not a big problem ... but if we are hard up against the  
wraparound limit, consuming XIDs during antiwraparound vacuums is a very  
bad thing.  
  
Instead, use ReadNewTransactionId(), which not only avoids this problem  
but is in itself a better comparison point to test whether wraparound  
has already occurred.  
  
Report and patch by Alexander Korotkov.  Back-patch to all versions.  
  
Report: <CAPpHfdspOkmiQsxh-UZw2chM6dRMwXAJGEmmbmqYR=yvM7-s6A@mail.gmail.com>  
  

Fix range check for effective_io_concurrency

  
commit   : 0c7cd45b6d702253c09427929bcceb6e7fe9029a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 24 May 2016 14:55:34 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 24 May 2016 14:55:34 -0400    

Click here for diff

  
Commit 1aba62ec moved the range check of that option form guc.c into  
bufmgr.c, but introduced a bug by changing a >= 0.0 to > 0.0, which made  
the value 0 no longer accepted.  Put it back.  
  
Reported by Jeff Janes, diagnosed by Tom Lane  
  

Docs: mention pg_reload_conf() in ALTER SYSTEM reference page.

  
commit   : c45fb43c8448c5b710d4ef9774497e1789e070e5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 14:04:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 14:04:29 -0400    

Click here for diff

  
Takayuki Tsunakawa  
  
Discussion: <0A3221C70F24FB45833433255569204D1F578FC3@G01JPEXMBYT05>  
  

In examples of Oracle PL/SQL code, use varchar2 not varchar.

  
commit   : 23f11dc21b0135702a2852aac927bdc4f9d69cef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 13:30:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2016 13:30:40 -0400    

Click here for diff

  
Oracle recommends using VARCHAR2 not VARCHAR, allegedly because they might  
someday change VARCHAR to be spec-compliant about distinguishing null from  
empty string.  (I'm not holding my breath, though.)  Our examples of PL/SQL  
code were using VARCHAR, which while not wrong is missing the pedagogical  
opportunity to talk about converting Oracle type names to Postgres.  So  
switch the examples to use VARCHAR2, and add some text about what to do  
with common Oracle type names like VARCHAR2 and NUMBER.  (There is probably  
more to be said here, but those are the ones I'm sure about offhand.)  
Per suggestion from rapg12@gmail.com.  
  
Discussion: <20160521140046.22591.24672@wrigleys.postgresql.org>  
  

Fix typo in docs

  
commit   : 6ee7fb8244560b7a3f224784b8ad2351107fa55d    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Tue, 24 May 2016 15:27:48 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Tue, 24 May 2016 15:27:48 +0300    

Click here for diff

  
Add missing USING BLOOM in example of contrib/bloom  
  
Nikolay Shaplov  
  

Fix typo in TAP test identification string.

  
commit   : 1087aa2314c7755cd436e37b95b84ba2c35b987c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2016 20:04:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2016 20:04:27 -0400    

Click here for diff

  
Michael Paquier  
  

Fix BTREE_BUILD_STATS build.

  
commit   : 1e0d6512e573a568a8ea1a0cb94ea30f800350e2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2016 19:41:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2016 19:41:11 -0400    

Click here for diff

  
Commit 65c5fcd353a859da9e61bfb2b92a99f12937de3b broke this by removing a  
header include directive that is conditionally required.  Add that back  
to nbtree.c, with annotation to keep pgrminclude from re-breaking it.  
  
Peter Geoghegan  
  
Report: <CAM3SWZTNjHFYW_UG8bu0BnogqQ2HfsTgkzXLueuUhfTcYbu5HA@mail.gmail.com>  
  

Support IndexElem in raw_expression_tree_walker().

  
commit   : eae1ad9b64eaa201444ff99848f674be91af0ee6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2016 19:23:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2016 19:23:36 -0400    

Click here for diff

  
Needed for cases in which INSERT ... ON CONFLICT appears inside a  
recursive CTE item.  Per bug #14153 from Thomas Alton.  
  
Patch by Peter Geoghegan, slightly adjusted by me  
  
Report: <20160521232802.22598.13537@wrigleys.postgresql.org>  
  

Add support for more extensive testing of raw_expression_tree_walker().

  
commit   : 465e09da6310fee89946f3ca32ee8002dd4c428a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2016 19:08:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2016 19:08:26 -0400    

Click here for diff

  
If RAW_EXPRESSION_COVERAGE_TEST is defined, do a no-op tree walk over  
every basic DML statement submitted to parse analysis.  If we'd had this  
in place earlier, bug #14153 would have been caught by buildfarm testing.  
The difficulty is that raw_expression_tree_walker() is only used in  
limited cases involving CTEs (particularly recursive ones), so it's  
very easy for an oversight in it to not be noticed during testing of a  
seemingly-unrelated feature.  
  
The type of error we can expect to catch with this is complete omission  
of a node type from raw_expression_tree_walker(), and perhaps also  
recursion into a field that doesn't contain a node tree, though that  
would be an unlikely mistake.  It won't catch failure to add new fields  
that need to be recursed into, unfortunately.  
  
I'll go enable this on one or two of my own buildfarm animals once  
bug #14153 is dealt with.  
  
Discussion: <27861.1464040417@sss.pgh.pa.us>  
  

Fix latent crash in do_text_output_multiline().

  
commit   : 8a4930e3faffedf0c392de1f03508b816fa2244d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2016 14:16:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2016 14:16:40 -0400    

Click here for diff

  
do_text_output_multiline() would fail (typically with a null pointer  
dereference crash) if its input string did not end with a newline.  Such  
cases do not arise in our current sources; but it certainly could happen  
in future, or in extension code's usage of the function, so we should fix  
it.  To fix, replace "eol += len" with "eol = text + len".  
  
While at it, make two cosmetic improvements: mark the input string const,  
and rename the argument from "text" to "txt" to dodge pgindent strangeness  
(since "text" is a typedef name).  
  
Even though this problem is only latent at present, it seems like a good  
idea to back-patch the fix, since it's a very simple/safe patch and it's  
not out of the realm of possibility that we might in future back-patch  
something that expects sane behavior from do_text_output_multiline().  
  
Per report from Hao Lee.  
  
Report: <CAGoxFiFPAGyPAJLcFxTB5cGhTW2yOVBDYeqDugYwV4dEd1L_Ag@mail.gmail.com>  
  

psql: Message style improvements

  
commit   : a50b605aa4487cbf677625a7a1bb5f2b05058d91    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 21 May 2016 22:17:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 21 May 2016 22:17:00 -0400    

Click here for diff

  
  

Improve docs about contrib/intarray’s benchmark suite.

  
commit   : 768d6f90f9e44af96c22135a8eb1e83ed73c422b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 May 2016 15:43:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 May 2016 15:43:57 -0400    

Click here for diff

  
Correct obsolete install instructions, as noted by Daniel Gustafsson.  
Clarify the test code's prerequisites.  
  
Discussion: <88E617F2-7721-4C4E-84F4-886A2041C1D0@yesql.se>  
  

Improve docs about using ORDER BY to control aggregate input order.

  
commit   : 82eafabeaaf12231a85ed67bbf4eae698aacb1c9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 May 2016 12:55:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 May 2016 12:55:31 -0400    

Click here for diff

  
David Johnston pointed out that the original text here had been obsoleted  
by SQL:2008, which allowed ORDER BY in subqueries.  We could weaken the  
text to describe ORDER-BY-in-subqueries as an optional SQL feature that's  
possibly unportable; but then the exact same statements would apply to  
the alternative it's being compared to (ORDER-BY-in-aggregate-calls).  
So really that would be pretty useless; let's just take out the sentence  
entirely.  Instead, point out the hazard that any extra processing in the  
upper query might cause the subquery output order to be destroyed.  
  
Discussion: <CAKFQuwbAX=iO9QbpN7_jr+BnUWm9FYX8WbEPUvG0p+nZhp6TZg@mail.gmail.com>  
  

Further improve documentation about –quote-all-identifiers switch.

  
commit   : 50e5315a58554735096f7530cb766fae2dd3b0c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 May 2016 15:51:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 May 2016 15:51:57 -0400    

Click here for diff

  
Mention it in the Notes section too, per suggestion from David Johnston.  
  
Discussion: <20160520165824.22598.31426@wrigleys.postgresql.org>  
  

Improve documentation about pg_dump’s –quote-all-identifiers switch.

  
commit   : 960be4a9986d5c4fde585c531e726c85e2aa787a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 May 2016 14:59:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 May 2016 14:59:47 -0400    

Click here for diff

  
Per bug #14152 from Alejandro Martínez.  Back-patch to all supported  
branches.  
  
Discussion: <20160520165824.22598.31426@wrigleys.postgresql.org>  
  

Pin the built-in index access methods.

  
commit   : 16ea51a263bfbb009ba73f36494f49246933e93c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 May 2016 14:40:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 May 2016 14:40:02 -0400    

Click here for diff

  
This was overlooked in commit 473b93287, which introduced DROP ACCESS  
METHOD.  Although that command is restricted to superusers, we don't want  
even superusers dropping the built-in methods; "DROP ACCESS METHOD btree"  
in particular is unrecoverable from.  Pin these objects in the same way  
that other initdb-created objects are pinned.  
  
I chose to bump catversion for this fix.  That's not absolutely necessary  
perhaps, but it will ensure that no 9.6 production systems are missing  
the pin entries.  
  

Avoid possible crash in contrib/bloom’s blendscan().

  
commit   : e13ac5586c49c77f301329b79bd7e8f489d0e66f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 May 2016 17:01:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 May 2016 17:01:18 -0400    

Click here for diff

  
It's possible to begin and end an indexscan without ever calling  
amrescan.  contrib/bloom, unlike every other index AM, allocated  
its "scan->opaque" storage at amrescan time, and thus would crash  
in amendscan if amrescan hadn't been called.  We could fix this  
by putting in a null-pointer check in blendscan, but I see no very  
good reason why contrib/bloom should march to its own drummer in  
this respect.  Let's move that initialization to blbeginscan  
instead.  Per report from Jeff Janes.  
  

Allocate all page images at once in generic wal interface

  
commit   : 7c979c95a3700d0bd34c2831f49a9260d505b0f9    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Tue, 17 May 2016 22:09:22 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Tue, 17 May 2016 22:09:22 +0300    

Click here for diff

  
That reduces number of allocation.  
  
Per gripe from Michael Paquier and Tom Lane suggestion.  
  

Fix typo

  
commit   : b09cd2e50a69182ef38ad67ac77d06a87236c5b0    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 17 May 2016 11:28:18 -0400    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 17 May 2016 11:28:18 -0400    

Click here for diff

  
Amit Langote  
  

Correctly align page’s images in generic wal API

  
commit   : 7c8345f67f3008a394adccae262f2a2162b6f5c7    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Tue, 17 May 2016 00:01:35 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Tue, 17 May 2016 00:01:35 +0300    

Click here for diff

  
Page image should be MAXALIGN'ed because existing code could directly align  
pointers in page instead of align offset from beginning of page.  
  
Found during play with indexes as extenstion, Alexander Korotkov and me  
  

postgres_fdw: Fix the fix for crash when pushing down multiple joins.

  
commit   : 02a568a02769ca626591039f460109369bf05dc2    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 16 May 2016 11:28:28 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 16 May 2016 11:28:28 -0400    

Click here for diff

  
Commit 3151f16e1874db82ed85a005dac15368903ca9fb was intended to be  
a commit of a patch from Ashutosh Bapat, but instead I mistakenly  
committed an earlier version from Michael Paquier (because both  
patches were submitted with the same filename, and I confused them).  
Michael's patch fixes the crash but doesn't actually implement the  
correct test.  
  
Repair the incorrect logic, and also expand the comments considerably  
so that this is all more clear.  
  
Ashutosh Bapat and Robert Haas  
  

Fix multiple problems in postgres_fdw query cancellation logic.

  
commit   : 1b812afb0eafe125b820cc3b95e7ca03821aa675    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 16 May 2016 11:19:10 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 16 May 2016 11:19:10 -0400    

Click here for diff

  
First, even if we cancel a query, we still have to roll back the  
containing transaction; otherwise, the session will be left in a  
failed transaction state.  
  
Second, we need to support canceling queries whe aborting a  
subtransaction as well as when aborting a toplevel transaction.  
  
Etsuro Fujita, reviewed by Michael Paquier  
  

Fix comment.

  
commit   : b7a9347c11e19918a34b127a096061bfb002fcb5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 May 2016 17:04:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 May 2016 17:04:01 -0400    

Click here for diff

  
Reference to getThreadLocalPQExpBuffer here seems inappropriate, since  
we aren't necessarily using that instantiation of getLocalPQExpBuffer.  
  

sql_features: Fix typos

  
commit   : 9b7bfc3a88ef7b374444205c14db76dae6b35b56    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 13 May 2016 21:24:54 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 13 May 2016 21:24:54 -0400    

Click here for diff

  
This makes the feature names match the SQL standard.  
  
From: Alexander Law <exclusion@gmail.com>  
  

doc: Fix typo

  
commit   : 8eec44be6b4e7f73b89e06b50a6773f4d8d0e53e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 13 May 2016 21:24:13 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 13 May 2016 21:24:13 -0400    

Click here for diff

  
From: Alexander Law <exclusion@gmail.com>  
  

Update release instructions for translation updates

  
commit   : 5251f2fc4d5b9d4c064678bf09d4627e67e40561    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 13 May 2016 21:21:47 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 13 May 2016 21:21:47 -0400    

Click here for diff

  
We don't tag the translations repository any more, because the commits  
into postgresql contain the git hashes, and that's authoritative.  
  

  
commit   : 6d52e8b64612fc339d33acee9e91f04c3cc5b182    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 13 May 2016 10:38:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 13 May 2016 10:38:35 -0400    

Click here for diff

  
  

Ensure plan stability in contrib/btree_gist regression test.

  
commit   : d94977ef1cef8810a6a7692a1debd56b7811b2aa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2016 20:04:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2016 20:04:12 -0400    

Click here for diff

  
Buildfarm member skink failed with symptoms suggesting that an  
auto-analyze had happened and changed the plan displayed for a  
test query.  Although this is evidently of low probability,  
regression tests that sometimes fail are no fun, so add commands  
to force a bitmap scan to be chosen.  
  

Fix bogus comments

  
commit   : cca2a278609e9ed9bedc4796ae1427fbfb88a2fc    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 May 2016 16:02:49 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 May 2016 16:02:49 -0300    

Click here for diff

  
Some comments mentioned XLogReplayBuffer, but there's no such function:  
that was an interim name for a function that got renamed to  
XLogReadBufferForRedo, before commit 2c03216d831160 was pushed.  
  

Fix obsolete comment

  
commit   : bdb9e3dc1da95bdfc28deb43914ff5f082bd9043    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 May 2016 15:36:51 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 May 2016 15:36:51 -0300    

Click here for diff

  
  

doc: Document default of max_worker_processes

  
commit   : 83b8ee87541c82505a85476024c1a4d50452a697    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 12 May 2016 09:15:49 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 12 May 2016 09:15:49 -0400    

Click here for diff

  
found by David G. Johnston <david.g.johnston@gmail.com>  
  

doc: Small wording change for clarity

  
commit   : 122b99478a7baa3a8deb03938ea5ae15a1ad7584    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 12 May 2016 08:32:12 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 12 May 2016 08:32:12 -0400    

Click here for diff

  
From: Martín Marqués <martin@2ndquadrant.com>  
  

Fix infer_arbiter_indexes() to not barf on system columns.

  
commit   : 8a13d5e6d1bb9ff9460c72992657077e57e30c32    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 May 2016 17:06:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 May 2016 17:06:53 -0400    

Click here for diff

  
While it could be argued that rejecting system column mentions in the  
ON CONFLICT list is an unsupported feature, falling over altogether  
just because the table has a unique index on OID is indubitably a bug.  
  
As far as I can tell, fixing infer_arbiter_indexes() is sufficient to  
make ON CONFLICT (oid) actually work, though making a regression test  
for that case is problematic because of the impossibility of setting  
the OID counter to a known value.  
  
Minor cosmetic cleanups along with the bug fix.  
  

Fix assorted missing infrastructure for ON CONFLICT.

  
commit   : 26e66184d6136643d16f6fb167db517fb18b8f89    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 May 2016 16:20:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 May 2016 16:20:03 -0400    

Click here for diff

  
subquery_planner() failed to apply expression preprocessing to the  
arbiterElems and arbiterWhere fields of an OnConflictExpr.  No doubt the  
theory was that this wasn't necessary because we don't actually try to  
execute those expressions; but that's wrong, because it results in failure  
to match to index expressions or index predicates that are changed at all  
by preprocessing.  Per bug #14132 from Reynold Smith.  
  
Also add pullup_replace_vars processing for onConflictWhere.  Perhaps  
it's impossible to have a subquery reference there, but I'm not exactly  
convinced; and even if true today it's a failure waiting to happen.  
  
Also add some comments to other places where one or another field of  
OnConflictExpr is intentionally ignored, with explanation as to why it's  
okay to do so.  
  
Also, catalog/dependency.c failed to record any dependency on the named  
constraint in ON CONFLICT ON CONSTRAINT, allowing such a constraint to  
be dropped while rules exist that depend on it, and allowing pg_dump to  
dump such a rule before the constraint it refers to.  The normal execution  
path managed to error out reasonably for a dangling constraint reference,  
but ruleutils.c dumped core; so in addition to fixing the omission, add  
a protective check in ruleutils.c, since we can't retroactively add a  
dependency in existing databases.  
  
Back-patch to 9.5 where this code was introduced.  
  
Report: <20160510190350.2608.48667@wrigleys.postgresql.org>  
  

Update key words table for 9.6

  
commit   : 9be58a2b8ef222c1de80ccbb55b19ab0cff33237    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 11 May 2016 15:01:44 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 11 May 2016 15:01:44 -0400    

Click here for diff

  
  

Fix autovacuum for shared relations

  
commit   : 15739393e4c3b64b9038d75784e848a415827517    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 May 2016 16:23:54 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 May 2016 16:23:54 -0300    

Click here for diff

  
The table-skipping logic in autovacuum would fail to consider that  
multiple workers could be processing the same shared catalog in  
different databases.  This normally wouldn't be a problem: firstly  
because autovacuum workers not for wraparound would simply ignore tables  
in which they cannot acquire lock, and secondly because most of the time  
these tables are small enough that even if multiple for-wraparound  
workers are stuck in the same catalog, they would be over pretty  
quickly.  But in cases where the catalogs are severely bloated it could  
become a problem.  
  
Backpatch all the way back, because the problem has been there since the  
beginning.  
  
Reported by Ondřej Světlík  
  
Discussion: https://www.postgresql.org/message-id/572B63B1.3030603%40flexibee.eu  
	https://www.postgresql.org/message-id/572A1072.5080308%40flexibee.eu  
  

Stamp 9.6beta1.

  
commit   : 8ee29a19d69ab6c19ec0f7565541b9f96e898200    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 May 2016 16:47:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 May 2016 16:47:49 -0400    

Click here for diff

  
  

Translation updates

  
commit   : 48aaba4acf4db787a1f1dff01b910e7557f1c657    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 9 May 2016 10:04:41 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 9 May 2016 10:04:41 -0400    

Click here for diff

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

Improve 9.6 release notes.

  
commit   : 91fd1df4aad2141859310564b498a3e28055ee28    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 May 2016 16:53:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 May 2016 16:53:55 -0400    

Click here for diff

  
Incorporate some suggestions from David Johnston, and update through today.  
  

Docs: create some user-facing documentation about index-only scans.

  
commit   : e6dd664d0dd362235fd0af31360ecbf29434c4c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 May 2016 16:36:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 May 2016 16:36:19 -0400    

Click here for diff

  
We didn't have any real user documentation about how index-only scans  
work or how to design indexes to exploit them.  Remedy that.  
Per gripe from David Johnston.  
  

Wording quibbles regarding initdb username

  
commit   : 6f69b96390eddf9c6129840eac511fd4159f01bb    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sun, 8 May 2016 12:58:21 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sun, 8 May 2016 12:58:21 -0400    

Click here for diff

  
Use disallowed instead of reserved, cannot instead of can not, and  
double quotes instead of single quotes.  
  
Also add a test to cover the bug which started this discussion.  
  
Per discussion with Tom.  
  

Disallow superuser names starting with ‘pg_’ in initdb

  
commit   : 7df974ee0bfd8978830b941e7af5697fd4268656    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sun, 8 May 2016 11:55:44 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sun, 8 May 2016 11:55:44 -0400    

Click here for diff

  
As with CREATE ROLE, disallow users from specifying initial  
superuser names which begin with 'pg_' in initdb.  
  
Per discussion with Tom.  
  

Fix poorly-worded log message.

  
commit   : 9eb7a0ac6b24804dcc90e42e533aa1b7b585d8e2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 May 2016 01:37:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 May 2016 01:37:07 -0400    

Click here for diff

  
Euler Taveira  
  

Release notes for 9.5.3, 9.4.8, 9.3.13, 9.2.17, 9.1.22.

  
commit   : 4768cc4565df3527293271e4ef6e90d8db4e106d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 May 2016 17:26:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 May 2016 17:26:23 -0400    

Click here for diff

  
  

In new pg_dump TAP tests, remove trailing “$” from regexps using /m.

  
commit   : b8180884082d46346394e1c54fc454d2c16bf3ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 May 2016 16:36:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 May 2016 16:36:50 -0400    

Click here for diff

  
It emerges that some Perl versions before 5.8.9 have a bug with regexps  
that use the /m flag and contain "$".  This is the reason why jacana  
is still failing on HEAD, and I was able to duplicate the failure on  
prairiedog's host.  There's no real need for "$" in these patterns,  
since they are already matching through the statement-terminating  
semicolons (or matching an explicit \n in some cases).  So just  
remove it.  
  
Note: the reason jacana hasn't actually reported any failures in the  
last little while is that the way the pg_dump TAP tests are set up, any  
failure of this sort results in echoing the entire pg_dump dump output  
to stderr.  Since there were about a hundred such failures, that resulted  
in a 30MB log file which choked the buildfarm upload script.  There is  
room for improvement here :-(.  
  
Per off-list discussion with Andrew and Stephen.  
  

Docs: improve warnings about nextval() not producing gapless sequences.

  
commit   : 691d99de386aa1f5a858e04634dbaaba48488ef8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 May 2016 13:16:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 May 2016 13:16:50 -0400    

Click here for diff

  
In the documentation for nextval(), point out explicitly that INSERT ...  
ON CONFLICT will call nextval() if needed for the insertion case, whether  
or not it ends up following the ON CONFLICT path.  This seems to be a  
matter of some confusion, cf bug #14126, so let's be clear about it.  
  
Also mention the issue in the CREATE SEQUENCE reference page, since that  
is another place where people might expect such things to be covered.  
  
Minor wording improvements nearby, as well.  
  
Back-patch to 9.5 where ON CONFLICT was introduced.  
  

Update back-branch release notes for the last few commits.

  
commit   : 7dc1d359699345a2b2af6af6d21bd6f7bd6cfb27    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 May 2016 00:51:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 May 2016 00:51:27 -0400    

Click here for diff

  
OpenSSL error queue fix no longer needs to be documented under 9.6.  
  

Clean up after pg_dump test runs.

  
commit   : 74a73b17225385e54dbf9fc2f77aaa59191ac04b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 22:28:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 22:28:01 -0400    

Click here for diff

  
The tmp_check directory needs to be removed by "make clean",  
and also ignored by .gitignore.  
  

Fix pg_upgrade to not fail when new-cluster TOAST rules differ from old.

  
commit   : 1a2c17f8e221b0c3c63cb2b1be1f862444f62516    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 22:05:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 22:05:51 -0400    

Click here for diff

  
This patch essentially reverts commit 4c6780fd17aa43ed, in favor of a much  
simpler solution for the case where the new cluster would choose to create  
a TOAST table but the old cluster doesn't have one: just don't create a  
TOAST table.  
  
The existing code failed in at least two different ways if the situation  
arose: (1) ALTER TABLE RESET didn't grab an exclusive lock, so that the  
lock sanity check in create_toast_table failed; (2) pg_upgrade did not  
provide a pg_type OID for the new toast table, so that the crosscheck in  
TypeCreate failed.  While both these problems were introduced by later  
patches, they show that the hack being used to cause TOAST table creation  
is overwhelmingly fragile (and untested).  I also note that before the  
TypeCreate crosscheck was added, the code would have resulted in assigning  
an indeterminate pg_type OID to the toast table, possibly causing a later  
OID conflict in that catalog; so that it didn't really work even when  
committed.  
  
If we simply don't create a TOAST table, there will only be a problem if  
the code tries to store a tuple that's wider than a page, and field  
compression isn't sufficient to get it under a page.  Given that the TOAST  
creation threshold is intended to be about a quarter of a page, it's very  
hard to believe that cross-version differences in the do-we-need-a-toast-  
table heuristic could result in an observable problem.  So let's just  
follow the old version's conclusion about whether a TOAST table is needed.  
  
(If we ever do change needs_toast_table() so much that this conclusion  
doesn't apply, we can devise a solution at that time, and hopefully do  
it in a less klugy way than 4c6780fd17aa43ed did.)  
  
Back-patch to 9.3, like the previous patch.  
  
Discussion: <8110.1462291671@sss.pgh.pa.us>  
  

Disable BLOB test in pg_dump TAP tests

  
commit   : 0f97c722bb201c67312eec0a9ff3691cda37878f    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 21:24:31 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 21:24:31 -0400    

Click here for diff

  
Buildfarm member jacana appears to have an issue with running this  
test.  It's not entirely clear to me why, but rather than try to  
fight with it, just disable it for now.  
  
None of the other tests try to write out from psql directly as  
this test does, so it seems likely that the rest of the tests will  
be fine (as they have been on numerous other systems).  
  

Mitigate “snapshot too old” performance regression on NUMA

  
commit   : 7e3da1c4737fd6582e12c80983987e4d2cbc1d17    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 6 May 2016 20:05:29 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 6 May 2016 20:05:29 -0500    

Click here for diff

  
Limit maintenance of time to xid mapping to once per minute.  At  
least in the tested case this brings performance within 5% of when  
the feature is off, compared to several times slower without this  
patch.  
  
While there, fix comments and whitespace.  
  
Ants Aasma, with cosmetic adjustments suggested by Andres Freund  
Reviewed by Kevin Grittner and Andres Freund  
  

First-draft release notes for 9.5.3.

  
commit   : eb7de00ac2d282263541ece849ec71e2809e9467    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 19:43:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 19:43:51 -0400    

Click here for diff

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

Docs: fix alphabetization of table entries.

  
commit   : bbbae5ead3952bee9184da4864e2f4078940cac7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 17:48:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 17:48:56 -0400    

Click here for diff

  
Fabien Coelho  
  

Docs: minor copy-editing for GSSAPI/SSPI authentication docs.

  
commit   : 36db18eaa0def33b3f7ea5e3980c43431ca9c923    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 17:42:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 17:42:44 -0400    

Click here for diff

  
Describe compat_realm = 0 as "disabled" not "enabled", per discussion  
with Christian Ullrich.  I failed to resist the temptation to do some  
other minor copy-editing in the same area.  
  

Add test_pg_dump to @contrib_excludes

  
commit   : 6e243c43c9b2d35f91a73d3982db6a0cad0eb64b    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 16:39:56 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 16:39:56 -0400    

Click here for diff

  
The test_pg_dump extension doesn't have a C component, so we need  
to exclude it from the MSVC build system trying to figure out how  
to build it.  
  
Also add a "MODULES" line to the Makefile, as test_extensions has.  
Might not be necessary, but seems good to keep things consistent.  
  
Lastly, remove the 'installcheck' line from test_pg_dump, as that  
was causing redefinition errors, at least on my box.  This also  
makes test_pg_dump consistent with how commit_ts is set up.  
  

More small 9.6 release note improvements.

  
commit   : 76ef266a86fdc3c4bdbd12b9ea9cacd523e00779    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 16:20:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 16:20:56 -0400    

Click here for diff

  
Corrections per Jeff Janes, Christian Ullrich, and Daniel Vérité.  
  

Correct query in pg_dumpall:dumpRoles

  
commit   : c778e27e13e883fb759f6100727aba80102933bd    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 16:15:52 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 16:15:52 -0400    

Click here for diff

  
We need to use a new branch due to the 9.5 addition of bypassrls  
when adding in the clause to exclude pg_* roles from being dumped  
by pg_dumpall.  
  
Pointed out by Noah, patch by me.  
  

Remove MODULES_big from test_pg_dump

  
commit   : eccfeeb631fa44850b644661d8b2ce94d9ef4fc1    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 15:26:57 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 15:26:57 -0400    

Click here for diff

  
The Makefile for test_pg_dump shouldn't have a MODULES_big line  
because there's no actual compiled bit for that extension.  Hopefully  
this will fix the Windows buildfarm members which were complaining.  
  
In passing, also add the 'prove_installcheck' bit to the pg_dump and  
test_pg_dump Makefiles, to get the buildfarm members to actually run  
those tests.  
  

Minimal fix for crash bug in quals_match_foreign_key.

  
commit   : 68d704edbfe14fd8d21545b244c3f6824e0fbb8a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 May 2016 15:00:55 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 May 2016 15:00:55 -0400    

Click here for diff

  
Discussion is still underway as to whether to revert the entire patch  
that added this function, but that discussion may not conclude before  
beta1.  So, in the meantime, let's do at least this much.  
  
David Rowley  
  

Limit maximum parallel degree to 1024.

  
commit   : c7ea68ff8dfafc22c6cfefdb5929e12ec5d1e02a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 May 2016 14:43:34 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 May 2016 14:43:34 -0400    

Click here for diff

  
This new limit affects both the max_parallel_degree GUC and the  
parallel_degree reloption.  There may some day be a use case for using  
more than 1024 CPUs for a single query, but that's surely not the case  
right now.  Not only do not very many people have that many CPUs, but  
the code hasn't been tested at that kind of scale and is very unlikely  
to perform well, or even work at all, without a lot more work.  The  
issue addressed by commit 06bd458cb812623c3f1fdd55216c4c08b06a8447 is  
probably just one problem of many.  
  
The idea of a more reasonable limit here was suggested by Tom Lane;  
the value of 1024 was suggested by Amit Kapila.  
  

Improve pg_upgrade’s report about failure to match up old and new tables.

  
commit   : 73b9952e8278b9c9a6f5f8e2df196fea5abb61f0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 14:23:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 14:23:45 -0400    

Click here for diff

  
Ordinarily, pg_upgrade shouldn't have any difficulty in matching up all  
the relations it sees in the old and new databases.  If it does, however,  
it just goes belly-up with a pretty unhelpful error message.  That seemed  
fine as long as we expected the case never to occur in the wild, but  
Alvaro reported that it had been seen in a database whose pg_largeobject  
table had somehow acquired a TOAST table.  That doesn't quite seem like  
a case that pg_upgrade actually needs to handle, but it would be good if  
the report were more diagnosable.  Hence, extend the logic to print out  
as much information as we can about the mismatch(es) before we quit.  
  
In passing, improve the readability of get_rel_infos()'s data collection  
query, which had suffered seriously from lets-not-bother-to-update-comments  
syndrome, and generally was unnecessarily disrespectful to readers.  
  
It could be argued that this is a bug fix, but given that we have so few  
reports, I don't feel a need to back-patch; at least not before this has  
baked awhile in HEAD.  
  

Use mul_size when multiplying by the number of parallel workers.

  
commit   : 06bd458cb812623c3f1fdd55216c4c08b06a8447    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 May 2016 14:23:47 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 May 2016 14:23:47 -0400    

Click here for diff

  
That way, if the result overflows size_t, you'll get an error instead  
of undefined behavior, which seems like a plus.  This also has the  
effect of casting the number of workers from int to Size, which is  
better because it's harder to overflow int than size_t.  
  
Dilip Kumar reported this issue and provided a patch upon which this  
patch is based, but his version did use mul_size.  
  

Remove various special checks around default roles

  
commit   : a89505fd21da337b81172871d8f65d9a4fa22a8b    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 14:06:50 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 14:06:50 -0400    

Click here for diff

  
Default roles really should be like regular roles, for the most part.  
This removes a number of checks that were trying to make default roles  
extra special by not allowing them to be used as regular roles.  
  
We still prevent users from creating roles in the "pg_" namespace or  
from altering roles which exist in that namespace via ALTER ROLE, as  
we can't preserve such changes, but otherwise the roles are very much  
like regular roles.  
  
Based on discussion with Robert and Tom.  
  

Add TAP tests for pg_dump

  
commit   : 6bd356c33a3cf3a49313dc8638ea4bb066c4cf37    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 14:06:50 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 14:06:50 -0400    

Click here for diff

  
This TAP test suite will create a new cluster, populate it based on  
the 'create_sql' values in the '%tests' hash, run all of the runs  
defined in the '%pgdump_runs' hash, and then for each test in the  
'%tests' hash, compare each run's output the the regular expression  
defined for the test under the 'like' and 'unlike' functions, as  
appropriate.  
  
While this test suite covers a fair bit of ground (67% of pg_dump.c  
and quite a bit of the other files in src/bin/pg_dump), there is  
still quite a bit which remains to be added to provide better code  
coverage.  Still, this is quite a bit better than we had, and has  
found a few bugs already (note that the CREATE TRANSFORM test is  
commented out, as it is currently failing).  
  
Idea for using the TAP system from Tom, though all of the code is mine.  
  

Only issue LOCK TABLE commands when necessary

  
commit   : e1b120a8cbb0f39a79926fd173f33e57202cdfa0    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 14:06:50 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 14:06:50 -0400    

Click here for diff

  
Reviewing the cases where we need to LOCK a given table during a dump,  
it was pointed out by Tom that we really don't need to LOCK a table if  
we are only looking to dump the ACL for it, or certain other  
components.  After reviewing the queries run for all of the component  
pieces, a list of components were determined to not require LOCK'ing  
of the table.  
  
This implements a check to avoid LOCK'ing those tables.  
  
Initial complaint from Rushabh Lathia, discussed with Robert and Tom,  
the patch is mine.  
  

pg_dump performance and other fixes

  
commit   : 5d589993cad212f7d556d52cc1e42fe18f65b057    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 14:06:50 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 14:06:50 -0400    

Click here for diff

  
Do not try to dump objects which do not have ACLs when only ACLs are  
being requested.  This results in a significant performance improvement  
as we can avoid querying for further information on these objects when  
we don't need to.  
  
When limiting the components to dump for an extension, consider what  
components have been requested.  Initially, we incorrectly hard-coded  
the components of the extension objects to dump, which would mean that  
we wouldn't dump some components even with they were asked for and in  
other cases we would dump components which weren't requested.  
  
Correct defaultACLs to use 'dump_contains' instead of 'dump'.  The  
defaultACL is considered a member of the namespace and should be  
dumped based on the same set of components that the other objects in  
the schema are, not based on what we're dumping for the namespace  
itself (which might not include ACLs, if the namespace has just the  
default or initial ACL).  
  
Use DUMP_COMPONENT_ACL for from-initdb objects, to allow users to  
change their ACLs, should they wish to.  This just extends what we  
are doing for the pg_catalog namespace to objects which are not  
members of namespaces.  
  
Due to column ACLs being treated a bit differently from other ACLs  
(they are actually reset to NULL when all privileges are revoked),  
adjust the query which gathers column-level ACLs to consider all of  
the ACL-relevant columns.  
  

Correct pg_dump WHERE clause for functions/aggregates

  
commit   : 64d60c8bf0703011d79dcb8a55dc42dcedc1e10f    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 14:06:50 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 May 2016 14:06:50 -0400    

Click here for diff

  
The query to grab the function/aggregate information is now joining  
to pg_init_privs, so we can simplify (and correct) the WHERE clause  
used to determine if a given function's ACL has changed from the  
initial ACL on the function.  
  
Bug found by Noah, patch by me.  
  

Update config.guess and config.sub

  
commit   : e324f8ad610bdc83a1392e54da5d9613e710b02f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 6 May 2016 14:00:47 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 6 May 2016 14:00:47 -0400    

Click here for diff

  
  

Fix possible read past end of string in to_timestamp().

  
commit   : d136d600f9756232b36681fdfada0e40e1563a47    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 12:09:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 12:09:20 -0400    

Click here for diff

  
to_timestamp() handles the TH/th format codes by advancing over two input  
characters, whatever those are.  It failed to notice whether there were  
two characters available to be skipped, making it possible to advance  
the pointer past the end of the input string and keep on parsing.  
A similar risk existed in the handling of "Y,YYY" format: it would advance  
over three characters after the "," whether or not three characters were  
available.  
  
In principle this might be exploitable to disclose contents of server  
memory.  But the security team concluded that it would be very hard to use  
that way, because the parsing loop would stop upon hitting any zero byte,  
and TH/th format codes can't be consecutive --- they have to follow some  
other format code, which would have to match whatever data is there.  
So it seems impractical to examine memory very much beyond the end of the  
input string via this bug; and the input string will always be in local  
memory not in disk buffers, making it unlikely that anything very  
interesting is close to it in a predictable way.  So this doesn't quite  
rise to the level of needing a CVE.  
  
Thanks to Wolf Roediger for reporting this bug.  
  

Fix pgbench’s parsing of double values to notice trailing garbage.

  
commit   : 6b8b4e4d8320d8c9daf9410175c40a09e58c4868    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 11:08:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 11:08:48 -0400    

Click here for diff

  
Noted by Fabien Coelho, though this isn't exactly his proposed patch.  
(The technique used here is borrowed from the zic sources.)  
  

Improve handling of numeric-valued variables in pgbench.

  
commit   : 9515299485a591b3a8f03c118d11809d01663665    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 11:01:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 11:01:05 -0400    

Click here for diff

  
The previous coding always stored variable values as strings, doing  
conversion on-the-fly when a numeric value was needed or a number was to be  
assigned.  This was a bit inefficient and risked loss of precision for  
floating-point values.  The precision aspect had been hacked around by  
printing doubles in "%.18e" format, which is ugly and has machine-dependent  
results.  Instead, arrange to preserve an assigned numeric value in the  
original binary numeric format, converting to string only when and if  
needed.  When we do need to convert a double to string, convert in "%g"  
format with DBL_DIG precision, which is the standard way to do it and  
produces the least surprising results in most cases.  
  
The implementation supports storing both a string value and a numeric  
value for any one variable, with lazy conversion between them.  I also  
arranged for lazy re-sorting of the variable array when new variables are  
added.  That was mainly to allow a clean refactoring of putVariable()  
into two levels of subroutine, but it may allow us to save a few sorts.  
  
Discussion: <9188.1462475559@sss.pgh.pa.us>  
  

Docs: fix \crosstabview example.

  
commit   : daa9856fcea775caeb4c92580b9693858509b43b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 10:39:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 10:39:35 -0400    

Click here for diff

  
This example missed being updated when we redefined \crosstabview's  
argument processing.  
  
Daniel Vérité  
  

Fix hash index vs “snapshot too old” problemms

  
commit   : 2cc41acd8fa3ebb8f0501c6102a253fb7053cf46    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 6 May 2016 07:47:12 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 6 May 2016 07:47:12 -0500    

Click here for diff

  
Hash indexes are not WAL-logged, and so do not maintain the LSN of  
index pages.  Since the "snapshot too old" feature counts on  
detecting error conditions using the LSN of a table and all indexes  
on it, this makes it impossible to safely do early vacuuming on any  
table with a hash index, so add this to the tests for whether the  
xid used to vacuum a table can be adjusted based on  
old_snapshot_threshold.  
  
While at it, add a paragraph to the docs for old_snapshot_threshold  
which specifically mentions this and other aspects of the feature  
which may otherwise surprise users.  
  
Problem reported and patch reviewed by Amit Kapila  
  

Fix psql’s \ev and \sv commands so that they handle view reloptions.

  
commit   : 9b66aa006f81b2705337ca223daeeabf4db6453a    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 6 May 2016 12:48:27 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 6 May 2016 12:48:27 +0100    

Click here for diff

  
Commit 8eb6407aaeb6cbd972839e356b436bb698f51cff added support for  
editing and showing view definitions, but neglected to account for  
view options such as security_barrier and WITH CHECK OPTION which are  
not returned by pg_get_viewdef() and so need special handling.  
  
Author: Dean Rasheed  
Reviewed-by: Peter Eisentraut  
Discussion: http://www.postgresql.org/message-id/CAEZATCWZjCgKRyM-agE0p8ax15j9uyQoF=qew7D2xB6cF76T8A@mail.gmail.com  
  

Move and rename fmtReloptionsArray().

  
commit   : 93a8c6fd6c5eeb61c12402f616a327d998a731c4    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 6 May 2016 12:45:36 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Fri, 6 May 2016 12:45:36 +0100    

Click here for diff

  
Move fmtReloptionsArray() from pg_dump.c to string_utils.c so that it  
is available to other frontend code. In particular psql's \ev and \sv  
commands need it to handle view reloptions. Also rename the function  
to appendReloptionsArray(), which is a more accurate description of  
what it does.  
  
Author: Dean Rasheed  
Reviewed-by: Peter Eisentraut  
Discussion: http://www.postgresql.org/message-id/CAEZATCWZjCgKRyM-agE0p8ax15j9uyQoF=qew7D2xB6cF76T8A@mail.gmail.com  
  

Further 9.6 release note improvements.

  
commit   : 306ff0aaf8ef2a4c69a799faf7e6c72fea1c4709    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 22:37:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 22:37:30 -0400    

Click here for diff

  
Call out the major enhancements in this release as identified by  
pgsql-advocacy discussion, and rearrange some of the entries to  
make those items more prominent.  Other minor improvements per  
advice from Vitaly Burovoy, Masahiko Sawada, Peter Geoghegan,  
and Andres Freund.  
  

Update time zone data files to tzdata release 2016d.

  
commit   : 98f158e41e8eea69c796d6734a3548ee62bb98ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 20:08:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 20:08:58 -0400    

Click here for diff

  
DST law changes in Russia (Magadan, Tomsk regions) and Venezuela.  
Historical corrections for Russia.  There are new zone names Europe/Kirov  
and Asia/Tomsk reflecting the fact that these regions now have different  
time zone histories from adjacent regions.  
  

Rename tsvector delete() to ts_delete(), and filter() to ts_filter().

  
commit   : 0b9a23443283f9ffb17a39c25f74adefdb72cae1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 19:43:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 19:43:32 -0400    

Click here for diff

  
The similarity of the original names to SQL keywords seems like a bad  
idea.  Rename them before we're stuck with 'em forever.  
  
In passing, minor code and docs cleanup.  
  
Discussion: <4875.1462210058@sss.pgh.pa.us>  
  

Small 9.6 release note improvements.

  
commit   : 2f38b986fa8ff048c7226f1ca212e12084c715cf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 18:52:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 18:52:32 -0400    

Click here for diff

  
Sync release notes through today, and incorporate some suggestions  
from Robert Haas.  
  

Rename pgbench min/max to least/greatest, and fix handling of double args.

  
commit   : 7a622b2731db5d0f6db8a3d0af88177f96d1cb2e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 14:51:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 14:51:00 -0400    

Click here for diff

  
These functions behave like the backend's least/greatest functions,  
not like min/max, so the originally-chosen names invite confusion.  
Per discussion, rename to least/greatest.  
  
I also took it upon myself to make them return double if any input is  
double.  The previous behavior of silently coercing all inputs to int  
surely does not meet the principle of least astonishment.  
  
Copy-edit some of the other new functions' documentation, too.  
  

First-draft release notes for Postgres 9.6.

  
commit   : c311f7887376f7f3ce24c4c0dac4f9cb6ad3bee3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 13:27:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 13:27:59 -0400    

Click here for diff

  
These are just of beta quality, but we're only at beta ... the section  
about parallel query, in particular, could doubtless use more work.  
  

Fix ordering/categorization of some recently-added system views.

  
commit   : a9ba6195f12d9b89e103c1b043cc6958e40b1ef0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 12:33:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 12:33:12 -0400    

Click here for diff

  
Somebody added pg_replication_origin, pg_replication_origin_status and  
pg_replication_slots to catalogs.sgml without a whole lot of concern for  
either alphabetical order or the difference between a table and a view.  
Clean up the mess.  
  
Back-patch to 9.5, not so much because this is critical as because if  
I don't it will result in a cross-branch divergence in release-9.5.sgml,  
which would be a maintenance hazard.  
  

Fix corner-case loss of precision in numeric pow() calculation

  
commit   : 18a02ad2a506e4425c6dd2ea235039cd5659467d    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 5 May 2016 11:16:17 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Thu, 5 May 2016 11:16:17 +0100    

Click here for diff

  
Commit 7d9a4737c268f61fb8800957631f12d3f13be218 greatly improved the  
accuracy of the numeric transcendental functions, however it failed to  
consider the case where the result from pow() is close to the overflow  
threshold, for example 0.12 ^ -2345.6. For such inputs, where the  
result has more than 2000 digits before the decimal point, the decimal  
result weight estimate was being clamped to 2000, leading to a loss of  
precision in the final calculation.  
  
Fix this by replacing the clamping code with an overflow test that  
aborts the calculation early if the final result is sure to overflow,  
based on the overflow limit in exp_var(). This provides the same  
protection against integer overflow in the subsequent result scale  
computation as the original clamping code, but it also ensures that  
precision is never lost and saves compute cycles in cases that are  
sure to overflow.  
  
The new early overflow test works with the initial low-precision  
result (expected to be accurate to around 8 significant digits) and  
includes a small fuzz factor to ensure that it doesn't kick in for  
values that would not overflow exp_var(), so the overall overflow  
threshold of pow() is unchanged and consistent for all inputs with  
non-integer exponents.  
  
Author: Dean Rasheed  
Reviewed-by: Tom Lane  
Discussion: http://www.postgresql.org/message-id/CAEZATCUj3U-cQj0jjoia=qgs0SjE3auroxh8swvNKvZWUqegrg@mail.gmail.com  
See-also: http://www.postgresql.org/message-id/CAEZATCV7w+8iB=07dJ8Q0zihXQT1semcQuTeK+4_rogC_zq5Hw@mail.gmail.com  
  

Revert timeline following in replication slots

  
commit   : c1543a81a7a89207b6c45b8f3f7f07b1148fcc6e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 4 May 2016 17:32:22 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 4 May 2016 17:32:22 -0300    

Click here for diff

  
This reverts commits f07d18b6e94d, 82c83b337202, 3a3b309041b0, and  
24c5f1a103ce.  
  
This feature has shown enough immaturity that it was deemed better to  
rip it out before rushing some more fixes at the last minute.  There are  
discussions on larger changes in this area for the next release.  
  

doc: Fix more typos

  
commit   : 6535bf399894db3597d257486062fe17311c642e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 4 May 2016 14:07:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 4 May 2016 14:07:00 -0400    

Click here for diff

  
From: Alexander Law <exclusion@gmail.com>  
  

Fix crash of filter(tsvector)

  
commit   : 4bbc1a7ea351f235eb9a4475ceb17d7e37a36473    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Wed, 4 May 2016 17:58:08 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Wed, 4 May 2016 17:58:08 +0300    

Click here for diff

  
Variable storing a position of lexeme, had a wrong type: char, it's  
obviously not enough to store 2^14 possible positions.  
  
Stas Kelvich  
  

Fix transient mdsync() errors of truncated relations due to 72a98a6395.

  
commit   : a712487087c73eee880ff1a7c50528cbab2f1b90    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 4 May 2016 01:54:20 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 4 May 2016 01:54:20 -0700    

Click here for diff

  
Unfortunately the segment size checks from 72a98a6395 had the negative  
side-effect of breaking a corner case in mdsync(): When processing a  
fsync request for a truncated away segment mdsync() could fail with  
"could not fsync file" (if previous segment < RELSEG_SIZE) because  
_mdfd_getseg() now wouldn't return the relevant segment anymore.  
  
The cleanest fix seems to be to allow the caller of _mdfd_getseg() to  
specify whether checks for RELSEG_SIZE are performed. To allow doing so,  
change the ExtensionBehavior enum into a bitmask. Besides allowing for  
the addition of EXTENSION_DONT_CHECK_SIZE, this makes for a nicer  
implementation of EXTENSION_REALLY_RETURN_NULL.  
  
Besides mdsync() the only callsite that should change behaviour due to  
this is mdprefetch() which now doesn't create segments anymore, even in  
recovery. Given the uses of mdprefetch() that seems better.  
  
Reported-By: Thom Brown  
Discussion: CAA-aLv72QazLvPdKZYpVn4a_Eh+i4_cxuB03k+iCuZM_xjc+6Q@mail.gmail.com  
  

doc: Fix typos

  
commit   : 613fb29a384c8a75146af7cfa433cfa61716f117    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 3 May 2016 21:06:25 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 3 May 2016 21:06:25 -0400    

Click here for diff

  
From: Alexander Law <exclusion@gmail.com>  
  

Fix more things to be parallel-safe.

  
commit   : 9888b34fdb169c1f0982ad700fc6d43e8b7aec14    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 3 May 2016 14:36:38 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 3 May 2016 14:36:38 -0400    

Click here for diff

  
Conversion functions were previously marked as parallel-unsafe, since  
that is the default, but in fact they are safe.  Parallel-safe  
functions defined in pg_proc.h and redefined in system_views.sql were  
ending up as parallel-unsafe because the redeclarations were not  
marked PARALLEL SAFE.  While editing system_views.sql, mark ts_debug()  
parallel safe also.  
  
Andreas Karlsson  
  

Tweak a few more things in preparation for upcoming pgindent run.

  
commit   : 8826d850781cb328482c8f92af2a3d93385cd63b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 3 May 2016 10:52:25 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 3 May 2016 10:52:25 -0400    

Click here for diff

  
These adjustments adjust code and comments in minor ways to prevent  
pgindent from mangling them.  Among other things, I tried to avoid  
situations where pgindent would emit "a +b" instead of "a + b", and I  
tried to avoid having it break up inline comments across multiple  
lines.  
  

Note that max_worker_processes requires restart.

  
commit   : 1e77949e67b94af4d2a350c6dac9109419932608    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 3 May 2016 10:39:21 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 3 May 2016 10:39:21 -0400    

Click here for diff

  
Since this is a minor issue, no back-patch.  
  
Julien Rouhaud  
  

Fix thinko in comment

  
commit   : 6b6091682959adce6d66dcd6a047eb21cb120b16    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 2 May 2016 16:46:42 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 2 May 2016 16:46:42 -0300    

Click here for diff

  
Pointed out by Andres Freund  
  

Fix code comments regarding logical decoding

  
commit   : 234a266066dc1c06a92ec85efb2f8948b7fbd320    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 2 May 2016 16:04:29 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 2 May 2016 16:04:29 -0300    

Click here for diff

  
Back in 3b02ea4f0780 I added some comments in various places to explain  
how logical decoding and other things worked.  Not all of the changes  
were welcome, because they were misleading or wrong.  This changes them  
a little bit to make them more accurate.  
  
Some other comments are also changed to be more accurate.  Also, fix a  
bunch of typos.  
  
Author: Álvaro Herrera, Craig Ringer  
  
Andres Freund reviewed some parts of this.  
  

Docs: improve index entries for new tsvector functions.

  
commit   : 21c2b1c611d072f1a27defa89803fdd09b132605    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 May 2016 13:28:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 May 2016 13:28:52 -0400    

Click here for diff

  
Fix typos, reword some overly general index entries.  
  

Fix configure’s incorrect version tests for flex and perl.

  
commit   : 7d7b129277eb545286aecf29ec22b5bb7fdf46bd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 May 2016 11:18:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 May 2016 11:18:10 -0400    

Click here for diff

  
awk's equality-comparison operator is "==" not "=".  We got this right  
in many places, but not in configure's checks for supported version  
numbers of flex and perl.  It hadn't been noticed because unsupported  
versions are so old as to be basically extinct in the wild, and because  
the only consequence is whether or not a WARNING flies by during  
configure.  
  
Daniel Gustafsson noted the problem with respect to the test for flex,  
I found the other by reviewing other awk calls.  
  

Fix parallel safety markings for pg_start_backup.

  
commit   : 37d0c2cb1ab2d3da0cb9a6388450776fc31c16ee    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 2 May 2016 10:42:34 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 2 May 2016 10:42:34 -0400    

Click here for diff

  
Commit 7117685461af50f50c03f43e6a622284c8d54694 made pg_start_backup  
parallel-restricted rather than parallel-safe, because it now relies  
on backend-private state that won't be synchronized with the parallel  
worker.  However, it didn't update pg_proc.h.  Separately, Andreas  
Karlsson observed that system_views.sql neglected to reiterate the  
parallel-safety markings whe redefining various functions, including  
this one; so add a PARALLEL RESTRICTED declaration there to match  
the new value in pg_proc.h.  
  

Again update typedefs.list file in preparation for pgindent run

  
commit   : f2f5e7e78ed95bb28d8bde783c46562e3498ac99    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 2 May 2016 09:23:55 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 2 May 2016 09:23:55 -0400    

Click here for diff

  
This time, use the buildfarm-supplied contents for this file, instead  
of trying to update it by eyeballing the pgindent output.  
  
Per discussion with Tom and Bruce.  
  

Remove unused macros.

  
commit   : d22b85fbd4ca3b4c2f41d8d4372205d56b296eb3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 2 May 2016 10:07:49 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 2 May 2016 10:07:49 +0300    

Click here for diff

  
CHECK_PAGE_OFFSET_RANGE() has been unused forever.  
CHECK_RELATION_BLOCK_RANGE() has been unused in pgstatindex.c ever since  
bt_page_stats() and bt_page_items() functions were moved from pgstattuple  
to pageinspect module. It still exists in pageinspect/btreefuncs.c.  
  
Daniel Gustafsson  
  

doc: Fix typo

  
commit   : a956bf439584ac5955ccf4e9c1a9aed2e9c4c95c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 1 May 2016 21:33:31 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 1 May 2016 21:33:31 -0400    

Click here for diff

  
From: Guillaume Lelarge <guillaume@lelarge.info>  
  

Add a –non-master-only option to git_changelog.

  
commit   : 8473b7f95fbe8ef25dccd23ff94a4e363797bd90    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 May 2016 11:24:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 May 2016 11:24:32 -0400    

Click here for diff

  
This has the inverse effect of --master-only.  It's needed to help find  
cases where a commit should not be described in major release notes  
because it was back-patched into older branches, though not at the same  
time as the HEAD commit.  
  

Update contrib/unaccent documentation about its unaccent.rules file.

  
commit   : 6376a16ba24a5a097fc739b9c79ab555be4d9f1a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Apr 2016 15:06:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Apr 2016 15:06:26 -0400    

Click here for diff

  
Commit 1bbd52cb9a4aa61a didn't bother with such niceties.  
  

Small improvements to OPTIMIZER_DEBUG code.

  
commit   : 2a2435e6995133c9d872ef9cb51432f0b678b978    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Apr 2016 14:08:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Apr 2016 14:08:00 -0400    

Click here for diff

  
Now that Paths have their own rows field, print that rather than  
the parent relation's rowcount.  
  
Show the relid sets associated with Paths using table names rather  
than numbers; since this code is able to print simple Var references  
using table names, it seems a bit silly that print_relids can't.  
  
Print the cheapest_parameterized_paths list for a RelOptInfo, and  
include information about a parameterized path's required_outer rels.  
  
Noted while trying to use this feature to debug Alexander Kirkouski's  
recent bug report.  
  

Fix planner crash from pfree’ing a partial path that a GatherPath uses.

  
commit   : c45bf5751b6338488bd79ce777210285531da373    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Apr 2016 12:29:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Apr 2016 12:29:21 -0400    

Click here for diff

  
We mustn't run generate_gather_paths() during add_paths_to_joinrel(),  
because that function can be invoked multiple times for the same target  
joinrel.  Not only is it wasteful to build GatherPaths repeatedly, but  
a later add_partial_path() could delete the partial path that a previously  
created GatherPath depends on.  Instead establish the convention that we  
do generate_gather_paths() for a rel only just before set_cheapest().  
  
The code was accidentally not broken for baserels, because as of today there  
never is more than one partial path for a baserel.  But that assumption  
obviously has a pretty short half-life, so move the generate_gather_paths()  
calls for those cases as well.  
  
Also add some generic comments explaining how and why this all works.  
  
Per fuzz testing by Andreas Seltenreich.  
  
Report: <871t5pgwdt.fsf@credativ.de>  
  

Remove warning about num_sync being too large in synchronous_standby_names.

  
commit   : 17d5db352c1780f4721664f67bc3a3f3b1cf933c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Apr 2016 10:54:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Apr 2016 10:54:45 -0400    

Click here for diff

  
If we're not going to reject such setups entirely, throwing a WARNING in  
check_synchronous_standby_names() is unhelpful, because it will cause the  
warning to be logged again every time the postmaster receives SIGHUP.  
Per discussion, just remove the warning.  
  
In passing, improve the documentation for synchronous_commit, which had not  
gotten the word that now there can be more than one synchronous standby.  
  

Fix mishandling of equivalence-class tests in parameterized plans.

  
commit   : 207d5a656e2ecc98a1db5bdc22ea306f7f7c8d62    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Apr 2016 20:19:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Apr 2016 20:19:38 -0400    

Click here for diff

  
Given a three-or-more-way equivalence class, such as X.Y = Y.Y = Z.Z,  
it was possible for the planner to omit one of the quals needed to  
enforce that all members of the equivalence class are actually equal.  
This only happened in the case of a parameterized join node for two  
of the relations, that is a plan tree like  
  
	Nested Loop  
	  ->  Scan X  
	  ->  Nested Loop  
	    ->  Scan Y  
	    ->  Scan Z  
	          Filter: Z.Z = X.X  
  
The eclass machinery normally expects to apply X.X = Y.Y when those  
two relations are joined, but in this shape of plan tree they aren't  
joined until the top node --- and, if the lower nested loop is marked  
as parameterized by X, the top node will assume that the relevant eclass  
condition(s) got pushed down into the lower node.  On the other hand,  
the scan of Z assumes that it's only responsible for constraining Z.Z  
to match any one of the other eclass members.  So one or another of  
the required quals sometimes fell between the cracks, depending on  
whether consideration of the eclass in get_joinrel_parampathinfo()  
for the lower nested loop chanced to generate X.X = Y.Y or X.X = Z.Z  
as the appropriate constraint there.  If it generated the latter,  
it'd erroneously suppose that the Z scan would take care of matters.  
To fix, force X.X = Y.Y to be generated and applied at that join node  
when this case occurs.  
  
This is *extremely* hard to hit in practice, because various planner  
behaviors conspire to mask the problem; starting with the fact that the  
planner doesn't really like to generate a parameterized plan of the  
above shape.  (It might have been impossible to hit it before we  
tweaked things to allow this plan shape for star-schema cases.)  Many  
thanks to Alexander Kirkouski for submitting a reproducible test case.  
  
The bug can be demonstrated in all branches back to 9.2 where parameterized  
paths were introduced, so back-patch that far.  
  

Add a few entries to the tail of time mapping, to see old values.

  
commit   : 7c3e8039f450eb99b3a73272d0a1661195747d1b    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 29 Apr 2016 16:46:08 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 29 Apr 2016 16:46:08 -0500    

Click here for diff

  
Without a few entries beyond old_snapshot_threshold, the lookup  
would often fail, resulting in the more aggressive pruning or  
vacuum being skipped often enough to matter.  This was very clearly  
shown by a python test script posted by Ants Aasma, and was likely  
a factor in an earlier but somewhat less clear-cut test case posted  
by Jeff Janes.  
  
This patch makes no change to the logic, per se -- it just makes  
the array of mapping entries big enough to make lookup misses based  
on timing much less likely.  An occasional miss is still possible  
if a thread stalls for more than 10 minutes, but that does not  
create any problem with correctness of behavior.  Besides, if  
things are so busy that a thread is stalling for more than 10  
minutes, it is probably OK to skip the more aggressive cleanup at  
that particular point in time.  
  

Fix comment whitespace in VS2105 patch

  
commit   : d34e7b2812467279b95060a4db8d9f4fc4be0e40    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 29 Apr 2016 14:18:51 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 29 Apr 2016 14:18:51 -0400    

Click here for diff

  
per gripe from Michael Paquier.  
  

doc: Minor wording changes

  
commit   : 82881b2b432c9433b45abc96acf49d5d690eb918    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 29 Apr 2016 13:03:58 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 29 Apr 2016 13:03:58 -0400    

Click here for diff

  
From: Dmitry Igrishin <dmitigr@gmail.com>  
  

Fix typo

  
commit   : a03bda323b0713aeaacfd0050be76df9e6b06a13    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 29 Apr 2016 16:14:20 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 29 Apr 2016 16:14:20 +0200    

Click here for diff

  
Author: Thomas Munro  
  

Fix typo in VS2015 patch

  
commit   : 7dc549238eabe6a634af3e24520f2c3f5667f76f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 29 Apr 2016 09:49:31 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 29 Apr 2016 09:49:31 -0400    

Click here for diff

  
reported by Christian Ullrich  
  

Support building with Visual Studio 2015

  
commit   : 0fb54de9aa4ffb792ea63af853146021ae501f12    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 29 Apr 2016 07:59:47 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 29 Apr 2016 07:59:47 -0400    

Click here for diff

  
Adjust the way we detect the locale. As a result the minumum Windows  
version supported by VS2015 and later is Windows Vista. Add some tweaks  
to remove new compiler warnings. Remove documentation references to the  
now obsolete msysGit.  
  
Michael Paquier, somewhat edited by me, reviewed by Christian Ullrich.  
  
Backpatch to 9.5  
  

Remember asking for feedback during walsender shutdown.

  
commit   : 59455018a8120bb3c02680b0f9764492c5283d99    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 28 Apr 2016 22:05:37 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 28 Apr 2016 22:05:37 -0700    

Click here for diff

  
Since 5a991ef8 we're explicitly asking for feedback from the receiving  
side when shutting down walsender, if there's not yet replicated  
data.  
  
Unfortunately we didn't remember (i.e. set waiting_for_ping_response to  
true) having asked for feedback, leading to scenarios in which replies  
were requested at a high frequency.  
  
I can't reproduce this problem on my laptop, I think that's because the  
problem requires a significant TCP window to manifest due to the  
!pq_is_send_pending() condition. But since this clearly is a bug, let's  
fix it.  There's quite possibly more wrong than just this though.  
  
While fiddling with WalSndDone(), I rewrote a hard to understand comment  
about looking at the flush vs. the write position.  
  
Reported-By: Nick Cleaton, Magnus Hagander  
Author: Nick Cleaton  
Discussion: CAFgz3kus=rC_avEgBV=+hRK5HYJ8vXskJRh8yEAbahJGTzF2VQ@mail.gmail.com  
    CABUevExsjROqDcD0A2rnJ6HK6FuKGyewJr3PL12pw85BHFGS2Q@mail.gmail.com  
Backpatch: 9.4, were 5a991ef8 introduced the use of feedback messages  
    during shutdown.  
  

Adjust DatumGetBool macro, this time for sure.

  
commit   : 23b09e15b9f40baeff527ca4dbc40afc823dd962    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Apr 2016 11:50:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Apr 2016 11:50:58 -0400    

Click here for diff

  
Commit 23a41573c attempted to fix the DatumGetBool macro to ignore bits  
in a Datum that are to the left of the actual bool value.  But it did that  
by casting the Datum to bool; and on compilers that use C99 semantics for  
bool, that ends up being a whole-word test, not a 1-byte test.  This seems  
to be the true explanation for contrib/seg failing in VS2015.  To fix, use  
GET_1_BYTE() explicitly.  I think in the previous patch, I'd had some idea  
of not having to commit to bool being exactly 1 byte wide, but regardless  
of what the compiler's bool is, boolean columns and Datums are certainly  
1 byte wide.  
  
The previous fix was (eventually) back-patched into all active versions,  
so do likewise with this one.  
  

Revert “Convert contrib/seg’s bool-returning SQL functions to V1 call convention.”

  
commit   : f050423052bc9265d4cd27555058435edd4bef87    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Apr 2016 11:46:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Apr 2016 11:46:07 -0400    

Click here for diff

  
This reverts commit c8e81afc60093b199a128ccdfbb692ced8e0c9cd.  
That turns out to have been based on a faulty diagnosis of why the  
VS2015 build was misbehaving.  Instead, we need to fix DatumGetBool().  
  

Prevent to use magic constants

  
commit   : f8467f7da8685dbc47187864e5afe130d9c63fff    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Thu, 28 Apr 2016 16:39:25 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Thu, 28 Apr 2016 16:39:25 +0300    

Click here for diff

  
Use macroses for definition amstrategies/amsupport fields instead of  
hardcoded values.  
  
Author: Nikolay Shaplov with addition for contrib/bloom  
  

Prevent multiple cleanup process for pending list in GIN.

  
commit   : e2c79e14d998cd31f860854bc9210b37b457bb01    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Thu, 28 Apr 2016 16:21:42 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Thu, 28 Apr 2016 16:21:42 +0300    

Click here for diff

  
Previously, ginInsertCleanup could exit early if it detects that someone else  
is cleaning up the pending list, without waiting for that someone else to  
finish the job. But in this case vacuum could miss tuples to be deleted.  
  
Cleanup process now locks metapage with a help of heavyweight  
LockPage(ExclusiveLock), and it guarantees that there is no another cleanup  
process at the same time. Lock is taken differently depending on caller of  
cleanup process: any vacuums and gin_clean_pending_list() will be blocked  
until lock becomes available, ordinary insert uses conditional lock to  
prevent indefinite waiting on lock.  
  
Insert into pending list doesn't use this lock, so insertion isn't blocked.  
  
Also, patch adds stopping of cleanup process when at-start-cleanup-tail is  
reached in order to prevent infinite cleanup in case of massive insertion. But  
it will stop only for automatic maintenance tasks like autovacuum.  
  
Patch introduces choice of limit of memory to use: autovacuum_work_mem,  
maintenance_work_mem or work_mem depending on call path.  
  
Patch for previous releases should be reworked due to changes between 9.6 and  
previous ones in this area.  
  
Discover and diagnostics by Jeff Janes and Tomas Vondra  
  
Patch by me with some ideas of Jeff Janes  
  

Use memmove() not memcpy() to slide some pointers down.

  
commit   : ad520ec4acb8f0cdb143b63519be95a9549fa826    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Apr 2016 18:19:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Apr 2016 18:19:28 -0400    

Click here for diff

  
The previous coding here was formally undefined, though it seems to  
accidentally work on most platforms in the buildfarm.  Caught by some  
OpenBSD platforms in which libc contains an assertion check for  
overlapping areas passed to memcpy().  
  
Thomas Munro  
  

Clean up parsing of synchronous_standby_names GUC variable.

  
commit   : 4c804fbdfb472cf71db33609258b8e1aaad81943    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Apr 2016 17:55:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Apr 2016 17:55:19 -0400    

Click here for diff

  
Commit 989be0810dffd08b added a flex/bison lexer/parser to interpret  
synchronous_standby_names.  It was done in a pretty crufty way, though,  
making assorted end-use sites responsible for calling the parser at the  
right times.  That was not only vulnerable to errors of omission, but made  
it possible that lexer/parser errors occur at very undesirable times,  
and created memory leakages even if there was no error.  
  
Instead, perform the parsing once during check_synchronous_standby_names  
and let guc.c manage the resulting data.  To do that, we have to flatten  
the parsed representation into a single hunk of malloc'd memory, but that  
is not very hard.  
  
While at it, work a little harder on making useful error reports for  
parsing problems; the previous code felt that "synchronous_standby_names  
parser returned 1" was an appropriate user-facing error message.  (To  
be fair, it did also log a syntax error message, but separately from the  
GUC problem report, which is at best confusing.)  It had some outright  
bugs in the face of invalid input, too.  
  
I (tgl) also concluded that we need to restrict unquoted names in  
synchronous_standby_names to be just SQL identifiers.  The previous coding  
would accept darn near anything, which (1) makes the quoting convention  
both nearly-unnecessary and formally ambiguous, (2) makes it very hard to  
understand what is a syntax error and what is a creative interpretation of  
the input as a standby name, and (3) makes it impossible to further extend  
the syntax in future without a compatibility break.  I presume that we're  
intending future extensions of the syntax, else this parsing infrastructure  
is massive overkill, so (3) is an important objection.  Since we've taken  
a compatibility hit for non-identifier names with this change anyway, we  
might as well lock things down now and insist that users use double quotes  
for standby names that aren't identifiers.  
  
Kyotaro Horiguchi and Tom Lane  
  

Fix wrong word.

  
commit   : 372ff7cae254ac110e2dd25f81cb000c61b60413    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 14:23:56 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 14:23:56 -0400    

Click here for diff

  
Commit a31212b429cd3397fb3147b1a584ae33224454a6 was a little too hasty.  
  
Per report from Tom Lane.  
  

Change postgresql.conf.sample to say that fsync=off will corrupt data.

  
commit   : a31212b429cd3397fb3147b1a584ae33224454a6    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 13:46:26 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 13:46:26 -0400    

Click here for diff

  
Discussion: 24748.1461764666@sss.pgh.pa.us  
  
Per a suggestion from Craig Ringer.  This wording from Tom Lane,  
following discussion.  
  

Tighten up sanity checks for parallel aggregate in execQual.c.

  
commit   : cf402ba7340f66defe25bffa8621a54fd579196e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 12:05:35 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 12:05:35 -0400    

Click here for diff

  
David Rowley  
  

Remove inadvertently commited vim swapfile.

  
commit   : b33dc7766509be27bda62a8de7889b26dc2a366c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 11:53:01 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 11:53:01 -0400    

Click here for diff

  
If you were wondering what editor I use, now you know.  
  

Update typedefs.list file in preparation for pgindent run

  
commit   : acb51bd71d16921cc18cd434d8e70ab0705d6856    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 11:47:28 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 11:47:28 -0400    

Click here for diff

  
In addition to adding new typedefs, I also re-sorted the file so that  
various entries add piecemeal, mostly or entirely by me, were alphabetized  
the same way as other entries in the file.  
  

  
commit   : 8126eaee2fed7cbc4e9fd6ba8713977ccacd77fe    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 11:29:45 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 11:29:45 -0400    

Click here for diff

  
In nodeFuncs.c, pgindent wants to introduce spurious indentation into  
the definitions of planstate_tree_walker and planstate_walk_subplans.  
Fix that by spreading the definition out across several lines, similar  
to what is already done for other walker functions in that file.  
  
In execParallel.c, in the definition of SharedExecutorInstrumentation,  
pgindent wants to insert more whitespace between the type name and the  
member name.  That causes it to mangle comments later on the line.  Fix  
by moving the comments out of line.  Now that we have a bit more room,  
add some more details that may be useful to the next person reading  
this code.  
  

Remove mergeHyperLogLog.

  
commit   : 360ca27a9b9793f3939c9f70de77c1272a110362    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 10:55:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 10:55:32 -0400    

Click here for diff

  
It's buggy.  If somebody needs this later, they'll need to put back  
a non-buggy vesion of it.  
  
Discussion: CAM3SWZT-i6R9JU5YXa8MJUou2_r3LfGJZpQ9tYa1BYxfkj0=cQ@mail.gmail.com  
Discussion: CAM3SWZRUOLsYoTT83QgdUy9D8ehYWm_nvbrrfcOOzikiRfFY7g@mail.gmail.com  
  
Peter Geoghegan  
  

Fix EXPLAIN VERBOSE output for parallel aggregate.

  
commit   : 59eb55127906b943ff155240eebc161df8edb62f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 07:33:33 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Apr 2016 07:33:33 -0400    

Click here for diff

  
The way that PartialAggregate and FinalizeAggregate plan nodes were  
displaying output columns before was bogus.  Now, FinalizeAggregate  
produces the same outputs as an Aggregate would have produced, while  
PartialAggregate produces each of those outputs prefixed by the word  
PARTIAL.  
  
Discussion: 12585.1460737650@sss.pgh.pa.us  
  
Patch by me, reviewed by David Rowley.  
  

Don’t open formally non-existent segments in _mdfd_getseg().

  
commit   : 72a98a639574d2e25ed94652848555900c81a799    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 26 Apr 2016 20:32:51 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 26 Apr 2016 20:32:51 -0700    

Click here for diff

  
Before this commit _mdfd_getseg(), in contrast to mdnblocks(), did not  
verify whether all segments leading up to the to-be-opened one, were  
RELSEG_SIZE sized. That is e.g. not the case after truncating a  
relation, because later segments just get truncated to zero length, not  
removed.  
  
Once a "non-existent" segment has been opened in a session, mdnblocks()  
will return wrong results, causing errors like "could not read block %u  
in file" when accessing blocks. Closing the session, or the later  
arrival of relevant invalidation messages, would "fix" the problem.  
  
That, so far, was mostly harmless, because most segment accesses are  
only done after an mdnblocks() call. But since 428b1d6b29ca we try to  
open segments that might have been deleted, to trigger kernel writeback  
from a backend's queue of recent writes.  
  
To fix check segment sizes in _mdfd_getseg() when opening previously  
unopened segments. In practice this shouldn't imply a lot of additional  
lseek() calls, because mdnblocks() will most of the time already have  
opened all relevant segments.  
  
This commit also fixes a second problem, namely that _mdfd_getseg(  
EXTENSION_RETURN_NULL) extends files during recovery, which is not  
desirable for the mdwriteback() case.  Add EXTENSION_REALLY_RETURN_NULL,  
which does not behave that way, and use it.  
  
Reported-By: Thom Brown  
Author: Andres Freund, Abhijit Menon-Sen  
Reviewd-By: Robert Haas, Fabien Coehlo  
Discussion: CAA-aLv6Dp_ZsV-44QA-2zgkqWKQq=GedBX2dRSrWpxqovXK=Pg@mail.gmail.com  
Fixes: 428b1d6b29ca599c5700d4bc4f4ce4c5880369bf  
  

Emit invalidations to standby for transactions without xid.

  
commit   : c6ff84b06a68b71719aa1aaa5f6704d8db1b51f8    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 23 Apr 2016 19:18:00 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 23 Apr 2016 19:18:00 -0700    

Click here for diff

  
So far, when a transaction with pending invalidations, but without an  
assigned xid, committed, we simply ignored those invalidation  
messages. That's problematic, because those are actually sent for a  
reason.  
  
Known symptoms of this include that existing sessions on a hot-standby  
replica sometimes fail to notice new concurrently built indexes and  
visibility map updates.  
  
The solution is to WAL log such invalidations in transactions without an  
xid. We considered to alternatively force-assign an xid, but that'd be  
problematic for vacuum, which might be run in systems with few xids.  
  
Important: This adds a new WAL record, but as the patch has to be  
back-patched, we can't bump the WAL page magic. This means that standbys  
have to be updated before primaries; otherwise  
"PANIC: standby_redo: unknown op code 32" errors can be encountered.  
  
XXX:  
  
Reported-By: Васильев Дмитрий, Masahiko Sawada  
Discussion:  
    CAB-SwXY6oH=9twBkXJtgR4UC1NqT-vpYAtxCseME62ADwyK5OA@mail.gmail.com  
    CAD21AoDpZ6Xjg=gFrGPnSn4oTRRcwK1EBrWCq9OqOHuAcMMC=w@mail.gmail.com  
  

Fix pg_get_functiondef to dump parallel-safety markings.

  
commit   : 2ac3be2e763d9b971352819f285dd51519e0aeb9    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 26 Apr 2016 22:56:04 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 26 Apr 2016 22:56:04 -0400    

Click here for diff

  
Ashutosh Sharma  
  

Impose a full barrier in generic-xlc.h atomics functions.

  
commit   : 213c7df0337278c71c98e90605dc83023db1a80e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 26 Apr 2016 21:53:58 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 26 Apr 2016 21:53:58 -0400    

Click here for diff

  
pg_atomic_compare_exchange_*_impl() were providing only the semantics of  
an acquire barrier.  Buildfarm members hornet and mandrill revealed this  
deficit beginning with commit 008608b9d51061b1f598c197477b3dc7be9c4a64.  
While we have no report of symptoms in 9.5, we can't rule out the  
possibility of certain compilers, hardware, or extension code relying on  
these functions' specified barrier semantics.  Back-patch to 9.5, where  
commit b64d92f1a5602c55ee8b27a7ac474f03b7aee340 introduced atomics.  
  
Reviewed by Andres Freund.  
  

pg_dump: Message style improvements

  
commit   : 3019f432d6fffe6d8e04f5ccc592eb385af96492    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 26 Apr 2016 12:04:43 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 26 Apr 2016 12:04:43 -0400    

Click here for diff

  
forgotten in b6dacc173b6830c515d970698cead9a85663c553  
  

Add a –brief option to git_changelog.

  
commit   : 8067c8f86b5f4516ee204a119a750329f7d126ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Apr 2016 18:52:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Apr 2016 18:52:17 -0400    

Click here for diff

  
In commit c0b050192, Andres introduced the idea of including one-line  
commit references in our major release notes.  Teach git_changelog to  
emit a (lightly adapted) version of that format, so that we don't  
have to laboriously add it to the notes after the fact.  The default  
output isn't changed, since I anticipate still using that for minor  
release notes.  
  

Fix tsearch docs

  
commit   : f1e3c76066f0066a8a9bb09b80cd97f11e4b2dc4    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Tue, 26 Apr 2016 20:26:26 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Tue, 26 Apr 2016 20:26:26 +0300    

Click here for diff

  
Remove mention of setweight(tsquery) which wasn't included in 9.6. Also  
replace old forgotten phrase operator to new one.  
  
Dmitry Ivanov  
  

Fix order of shutdown cleanup operations in PostgresNode.pm.

  
commit   : 08af9219060a9526c69f5408b80eee0aa8f707e9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Apr 2016 12:43:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Apr 2016 12:43:03 -0400    

Click here for diff

  
Previously, database clusters created by a TAP test were shut down by  
DESTROY methods attached to the PostgresNode objects representing them.  
The trouble with that is that if the objects survive into the final global  
destruction phase (which they do), Perl executes the DESTROY methods in an  
unspecified order.  Thus, the order of shutdown of multiple clusters was  
indeterminate, which might lead to not-very-reproducible errors getting  
logged (eg from a slave whose master might or might not get killed first).  
Worse, the File::Temp objects representing the temporary PGDATA directories  
might get destroyed before the PostgresNode objects, resulting in attempts  
to delete PGDATA directories that still have live servers in them.  On  
Windows, this would lead to directory deletion failures; on Unix, it  
usually had no effects worse than erratic "could not open temporary  
statistics file "pg_stat/global.tmp": No such file or directory" log  
messages.  
  
While none of this would affect the reported result of the TAP test, which  
is already determined, it could be very confusing when one is trying to  
understand from the logs what went wrong with a failed test.  
  
To fix, do the postmaster shutdowns in an END block rather than at object  
destruction time.  The END block will execute at a well-defined (and  
reasonable) time during script termination, and it will stop the  
postmasters in order of PostgresNode object creation.  (Perhaps we should  
change that to be reverse order of creation, but the main point here is  
that we now have control which we did not before.)  Use "pg_ctl stop", not  
an asynchronous kill(SIGQUIT), so that we wait for the postmasters to shut  
down before proceeding with directory deletion.  
  
Deletion of temporary directories still happens in an unspecified order  
during global destruction, but I can see no reason to care about that  
once the postmasters are stopped.  
  

Yet more portability hacking for degree-based trig functions.

  
commit   : 82311bcdd76904b2cee7567e14e9fb0cf6c6178c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Apr 2016 11:24:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Apr 2016 11:24:15 -0400    

Click here for diff

  
The true explanation for Peter Eisentraut's report of inexact asind results  
seems to be that (a) he's compiling into x87 instruction set, which uses  
wider-than-double float registers, plus (b) the library function asin() on  
his platform returns a result that is wider than double and is not rounded  
to double width.  To fix, we have to force the function's result to be  
rounded comparably to what happened to the scaling constant asin_0_5.  
Experimentation suggests that storing it into a volatile local variable is  
the least ugly way of making that happen.  Although only asin() is known to  
exhibit an observable inexact result, we'd better do this in all the places  
where we're hoping to get an exact result by scaling.  
  

Enable parallel query by default.

  
commit   : 77cd477c4ba885cfa1ba67beaa82e06f2e182b85    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 26 Apr 2016 08:31:38 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 26 Apr 2016 08:31:38 -0400    

Click here for diff

  
Change max_parallel_degree default from 0 to 2.  It is possible that  
this is not a good idea, or that we should go with 1 worker rather  
than 2, but we won't find out without trying it.  Along the way,  
reword the documentation for max_parallel_degree a little bit to  
hopefully make it more clear.  
  
Discussion: 20160420174631.3qjjhpwsvvx5bau5@alap3.anarazel.de  
  

Fix typo in comment

  
commit   : b7351ced425f3937f0a61adb4ade1d4b93bf751d    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 26 Apr 2016 10:38:32 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 26 Apr 2016 10:38:32 +0200    

Click here for diff

  
Author: Daniel Gustafsson  
  

pg_dump: Message style improvements

  
commit   : b6dacc173b6830c515d970698cead9a85663c553    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 25 Apr 2016 17:16:59 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 25 Apr 2016 17:16:59 -0400    

Click here for diff

  
  

Fix C comment typo and redundant test

  
commit   : e65953be4f540dce31f17db2934ee58365077272    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Mon, 25 Apr 2016 15:42:29 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Mon, 25 Apr 2016 15:42:29 -0500    

Click here for diff

  
  

New method for preventing compile-time calculation of degree constants.

  
commit   : 6b1a213bbd6599228b2b67f7552ff7cc378797bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Apr 2016 15:21:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Apr 2016 15:21:04 -0400    

Click here for diff

  
Commit 65abaab547a5758b tried to prevent the scaling constants used in  
the degree-based trig functions from being precomputed at compile time,  
because some compilers do that with functions that don't yield results  
identical-to-the-last-bit to what you get at runtime.  A report from  
Peter Eisentraut suggests that some recent compilers are smart enough  
to see through that trick, though.  Instead, let's put the inputs to  
these calculations into non-const global variables, which should be a  
more reliable way of convincing the compiler that it can't assume that  
they are compile-time constants.  (If we really get desperate, we could  
mark these variables "volatile", but I do not believe we should have to.)  
  

Try harder to detect a port conflict in PostgresNode.pm.

  
commit   : 40e89e2ab89cb2801f6bc02f08dcc24d547530fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Apr 2016 12:28:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Apr 2016 12:28:49 -0400    

Click here for diff

  
Commit fab84c7787f25756 tried to get away without doing an actual bind(),  
but buildfarm results show that that doesn't get the job done.  So we must  
really bind to the target port --- and at least on my Linux box, we need a  
listen() as well, or conflicts won't be detected.  We rely on SO_REUSEADDR  
to prevent problems from starting a postmaster on the socket immediately  
after we've bound to it in the test code.  (There may be platforms where  
that doesn't work too well.  But fortunately, we only really care whether  
this works on Windows, and there the default behavior should be OK.)  
  

Update GETTEXT_FILES after config and controldata refactoring

  
commit   : 63417b4b2e38897ea02fef416bd96113baa3ed45    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 24 Apr 2016 20:58:11 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 24 Apr 2016 20:58:11 -0400    

Click here for diff

  
  

doc: Fix typo

  
commit   : 96687497b640b24772da4e086c7690ee8d840f1c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 24 Apr 2016 20:44:22 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 24 Apr 2016 20:44:22 -0400    

Click here for diff

  
From: Andreas Seltenreich <andreas.seltenreich@credativ.de>  
  

Improve PostgresNode.pm’s logic for detecting already-in-use ports.

  
commit   : fab84c7787f25756a9d7bcb8bc89145d237e8e85    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Apr 2016 15:31:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Apr 2016 15:31:36 -0400    

Click here for diff

  
Buildfarm members bowerbird and jacana have shown intermittent "could not  
bind IPv4 socket" failures in the BinInstallCheck stage since mid-December,  
shortly after commits 1caef31d9e550408 and 9821492ee417a591 changed the  
logic for selecting which port to use in temporary installations.  One  
plausible explanation is that we are randomly selecting ports that are  
already in use for some non-Postgres purpose.  Although the code tried  
to defend against already-in-use ports, it used pg_isready to probe  
the port which is quite unhelpful: if some non-Postgres server responds  
at the given address, pg_isready will generally say "no response",  
leading to exactly the wrong conclusion about whether the port is free.  
  
Instead, let's use a simple TCP connect() call to see if anything answers  
without making assumptions about what it is.  Note that this means there's  
no direct check for a conflicting Unix socket, but that should be okay  
because there should be no other Unix sockets in use in the temporary  
socket directory created for a test run.  
  
This is only a partial solution for the TCP case, since if the port number  
is in use for an outgoing connection rather than a listening socket, we'll  
fail to detect that.  We could try to bind() to the proposed port as a  
means of detecting that case, but that would introduce its own failure  
modes, since the system might consider the address to remain reserved for  
some period of time after we drop the bound socket.  Close study of the  
errors returned by bowerbird and jacana suggests that what we're seeing  
there may be conflicts with listening not outgoing sockets, so let's try  
this and see if it improves matters.  It's certainly better than what's  
there now, in any case.  
  
Michael Paquier, adjusted by me to work on non-Windows as well as Windows  
  

Fix documentation & config inconsistencies around 428b1d6b2.

  
commit   : 8f91d87d43d021db92c6edd966a4bb8c3a81ae39    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 24 Apr 2016 12:26:55 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 24 Apr 2016 12:26:55 -0700    

Click here for diff

  
Several issues:  
1) checkpoint_flush_after doc and code disagreed about the default  
2) new GUCs were missing from postgresql.conf.sample  
3) Outdated source-code comment about bgwriter_flush_after's default  
4) Sub-optimal categories assigned to new GUCs  
5) Docs suggested backend_flush_after is PGC_SIGHUP, but it's PGC_USERSET.  
6) Spell out int as integer in the docs, as done elsewhere  
  
Reported-By: Magnus Hagander, Fujii Masao  
Discussion: CAHGQGwETyTG5VYQQ5C_srwxWX7RXvFcD3dKROhvAWWhoSBdmZw@mail.gmail.com  
  

Rename strtoi() to strtoint().

  
commit   : 0ab3595e5bb53a8fc2cd231320b1af1ae3ed68e0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Apr 2016 16:53:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Apr 2016 16:53:15 -0400    

Click here for diff

  
NetBSD has seen fit to invent a libc function named strtoi(), which  
conflicts with the long-established static functions of the same name in  
datetime.c and ecpg's interval.c.  While muttering darkly about intrusions  
on application namespace, we'll rename our functions to avoid the conflict.  
  
Back-patch to all supported branches, since this would affect attempts  
to build any of them on recent NetBSD.  
  
Thomas Munro  
  

doc: Fix typos

  
commit   : b87b2f4bda1a3b98f8dea867b8bc419ace7a9ea9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 23 Apr 2016 14:48:02 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 23 Apr 2016 14:48:02 -0400    

Click here for diff

  
From: Erik Rijkers <er@xs4all.nl>  
  

Properly mark initRectBox() as taking ‘void’ args

  
commit   : 915cee4595060fd536a7c997e37e4a535c3e0d4f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 Apr 2016 10:41:11 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 Apr 2016 10:41:11 -0400    

Click here for diff

  
Was part of box type in SP-GiST index patch.  
  
Reported-by: Emre Hasegeli  
  

Convert contrib/seg’s bool-returning SQL functions to V1 call convention.

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

Click here for diff

  
It appears that we can no longer get away with using V0 call convention  
for bool-returning functions in newer versions of MSVC.  The compiler  
seems to generate code that doesn't clear the higher-order bits of the  
result register, causing the bool result Datum to often read as "true"  
when "false" was intended.  This is not very surprising, since the  
function thinks it's returning a bool-width result but fmgr_oldstyle  
assumes that V0 functions return "char *"; what's surprising is that  
that hack worked for so long on so many platforms.  
  
The only functions of this description in core+contrib are in contrib/seg,  
which we'd intentionally left mostly in V0 style to serve as a warning  
canary if V0 call convention breaks.  We could imagine hacking things  
so that they're still V0 (we'd have to redeclare the bool-returning  
functions as returning some suitably wide integer type, like size_t,  
at the C level).  But on the whole it seems better to convert 'em to V1.  
We can still leave the pointer- and int-returning functions in V0 style,  
so that the test coverage isn't gone entirely.  
  
Back-patch to 9.5, since our intention is to support VS2015 in 9.5  
and later.  There's no SQL-level change in the functions' behavior  
so back-patching should be safe enough.  
  
Discussion: <22094.1461273324@sss.pgh.pa.us>  
  
Michael Paquier, adjusted some by me  
  

Add putenv support for msvcrt from Visual Studio 2013

  
commit   : 9f633b404cb3be6139f8dfdea00538489ffef9ab    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 22 Apr 2016 05:18:59 -0400    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 22 Apr 2016 05:18:59 -0400    

Click here for diff

  
This was missed when VS 2013 support was added.  
  
Michael Paquier  
  

Fix unexpected side-effects of operator_precedence_warning.

  
commit   : abb164655c703a5013b7fcf83f855a071895dc91    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 23:17:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 23:17:36 -0400    

Click here for diff

  
The implementation of that feature involves injecting nodes into the  
raw parsetree where explicit parentheses appear.  Various places in  
parse_expr.c that test to see "is this child node of type Foo" need to  
look through such nodes, else we'll get different behavior when  
operator_precedence_warning is on than when it is off.  Note that we only  
need to handle this when testing untransformed child nodes, since the  
AEXPR_PAREN nodes will be gone anyway after transformExprRecurse.  
  
Per report from Scott Ribe and additional code-reading.  Back-patch  
to 9.5 where this feature was added.  
  
Report: <ED37E303-1B0A-4CD8-8E1E-B9C4C2DD9A17@elevated-dev.com>  
  

Fix planner failure with full join in RHS of left join.

  
commit   : 80f66a9ad06eafa91ffc5ff19c725c7f393c242e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 20:05:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 20:05:58 -0400    

Click here for diff

  
Given a left join containing a full join in its righthand side, with  
the left join's joinclause referencing only one side of the full join  
(in a non-strict fashion, so that the full join doesn't get simplified),  
the planner could fail with "failed to build any N-way joins" or related  
errors.  This happened because the full join was seen as overlapping the  
left join's RHS, and then recent changes within join_is_legal() caused  
that function to conclude that the full join couldn't validly be formed.  
Rather than try to rejigger join_is_legal() yet more to allow this,  
I think it's better to fix initsplan.c so that the required join order  
is explicit in the SpecialJoinInfo data structure.  The previous coding  
there essentially ignored full joins, relying on the fact that we don't  
flatten them in the joinlist data structure to preserve their ordering.  
That's sufficient to prevent a wrong plan from being formed, but as this  
example shows, it's not sufficient to ensure that the right plan will  
be formed.  We need to work a bit harder to ensure that the right plan  
looks sane according to the SpecialJoinInfos.  
  
Per bug #14105 from Vojtech Rylko.  This was apparently induced by  
commit 8703059c6 (though now that I've seen it, I wonder whether there  
are related cases that could have failed before that); so back-patch  
to all active branches.  Unfortunately, that patch also went into 9.0,  
so this bug is a regression that won't be fixed in that branch.  
  

Improve TranslateSocketError() to handle more Windows error codes.

  
commit   : 125ad539a275db5ab8f4647828b80a16d02eabd2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 16:58:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 16:58:47 -0400    

Click here for diff

  
The coverage was rather lean for cases that bind() or listen() might  
return.  Add entries for everything that there's a direct equivalent  
for in the set of Unix errnos that elog.c has heard of.  
  

Remove dead code in win32.h.

  
commit   : e54528155a3c4159b01327534691c3342a371cab    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 16:16:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 16:16:19 -0400    

Click here for diff

  
There's no longer a need for the MSVC-version-specific code stanza that  
forcibly redefines errno code symbols, because since commit 73838b52 we're  
unconditionally redefining them in the stanza before this one anyway.  
Now it's merely confusing and ugly, so get rid of it; and improve the  
comment that explains what's going on here.  
  
Although this is just cosmetic, back-patch anyway since I'm intending  
to back-patch some less-cosmetic changes in this same hunk of code.  
  

PGDLLIMPORT-ify old_snapshot_threshold.

  
commit   : 14216649f3dc8bd9839702440dd593e958b0920b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 14:33:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 14:33:34 -0400    

Click here for diff

  
Revert commit 7cb1db1d9599f0a09d6920d2149d956ef6d88b0e, which represented  
a misunderstanding of the problem (if snapmgr.h weren't already included  
in bufmgr.h, things wouldn't compile anywhere).  Instead install what  
I think is the real fix.  
  

  
commit   : 1f7c85b820814810f985a270e92cde4c12ceded4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 14:20:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 14:20:18 -0400    

Click here for diff

  
When we shoehorned "x op ANY (array)" into the SQL syntax, we created a  
fundamental ambiguity as to the proper treatment of a sub-SELECT on the  
righthand side: perhaps what's meant is to compare x against each row of  
the sub-SELECT's result, or perhaps the sub-SELECT is meant as a scalar  
sub-SELECT that delivers a single array value whose members should be  
compared against x.  The grammar resolves it as the former case whenever  
the RHS is a select_with_parens, making the latter case hard to reach ---  
but you can get at it, with tricks such as attaching a no-op cast to the  
sub-SELECT.  Parse analysis would throw away the no-op cast, leaving a  
parsetree with an EXPR_SUBLINK SubLink directly under a ScalarArrayOpExpr.  
ruleutils.c was not clued in on this fine point, and would naively emit  
"x op ANY ((SELECT ...))", which would be parsed as the first alternative,  
typically leading to errors like "operator does not exist: text = text[]"  
during dump/reload of a view or rule containing such a construct.  To fix,  
emit a no-op cast when dumping such a parsetree.  This might well be  
exactly what the user wrote to get the construct accepted in the first  
place; and even if she got there with some other dodge, it is a valid  
representation of the parsetree.  
  
Per report from Karl Czajkowski.  He mentioned only a case involving  
RLS policies, but actually the problem is very old, so back-patch to  
all supported branches.  
  
Report: <20160421001832.GB7976@moraine.isi.edu>  
  

Prevent possible crash reading pg_stat_activity.

  
commit   : c4a586c4860477ddae6d4f9cef88486f0e37c37e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 21 Apr 2016 14:02:15 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 21 Apr 2016 14:02:15 -0400    

Click here for diff

  
Also, avoid reading PGPROC's wait_event field twice, once for the wait  
event and again for the wait_event_type, because the value might change  
in the middle.  
  
Petr Jelinek and Robert Haas  
  

Comment improvements for ForeignPath.

  
commit   : 36f69faeff540cd93de0b6aa7c2d2a7781d637a6    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 21 Apr 2016 13:30:48 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 21 Apr 2016 13:30:48 -0400    

Click here for diff

  
It's not necessarily just scanning a base relation any more.  
  
Amit Langote and Etsuro Fujita  
  

Fix assorted defects in 09adc9a8c09c9640de05c7023b27fb83c761e91c.

  
commit   : 9f84280ae94b43b75dcf32aef433545335e7bb16    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 21 Apr 2016 13:24:09 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 21 Apr 2016 13:24:09 -0400    

Click here for diff

  
That commit increased all shared memory allocations to the next higher  
multiple of PG_CACHE_LINE_SIZE, but it didn't ensure that allocation  
started on a cache line boundary.  It also failed to remove a couple  
other pieces of now-useless code.  
  
BUFFERALIGN() is perhaps obsolete at this point, and likely should be  
removed at some point, too, but that seems like it can be left to a  
future cleanup.  
  
Mistakes all pointed out by Andres Freund.  The patch is mine, with  
a few extra assertions which I adopted from his version of this fix.  
  

Include snapmgr.h in blscan.c

  
commit   : 7cb1db1d9599f0a09d6920d2149d956ef6d88b0e    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Thu, 21 Apr 2016 11:51:20 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Thu, 21 Apr 2016 11:51:20 -0500    

Click here for diff

  
Windows builds on buildfarm are failing because  
old_snapshot_threshold is not found in the bloom filter contrib  
module.  
  

Allow queries submitted by postgres_fdw to be canceled.

  
commit   : f039eaac7131ef2a4cf63a10cf98486f8bcd09d2    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 21 Apr 2016 10:46:09 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 21 Apr 2016 10:46:09 -0400    

Click here for diff

  
This fixes a problem which is not new, but with the advent of direct  
foreign table modification in 0bf3ae88af330496517722e391e7c975e6bad219,  
it's somewhat more likely to be annoying than previously.  So,  
arrange for a local query cancelation to propagate to the remote side.  
  
Michael Paquier, reviewed by Etsuro Fujita.	 Original report by  
Thom Brown.  
  

Inline initial comparisons in TestForOldSnapshot()

  
commit   : 11e178d0dc4bc2328ae4759090b3c48b07023fab    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Thu, 21 Apr 2016 08:40:08 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Thu, 21 Apr 2016 08:40:08 -0500    

Click here for diff

  
Even with old_snapshot_threshold = -1 (which disables the "snapshot  
too old" feature), performance regressions were seen at moderate to  
high concurrency.  For example, a one-socket, four-core system  
running 200 connections at saturation could see up to a 2.3%  
regression, with larger regressions possible on NUMA machines.  
By inlining the early (smaller, faster) tests in the  
TestForOldSnapshot() function, the i7 case dropped to a 0.2%  
regression, which could easily just be noise, and is clearly an  
improvement.  Further testing will show whether more is needed.  
  

postgres_fdw: Don’t push down certain full joins.

  
commit   : 5b1f9ce1d9e8dcae2bcd93b2becffaba5e4f3049    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Apr 2016 23:34:07 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Apr 2016 23:34:07 -0400    

Click here for diff

  
If there's a filter condition on either side of a full outer join,  
it is neither correct to attach it to the join's ON clause nor to  
throw it into the toplevel WHERE clause.  Just don't push down the  
join in that case.  
  
To maximize the number of cases where we can still push down full  
joins, push inner join conditions into the ON clause at the first  
opportunity rather than postponing them to the top-level WHERE  
clause.  This produces nicer SQL, anyway.  
  
This bug was introduced in e4106b2528727c4b48639c0e12bf2f70a766b910.  
  
Ashutosh Bapat, per report from Rajkumar Raghuwanshi.  
  

Honor PGCTLTIMEOUT environment variable for pg_regress’ startup wait.

  
commit   : cbabb70f35bb0e5bac84b9f15ecadc82868ad9f9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Apr 2016 23:48:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Apr 2016 23:48:13 -0400    

Click here for diff

  
In commit 2ffa86962077c588 we made pg_ctl recognize an environment variable  
PGCTLTIMEOUT to set the default timeout for starting and stopping the  
postmaster.  However, pg_regress uses pg_ctl only for the "stop" end of  
that; it has bespoke code for starting the postmaster, and that code has  
historically had a hard-wired 60-second timeout.  Further buildfarm  
experience says it'd be a good idea if that timeout were also controlled  
by PGCTLTIMEOUT, so let's make it so.  Like the previous patch, back-patch  
to all active branches.  
  
Discussion: <13969.1461191936@sss.pgh.pa.us>  
  

Add pg_dump support for the new PARALLEL option for aggregates.

  
commit   : b4e0f183826e85fd43248d5047eddf393c3d8a30    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Apr 2016 22:47:20 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Apr 2016 22:47:20 -0400    

Click here for diff

  
This was an oversight in commit 41ea0c23761ca108e2f08f6e3151e3cb1f9652a1.  
  
Fabrízio de Royes Mello, per a report from Tushar Ahuja  
  

Forbid parallel Hash Right Join or Hash Full Join.

  
commit   : 9c75e1a36b6b2f3ad9f76ae661f42586c92c6f7c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Apr 2016 17:48:55 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Apr 2016 17:48:55 -0400    

Click here for diff

  
That won't work.  You'll get bogus null-extended rows.  
  
Mithun Cy  
  

Update backup documentation for new APIs

  
commit   : cfb863f20a2a005ac89f393265d4c37ad9baab41    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Apr 2016 14:40:04 -0400    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Apr 2016 14:40:04 -0400    

Click here for diff

  
This includes the rest of the documentation that was not included  
in 7117685. A larger restructure would still be wanted, but with  
this commit the documentation of the new features is complete.  
  

Fix memory leak and other bugs in ginPlaceToPage() & subroutines.

  
commit   : bde361fef5ea3c65074a0c95c724fae5ac8a1bb5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Apr 2016 14:25:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Apr 2016 14:25:15 -0400    

Click here for diff

  
Commit 36a35c550ac114ca turned the interface between ginPlaceToPage and  
its subroutines in gindatapage.c and ginentrypage.c into a royal mess:  
page-update critical sections were started in one place and finished in  
another place not even in the same file, and the very same subroutine  
might return having started a critical section or not.  Subsequent patches  
band-aided over some of the problems with this design by making things  
even messier.  
  
One user-visible resulting problem is memory leaks caused by the need for  
the subroutines to allocate storage that would survive until ginPlaceToPage  
calls XLogInsert (as reported by Julien Rouhaud).  This would not typically  
be noticeable during retail index updates.  It could be visible in a GIN  
index build, in the form of memory consumption swelling to several times  
the commanded maintenance_work_mem.  
  
Another rather nasty problem is that in the internal-page-splitting code  
path, we would clear the child page's GIN_INCOMPLETE_SPLIT flag well before  
entering the critical section that it's supposed to be cleared in; a  
failure in between would leave the index in a corrupt state.  There were  
also assorted coding-rule violations with little immediate consequence but  
possible long-term hazards, such as beginning an XLogInsert sequence before  
entering a critical section, or calling elog(DEBUG) inside a critical  
section.  
  
To fix, redefine the API between ginPlaceToPage() and its subroutines  
by splitting the subroutines into two parts.  The "beginPlaceToPage"  
subroutine does what can be done outside a critical section, including  
full computation of the result pages into temporary storage when we're  
going to split the target page.  The "execPlaceToPage" subroutine is called  
within a critical section established by ginPlaceToPage(), and it handles  
the actual page update in the non-split code path.  The critical section,  
as well as the XLOG insertion call sequence, are both now always started  
and finished in ginPlaceToPage().  Also, make ginPlaceToPage() create and  
work in a short-lived memory context to eliminate the leakage problem.  
(Since a short-lived memory context had been getting created in the most  
common code path in the subroutines, this shouldn't cause any noticeable  
performance penalty; we're just moving the overhead up one call level.)  
  
In passing, fix a bunch of comments that had gone unmaintained throughout  
all this klugery.  
  
Report: <571276DD.5050303@dalibo.com>  
  

Revert no-op changes to BufferGetPage()

  
commit   : a343e223a5c33a7283a6d8b255c9dbc48dbc5061    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 20 Apr 2016 08:31:19 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 20 Apr 2016 08:31:19 -0500    

Click here for diff

  
The reverted changes were intended to force a choice of whether any  
newly-added BufferGetPage() calls needed to be accompanied by a  
test of the snapshot age, to support the "snapshot too old"  
feature.  Such an accompanying test is needed in about 7% of the  
cases, where the page is being used as part of a scan rather than  
positioning for other purposes (such as DML or vacuuming).  The  
additional effort required for back-patching, and the doubt whether  
the intended benefit would really be there, have indicated it is  
best just to rely on developers to do the right thing based on  
comments and existing usage, as we do with many other conventions.  
  
This change should have little or no effect on generated executable  
code.  
  
Motivated by the back-patching pain of Tom Lane and Robert Haas  
  

Improve regression tests for degree-based trigonometric functions.

  
commit   : 4db0d2d2fe935e086dfd26c00f707dab298b443c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Apr 2016 16:47:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Apr 2016 16:47:21 -0400    

Click here for diff

  
Print the actual value of each function result that's expected to be exact,  
rather than merely emitting a NULL if it's not right.  Although we print  
these with extra_float_digits = 3, we should not trust that the platform  
will produce a result visibly different from the expected value if it's off  
only in the last place; hence, also include comparisons against the exact  
values as before.  This is a bit bulkier and uglier than the previous  
printout, but it will provide more information and be easier to interpret  
if there's a test failure.  
  
Discussion: <18241.1461073100@sss.pgh.pa.us>  
  

Make partition-lock-release coding more transparent in BufferAlloc().

  
commit   : a0382e2d7e330de13e15cea0921a95faa9da3570    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Apr 2016 18:05:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Apr 2016 18:05:56 -0400    

Click here for diff

  
Coverity complained that oldPartitionLock was possibly dereferenced after  
having been set to NULL.  That actually can't happen, because we'd only use  
it if (oldFlags & BM_TAG_VALID) is true.  But nonetheless Coverity is  
justified in complaining, because at line 1275 we actually overwrite  
oldFlags, and then still expect its BM_TAG_VALID bit to be a safe guide to  
whether to release the oldPartitionLock.  Thus, the code would be incorrect  
if someone else had changed the buffer's BM_TAG_VALID flag meanwhile.  
That should not happen, since we hold pin on the buffer throughout this  
sequence, but it's starting to look like a rather shaky chain of logic.  
And there's no need for such assumptions, because we can simply replace  
the (oldFlags & BM_TAG_VALID) tests with (oldPartitionLock != NULL),  
which has identical results and makes it plain to all comers that we don't  
dereference a null pointer.  A small side benefit is that the range of  
liveness of oldFlags is greatly reduced, possibly allowing the compiler  
to save a register.  
  
This is just cleanup, not an actual bug fix, so there seems no need  
for a back-patch.  
  

Further reduce the number of semaphores used under –disable-spinlocks.

  
commit   : 75c24d0f7491f77dfbc0acdf6c18439f288353ef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Apr 2016 13:33:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Apr 2016 13:33:06 -0400    

Click here for diff

  
Per discussion, there doesn't seem to be much value in having  
NUM_SPINLOCK_SEMAPHORES set to 1024: under any scenario where you are  
running more than a few backends concurrently, you really had better have a  
real spinlock implementation if you want tolerable performance.  And 1024  
semaphores is a sizable fraction of the system-wide SysV semaphore limit  
on many platforms.  Therefore, reduce this setting's default value to 128  
to make it less likely to cause out-of-semaphores problems.  
  

Fix typo in docs.

  
commit   : 8ce8307bd4d6028371c6e8b51bdc6ad260baa03a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 18 Apr 2016 13:35:21 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 18 Apr 2016 13:35:21 +0900    

Click here for diff

  
Artur Zakirov  
  

doc: Document that sequences can also be extension configuration tables

  
commit   : d460c7cc0fd43a7f7184818c67705a878e938b2d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 17 Apr 2016 23:13:45 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 17 Apr 2016 23:13:45 -0400    

Click here for diff

  
From: Michael Paquier <michael.paquier@gmail.com>  
  

Avoid code duplication in \crosstabview.

  
commit   : 9603a32594d2f5e6d9a1f098bc554a68f44ccb3c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Apr 2016 11:37:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Apr 2016 11:37:58 -0400    

Click here for diff

  
In commit 6f0d6a507 I added a duplicate copy of psqlscanslash's identifier  
downcasing code, but actually it's not hard to split that out as a callable  
subroutine and avoid the duplication.  
  

Adjust spin.c’s spinlock emulation so that 0 is not a valid spinlock value.

  
commit   : 4039c736eb0955cb1daf88e211f105dbbb78f7ea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Apr 2016 19:53:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Apr 2016 19:53:38 -0400    

Click here for diff

  
We've had repeated troubles over the years with failures to initialize  
spinlocks correctly; see 6b93fcd14 for a recent example.  Most of the time,  
on most platforms, such oversights can escape notice because all-zeroes is  
the expected initial content of an slock_t variable.  The only platform  
we have where the initialized state of an slock_t isn't zeroes is HPPA,  
and that's practically gone in the wild.  To make it easier to catch such  
errors without needing one of those, adjust the --disable-spinlocks code  
so that zero is not a valid value for an slock_t for it.  
  
In passing, remove a bunch of unnecessary #include's from spin.c;  
commit daa7527afc227443 removed all the intermodule coupling that  
made them necessary.  
  

doc: Change some “user” to “role” for consistency in the section

  
commit   : 5fdda1ceab35311367ed0dbb283cd8aea896e49b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 16 Apr 2016 12:54:56 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 16 Apr 2016 12:54:56 -0400    

Click here for diff

  
suggested by Johannes Choo  
  

doc: Markup improvement

  
commit   : efb25e56d8a43917bcadfe3904691b1e1cdbbe20    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 16 Apr 2016 12:49:36 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 16 Apr 2016 12:49:36 -0400    

Click here for diff

  
  

Disallow creation of indexes on system columns (except for OID).

  
commit   : c34df8a003c3e478d70e8251bd2a24d710b297d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Apr 2016 12:11:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Apr 2016 12:11:41 -0400    

Click here for diff

  
Although OID acts pretty much like user data, the other system columns do  
not, so an index on one would likely misbehave.  And it's pretty hard to  
see a use-case for one, anyway.  Let's just forbid the case rather than  
worry about whether it should be supported.  
  
David Rowley  
  

In recordExtensionInitPriv(), keep the scan til we’re done with it

  
commit   : 99f2f3c19ae7d6aa2950a9bdb549217c5a60d941    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 15 Apr 2016 21:57:15 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 15 Apr 2016 21:57:15 -0400    

Click here for diff

  
For reasons of sheer brain fade, we (I) was calling systable_endscan()  
immediately after systable_getnext() and expecting the tuple returned  
by systable_getnext() to still be valid.  
  
That's clearly wrong.  Move the systable_endscan() down below the tuple  
usage.  
  
Discovered initially by Pavel Stehule and then also by Alvaro.  
  
Add a regression test based on Alvaro's testing.  
  

doc: Add missing parentheses

  
commit   : d2de44c2ce5c697a2de8089fb377816b2387107a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 15 Apr 2016 20:44:10 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 15 Apr 2016 20:44:10 -0400    

Click here for diff

  
From: Alexander Law <exclusion@gmail.com>  
  

psql: Add new gettext trigger

  
commit   : c3136876734b31ce50018f39c87b00145a8c7c33    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 15 Apr 2016 20:23:41 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 15 Apr 2016 20:23:41 -0400    

Click here for diff

  
  

Use less-generic names in matview.sql.

  
commit   : 4447f0bcb66547708fa977d6b252046e792a7e04    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2016 13:04:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2016 13:04:17 -0400    

Click here for diff

  
The original coding of this test used table and view names like "t",  
"tv", "foo", etc.  This tended to interfere with doing simple manual  
tests in the regression database; not to mention that it posed a  
considerable risk of conflict with other regression test scripts.  
Prefix these names with "mvtest_" to avoid such conflicts.  
  
Also, change transiently-created role name to be "regress_xxx" per  
discussions about being careful with regression-test role creation.  
  

Fix possible crash in ALTER TABLE … REPLICA IDENTITY USING INDEX.

  
commit   : 8f1911d5e6d5a1e62c860ddb040d664b01c6415c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2016 12:11:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2016 12:11:27 -0400    

Click here for diff

  
Careless coding added by commit 07cacba983ef79be could result in a crash  
or a bizarre error message if someone tried to select an index on the  
OID column as the replica identity index for a table.  Back-patch to 9.4  
where the feature was introduced.  
  
Discussion: CAKJS1f8TQYgTRDyF1_u9PVCKWRWz+DkieH=U7954HeHVPJKaKg@mail.gmail.com  
  
David Rowley  
  

postgres_fdw: Clean up handling of system columns.

  
commit   : da7d44b627ba839de32c9409aca659f60324de76    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 15 Apr 2016 11:58:56 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 15 Apr 2016 11:58:56 -0400    

Click here for diff

  
Previously, querying the xmin column of a single postgres_fdw foreign  
table fetched the tuple length, xmax the typmod, and cmin or cmax the  
composite type OID of the tuple.  However, when you queried several  
such tables and the join got shipped to the remote side, these columns  
ended up containing the remote values of the corresponding columns.  
Both behaviors are rather unprincipled, the former for obvious reasons  
and the latter because the remote values of these columns don't have  
any local significance; our transaction IDs are in a different space  
than those of the remote machine.  Clean this up by setting all of  
these fields to 0 in both cases.  Also fix the handling of tableoid  
to be sane.  
  
Robert Haas and Ashutosh Bapat, reviewed by Etsuro Fujita.  
  

Tweak EXPLAIN for parallel query to show workers launched.

  
commit   : 5702277ca97396384eaf5c58d582b79b9984ce73    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 15 Apr 2016 11:49:41 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 15 Apr 2016 11:49:41 -0400    

Click here for diff

  
The previous display was sort of confusing, because it didn't  
distinguish between the number of workers that we planned to launch  
and the number that actually got launched.  This has already confused  
several people, so display both numbers and label them clearly.  
  
Julien Rouhaud, reviewed by me.  
  

Fix portability problem induced by commit a6f6b7819.

  
commit   : 6b85d4ba9b09dc94cf1b14aef517da095a83cdbb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2016 10:44:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2016 10:44:28 -0400    

Click here for diff

  
pg_xlogdump includes bufmgr.h.  With a compiler that emits code for  
static inline functions even when they're unreferenced, that leads  
to unresolved external references in the new static-inline version  
of BufferGetPage().  So hide it with #ifndef FRONTEND, as we've done  
for similar issues elsewhere.  Per buildfarm member pademelon.  
  

Fix typo in comment

  
commit   : ba8fe38f58e2f3d86c5361373598af80d5ce4443    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 15 Apr 2016 13:32:54 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 15 Apr 2016 13:32:54 +0200    

Click here for diff

  
  

Update helptext for vcregress.pl

  
commit   : cf086b1c2fa1e11c14a9fe5fea05553974a480ef    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 15 Apr 2016 10:04:10 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 15 Apr 2016 10:04:10 +0200    

Click here for diff

  
This has clearly not been tracking the code changse for quite some time.  
  
Michael Paquier, problem spotted by Kyotaro HORIGUCHI  
  

Make regression test for multiple synchronous standbys more stable.

  
commit   : 36c1c91604cee164c6487afb99508f7ff8737b96    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 15 Apr 2016 13:58:14 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 15 Apr 2016 13:58:14 +0900    

Click here for diff

  
The regression test checks whether the output of pg_stat_replication is  
expected or not after changing synchronous_standby_names and reloading  
the configuration file. Regarding this test logic, previously there was  
a timing issue which made the test result unstable. That is,  
pg_stat_replication could return unexpected result during small window  
after the configuration file was reloaded before new setting value  
took effect, and which made the test fail.  
  
This commit changes the test logic so that it uses a loop with a timeout  
to give some room for the test to pass. Now the test fails only when  
pg_stat_replication keeps returning unexpected result for 30 seconds.  
  
Michael Paquier  
  

Fix memory leak in GIN index scans.

  
commit   : f0e766bd7f77774075297526bd2da8f3de226c1f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2016 00:02:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2016 00:02:26 -0400    

Click here for diff

  
The code had a query-lifespan memory leak when encountering GIN entries  
that have posting lists (rather than posting trees, ie, there are a  
relatively small number of heap tuples containing this index key value).  
With a suitable data distribution this could add up to a lot of leakage.  
Problem seems to have been introduced by commit 36a35c550, so back-patch  
to 9.4.  
  
Julien Rouhaud  
  

Rethink \crosstabview’s argument parsing logic.

  
commit   : 6f0d6a507889d94a79c0d18577a0cb1ccc2b6815    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Apr 2016 22:54:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Apr 2016 22:54:26 -0400    

Click here for diff

  
\crosstabview interpreted its arguments in an unusual way, including  
doing case-insensitive matching of unquoted column names, which is  
surely not the right thing.  Rip that out in favor of doing something  
equivalent to the dequoting/case-folding rules used by other psql  
commands.  To keep it simple, change the syntax so that the optional  
sort column is specified as a separate argument, instead of the  
also-quite-unusual syntax that attached it to the colH argument with  
a colon.  
  
Also, rework the error messages to be closer to project style.  
  

Make init_spin_delay() C89 compliant #2.

  
commit   : 4b74c6a40e7ac9dad7cdeb4cfd2d51ea60cfdbb5    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Apr 2016 19:26:13 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Apr 2016 19:26:13 -0700    

Click here for diff

  
My previous attempt at doing so, in 80abbeba23, was not sufficient. While that  
fixed the problem for bufmgr.c and lwlock.c , s_lock.c still has non-constant  
expressions in the struct initializer, because the file/line/function  
information comes from the caller of s_lock().  
  
Give up on using a macro, and use a static inline instead.  
  
Discussion: 4369.1460435533@sss.pgh.pa.us  
  

Remove trailing commas in enums.

  
commit   : 533cd2303aa6558721e76295fd1ffb05211764f9    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Apr 2016 18:54:06 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Apr 2016 18:54:06 -0700    

Click here for diff

  
These aren't valid C89. Found thanks to gcc's -Wc90-c99-compat. These  
exist in differing places in most supported branches.  
  

Fix trivial typo.

  
commit   : 7b16781228d6c0a2db66d71e33e64b9606779feb    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 13 Apr 2016 17:47:41 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 13 Apr 2016 17:47:41 -0700    

Click here for diff

  
  

Fix core dump in ReorderBufferRestoreChange on alignment-picky platforms.

  
commit   : 6a3d3965d6d5eec30e1c36b3ffa3355ee9201933    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Apr 2016 19:42:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Apr 2016 19:42:21 -0400    

Click here for diff

  
When re-reading an update involving both an old tuple and a new tuple from  
disk, reorderbuffer.c was careless about whether the new tuple is suitably  
aligned for direct access --- in general, it isn't.  We'd missed seeing  
this in the buildfarm because the contrib/test_decoding tests exercise this  
code path only a few times, and by chance all of those cases have old  
tuples with length a multiple of 4, which is usually enough to make the  
access to the new tuple's t_len safe.  For some still-not-entirely-clear  
reason, however, Debian's sparc build gets a bus error, as reported by  
Christoph Berg; perhaps it's assuming 8-byte alignment of the pointer?  
  
The lack of previous field reports is probably because you need all of  
these conditions to trigger a crash: an alignment-picky platform (not  
Intel), a transaction large enough to spill to disk, an update within  
that xact that changes a primary-key field and has an odd-length old tuple,  
and of course logical decoding tracing the transaction.  
  
Avoid the alignment assumption by using memcpy instead of fetching t_len  
directly, and add a test case that exposes the crash on picky platforms.  
Back-patch to 9.4 where the bug was introduced.  
  
Discussion: <20160413094117.GC21485@msg.credativ.de>  
  

Adjust signature of walrcv_receive hook.

  
commit   : c2dc194bdbf5f84ceb433ed416eb389c1234ebc9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Apr 2016 13:49:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Apr 2016 13:49:37 -0400    

Click here for diff

  
Commit 314cbfc5da988eff redefined the signature of this hook as  
typedef int (*walrcv_receive_type) (char **buffer, int *wait_fd);  
  
But in fact the type of the "wait_fd" variable ought to be pgsocket,  
which is what WaitLatchOrSocket expects, and which is necessary if  
we want to be able to assign PGINVALID_SOCKET to it on Windows.  
So fix that.  
  

Adjust datatype of ReplicationState.acquired_by.

  
commit   : 994f11257328e272a6a43d3de59ffa916cbfbe96    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Apr 2016 12:18:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Apr 2016 12:18:09 -0400    

Click here for diff

  
It was declared as "pid_t", which would be fine except that none of  
the places that printed it in error messages took any thought for the  
possibility that it's not equivalent to "int".  This leads to warnings  
on some buildfarm members, and could possibly lead to actually wrong  
error messages on those platforms.  There doesn't seem to be any very  
good reason not to just make it "int"; it's only ever assigned from  
MyProcPid, which is int.  If we want to cope with PIDs that are wider  
than int, this is not the place to start.  
  
Also, fix the comment, which seems to perhaps be a leftover from a time  
when the field was only a bool?  
  
Per buildfarm.  Back-patch to 9.5 which has same issue.  
  

Docs: clarify description of LIMIT/OFFSET behavior.

  
commit   : fda21aa05bdc96c2c4141f5fd1245a11a41cf62c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Apr 2016 10:57:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Apr 2016 10:57:29 -0400    

Click here for diff

  
Section 7.6 was a tad confusing because it specified what LIMIT NULL  
does, but neglected to do the same for OFFSET NULL, making this look  
like perhaps a special case or a wrong restatement of the bit about  
LIMIT ALL.  Wordsmith a bit while at it.  Per bug #14084.  
  

Fix prototype of pgwin32_bind().

  
commit   : 22989a8e34168f576e0f90b16fc3edabd28c40e6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Apr 2016 09:44:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Apr 2016 09:44:21 -0400    

Click here for diff

  
I (tgl) had copied-and-pasted this from pgwin32_accept(), failing to  
notice that the third parameter should be "int" not "int *".  
  
David Rowley  
  

Fix broken dependency-mongering for index operator classes/families.

  
commit   : 92a30a7eb0cadb008e18053f199af7de3fc1abaa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Apr 2016 23:33:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Apr 2016 23:33:31 -0400    

Click here for diff

  
For a long time, opclasscmds.c explained that "we do not create a  
dependency link to the AM [for an opclass or opfamily], because we don't  
currently support DROP ACCESS METHOD".  Commit 473b93287040b200 invented  
DROP ACCESS METHOD, but it batted only 1 for 2 on adding the dependency  
links, and 0 for 2 on updating the comments about the topic.  
  
In passing, undo the same commit's entirely inappropriate decision to  
blow away an existing index as a side-effect of create_am.sql.  
  

Fix duplicated index entry in doc.

  
commit   : c8cb7453233b31a177b08a3b2bdac4c31508dc00    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 14 Apr 2016 11:17:41 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 14 Apr 2016 11:17:41 +0900    

Click here for diff

  
Commit cfe96ae corrected the name of pg_logical_emit_message()  
in its index entry. But this typo fix caused duplicated index  
entry because there was another index entry for the function.  
  
Spotted by Tom Lane.  
  

Disallow SET SESSION AUTHORIZATION pg_*

  
commit   : bfed4ab824789fd7c000286650d4498dccb05634    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Wed, 13 Apr 2016 21:31:24 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Wed, 13 Apr 2016 21:31:24 -0400    

Click here for diff

  
As part of reserving the pg_* namespace for default roles and in line  
with SET ROLE and other previous efforts, disallow settings the role  
to a default/reserved role using SET SESSION AUTHORIZATION.  
  
These checks and restrictions on what is allowed regarding default /  
reserved roles are under debate, but it seems prudent to ensure that  
the existing checks at least cover the intended cases while the  
debate rages on.  On me to clean it up if the consensus decision is  
to remove these checks.  
  

Add required database and origin filtering for logical messages.

  
commit   : be65eddd80093a923b091dc60776aa6f966d1f07    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 13 Apr 2016 17:38:54 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 13 Apr 2016 17:38:54 -0700    

Click here for diff

  
Logical messages, added in 3fe3511d05, during decoding failed to filter  
messages emitted in other databases and messages emitted "under" a  
replication origin the output plugin isn't interested in.  
  
Add tests to verify that both types of filtering actually work. While  
touching message.sql remove hunk obsoleted by d25379e.  
  
Bump XLOG_PAGE_MAGIC because xl_logical_message changed and because  
3fe3511d05 had omitted doing so. 3fe3511d05 additionally didn't bump  
catversion, but 7a542700d has done so since.  
  
Author: Petr Jelinek  
Reported-By: Andres Freund  
Discussion: 20160406142513.wotqy3ba3kanr423@alap3.anarazel.de  
  

Make init_spin_delay() C89 compliant and change stuck spinlock reporting.

  
commit   : 80abbeba23d466b6541cf95082a9e1f36704424e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 13 Apr 2016 16:42:01 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 13 Apr 2016 16:42:01 -0700    

Click here for diff

  
The current definition of init_spin_delay (introduced recently in  
48354581a) wasn't C89 compliant. It's not legal to refer to refer to  
non-constant expressions, and the ptr argument was one.  This, as  
reported by Tom, lead to a failure on buildfarm animal pademelon.  
  
The pointer, especially on system systems with ASLR, isn't super helpful  
anyway, though. So instead of making init_spin_delay into an inline  
function, make s_lock_stuck() report the function name in addition to  
file:line and change init_spin_delay() accordingly. While not a direct  
replacement, the function name is likely more useful anyway (line  
numbers are often hard to interpret in third party reports).  
  
This also fixes what file/line number is reported for waits via  
s_lock().  
  
As PG_FUNCNAME_MACRO is now used outside of elog.h, move it to c.h.  
  
Reported-By: Tom Lane  
Discussion: 4369.1460435533@sss.pgh.pa.us  
  

Fix pg_dump so pg_upgrade’ing an extension with simple opfamilies works.

  
commit   : 6cead413bb92be0579a2dbf6320121edcc32e369    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Apr 2016 18:57:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Apr 2016 18:57:52 -0400    

Click here for diff

  
As reported by Michael Feld, pg_upgrade'ing an installation having  
extensions with operator families that contain just a single operator class  
failed to reproduce the extension membership of those operator families.  
This caused no immediate ill effects, but would create problems when later  
trying to do a plain dump and restore, because the seemingly-not-part-of-  
the-extension operator families would appear separately in the pg_dump  
output, and then would conflict with the families created by loading the  
extension.  This has been broken ever since extensions were introduced,  
and many of the standard contrib extensions are affected, so it's a bit  
astonishing nobody complained before.  
  
The cause of the problem is a perhaps-ill-considered decision to omit  
such operator families from pg_dump's output on the grounds that the  
CREATE OPERATOR CLASS commands could recreate them, and having explicit  
CREATE OPERATOR FAMILY commands would impede loading the dump script into  
pre-8.3 servers.  Whatever the merits of that decision when 8.3 was being  
written, it looks like a poor tradeoff now.  We can fix the pg_upgrade  
problem simply by removing that code, so that the operator families are  
dumped explicitly (and then will be properly made to be part of their  
extensions).  
  
Although this fixes the behavior of future pg_upgrade runs, it does nothing  
to clean up existing installations that may have improperly-linked operator  
families.  Given the small number of complaints to date, maybe we don't  
need to worry about providing an automated solution for that; anyone who  
needs to clean it up can do so with manual "ALTER EXTENSION ADD OPERATOR  
FAMILY" commands, or even just ignore the duplicate-opfamily errors they  
get during a pg_restore.  In any case we need this fix.  
  
Back-patch to all supported branches.  
  
Discussion: <20228.1460575691@sss.pgh.pa.us>  
  

Avoid atomic operation in MarkLocalBufferDirty().

  
commit   : 6b93fcd149329d4ee7319561b30fc15a573c6307    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 13 Apr 2016 15:28:29 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 13 Apr 2016 15:28:29 -0700    

Click here for diff

  
The recent patch to make Pin/UnpinBuffer lockfree in the hot  
path (48354581a), accidentally used pg_atomic_fetch_or_u32() in  
MarkLocalBufferDirty(). Other code operating on local buffers was  
careful to only use pg_atomic_read/write_u32 which just read/write from  
memory; to avoid unnecessary overhead.  
  
On its own that'd just make MarkLocalBufferDirty() slightly less  
efficient, but in addition InitLocalBuffers() doesn't call  
pg_atomic_init_u32() - thus the spinlock fallback for the atomic  
operations isn't initialized. That in turn caused, as reported by Tom,  
buildfarm animal gaur to fail.  As those errors are actually useful  
against this type of error, continue to omit - intentionally this time -  
initialization of the atomic variable.  
  
In addition, add an explicit note about only using pg_atomic_read/write  
on local buffers's state to BufferDesc's description.  
  
Reported-By: Tom Lane  
Discussion: 1881.1460431476@sss.pgh.pa.us  
  

Widen amount-to-flush arguments of FileWriteback and callers.

  
commit   : 95ef43c4308102d23afa887c9fc28d9977612a2d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Apr 2016 18:12:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Apr 2016 18:12:06 -0400    

Click here for diff

  
It's silly to define these counts as narrower than they might someday  
need to be.  Also, I believe that the BLCKSZ * nflush calculation in  
mdwriteback was capable of overflowing an int.  
  

Fix assorted portability issues with using msync() for data flushing.

  
commit   : fa11a09fed2b6f483231608866a682ee3a376277    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Apr 2016 17:17:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Apr 2016 17:17:51 -0400    

Click here for diff

  
Commit 428b1d6b29ca599c5700d4bc4f4ce4c5880369bf introduced the use of  
msync() for flushing dirty data from the kernel's file buffers.  Several  
portability issues were overlooked, though:  
  
* Not all implementations of mmap() think that nbytes == 0 means "map  
the whole file".  To fix, use lseek() to find out the true length.  
Fix callers of pg_flush_data to be aware that nbytes == 0 may result  
in trashing the file's seek position.  
  
* Not all implementations of mmap() will accept partial-page mmap  
requests.  To fix, round down the length request to whatever sysconf()  
says the page size is.  (I think this is OK from a portability standpoint,  
because sysconf() is required by SUS v2, and we aren't trying to compile  
this part on Windows anyway.  Buildfarm should let us know if not.)  
  
* On 32-bit machines, the file size might exceed the available free  
address space, or even exceed what will fit in size_t.  Check for  
the latter explicitly to avoid passing a false request size to mmap().  
If mmap fails, silently fall through to the next implementation method,  
rather than bleating to the postmaster log and giving up.  
  
* mmap'ing directories fails on some platforms, and even if it works,  
msync'ing the directory is quite unlikely to help, as for that matter are  
the other flush implementations.  In pre_sync_fname(), just skip flush  
attempts on directories.  
  
In passing, copy-edit the comments a bit.  
  
Stas Kelvich and myself  
  

Improve documentation for \crosstabview.

  
commit   : 85e004707715f5ee7a6bfc3d03d0fbc837fb2432    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Apr 2016 11:49:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Apr 2016 11:49:47 -0400    

Click here for diff

  
Fix misleading syntax summary (there cannot be a space between colH and  
scolH).  Provide a link from the existing crosstab() function's  
documentation to \crosstabview.  Copy-edit the command's description.  
  
Christoph Berg and Tom Lane  
  

Use PG_INT32_MIN instead of reiterating the constant.

  
commit   : cbb2a812d710dd58e68088b334f8c492346a0d0f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 13 Apr 2016 07:53:54 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 13 Apr 2016 07:53:54 -0400    

Click here for diff

  
Makes no difference, but it's cleaner this way.  
  
Michael Paquier  
  

Provide errno-translation wrappers around bind() and listen() on Windows.

  
commit   : d1b7d4877b9a71f476e8e5adea3b6afe419896ba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Apr 2016 19:52:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Apr 2016 19:52:21 -0400    

Click here for diff

  
I've seen one too many "could not bind IPv4 socket: No error" log entries  
from the Windows buildfarm members.  Per previous discussion, this is  
likely caused by the fact that we're doing nothing to translate  
WSAGetLastError() to errno.  Put in a wrapper layer to do that.  
  
If this works as expected, it should get back-patched, but let's see what  
happens in the buildfarm first.  
  
Discussion: <4065.1452450340@sss.pgh.pa.us>  
  

Fix costing for parallel aggregation.

  
commit   : deb71fa9713dfe374a74fc58a5d298b5f25da3f5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 12 Apr 2016 16:24:55 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 12 Apr 2016 16:24:55 -0400    

Click here for diff

  
The original patch kind of ignored the fact that we were doing something  
different from a costing point of view, but nobody noticed.  This patch  
fixes that oversight.  
  
David Rowley  
  

Remove unused function GetOldestWALSendPointer from walsender code.

  
commit   : 46d73e0d65eef19e25bb0d31f1e5c23ff40a3444    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 13 Apr 2016 04:36:29 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 13 Apr 2016 04:36:29 +0900    

Click here for diff

  
That unused function was introduced as a sample because synchronous  
replication or replication monitoring tools might need it in the future.  
Recently commit 989be08 added the function SyncRepGetOldestSyncRecPtr  
which provides almost the same functionality for multiple synchronous  
standbys feature. So it's time to remove that unused sample function.  
This commit does that.  
  

Redefine create_upper_paths_hook as being invoked once per upper relation.

  
commit   : f1f01de145d0aaca80e6cf8b2ccb7e7f4ed1ad02    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Apr 2016 15:23:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Apr 2016 15:23:14 -0400    

Click here for diff

  
Per discussion, this gives potential users of the hook more flexibility,  
because they can build custom Paths that implement only one stage of  
upper processing atop core-provided Paths for earlier stages.  
  

Improve coding of column-name parsing in psql’s new crosstabview.c.

  
commit   : 7a5f8b5c59033ac153963f98b9109be9529a824a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Apr 2016 12:52:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Apr 2016 12:52:35 -0400    

Click here for diff

  
Coverity complained about this code, not without reason because it was  
rather messy.  Adjust it to not scribble on the passed string; that adds  
one malloc/free cycle per column name, which is going to be insignificant  
in context.  We can actually const-ify both the string argument and the  
PGresult.  
  
Daniel Verité, with some further cleanup by me  
  

Avoid extra locks in GetSnapshotData if old_snapshot_threshold < 0

  
commit   : 2201d801b03c2d1b0bce4d6580b718dc34d38b3e    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 12 Apr 2016 11:48:02 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 12 Apr 2016 11:48:02 -0500    

Click here for diff

  
On a big NUMA machine with 1000 connections in saturation load  
there was a performance regression due to spinlock contention, for  
acquiring values which were never used.  Just fill with dummy  
values if we're not going to use them.  
  
This patch has not been benchmarked yet on a big NUMA machine, but  
it seems like a good idea on general principle, and it seemed to  
prevent an apparent 2.2% regression on a single-socket i7 box  
running 200 connections at saturation load.  
  

Improve API of GenericXLogRegister().

  
commit   : 5713f03973e26ad6df6df5ac8b9efa0123d68062    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Apr 2016 11:42:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Apr 2016 11:42:06 -0400    

Click here for diff

  
Rename this function to GenericXLogRegisterBuffer() to make it clearer  
what it does, and leave room for other sorts of "register" actions in  
future.  Also, replace its "bool isNew" argument with an integer flags  
argument, so as to allow adding more flags in future without an API  
break.  
  
Alexander Korotkov, adjusted slightly by me  
  

In generic WAL application and replay, ensure page “hole” is always zero.

  
commit   : bdf7db81921deb99fd9d489cbcc635906c89e215    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Apr 2016 11:13:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Apr 2016 11:13:52 -0400    

Click here for diff

  
The previous coding could allow the contents of the "hole" between pd_lower  
and pd_upper to diverge during replay from what it had been when the update  
was originally applied.  This would pose a problem if checksums were in  
use, and in any case would complicate forensic comparisons between master  
and slave servers.  So force the "hole" to contain zeroes, both at initial  
application of a generically-logged action, and at replay.  
  
Alexander Korotkov, adjusted slightly by me  
  

Add page id to bloom index

  
commit   : 813b456ea21d4cf57b124bf855ec019c7a8099a7    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Tue, 12 Apr 2016 18:03:01 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Tue, 12 Apr 2016 18:03:01 +0300    

Click here for diff

  
Added to ensure that bloom index pages can be distinguished from other pages  
by pg_filedump. Because there wasn't any public/production versions before,  
it doesn't pay attention to any compatibility issues.  
  
Per notice from Tom Lane  
  

Remove unnecessary definition of _WIN64 in libpq/win32.mak.

  
commit   : e7bcde8ca0d376d9d23d61855baf67122a66c76a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Apr 2016 10:52:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Apr 2016 10:52:58 -0400    

Click here for diff

  
In commit b0e40d189325dc7a54d2546245e766f8c47a7c8d, I should have just  
removed the /D switch defining WIN64.  The reason the code worked before  
is that all Windows64 compilers automatically predefine _WIN64.  Perhaps  
at one time we had code that depended on WIN64 being defined, but it's  
long gone, and we should not encourage any reappearance.  Per discussion  
with Christian Ullrich.  
  

  
commit   : cd13471f2e9dee6d411cae3ddae72d0ad6b58c4d    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 12 Apr 2016 08:45:09 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 12 Apr 2016 08:45:09 -0400    

Click here for diff

  
It's 2016 these days (no, not entirely sure how we got here either).  
  
Pointed out by Amit Langote  
  

Fix whitespace

  
commit   : 70715e6a600f1652a04b4e698dad3c7d6bff6bdb    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Apr 2016 20:59:04 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Apr 2016 20:59:04 -0400    

Click here for diff

  
  

Fix _SPI_execute_plan() for CREATE TABLE IF NOT EXISTS foo AS …

  
commit   : 39c283e498de1bb7c3d5beadfffcf3273ae8cc27    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Apr 2016 20:07:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Apr 2016 20:07:17 -0400    

Click here for diff

  
When IF NOT EXISTS was added to CREATE TABLE AS, this logic didn't get  
the memo, possibly resulting in an Assert failure.  It looks like there  
would have been no ill effects in a non-Assert build, though.  Back-patch  
to 9.5 where the IF NOT EXISTS option was added.  
  
Stas Kelvich  
  

Fix two places that thought Windows64 is indicated by WIN64 macro.

  
commit   : b0e40d189325dc7a54d2546245e766f8c47a7c8d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Apr 2016 19:37:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Apr 2016 19:37:04 -0400    

Click here for diff

  
Everyplace else thinks it's _WIN64, so make these places fall in line.  
  
The pg_regress.c usage is not going to result in any change in behavior,  
only suppressing (or not) a compiler warning about downcasting HANDLEs.  
So there seems no need for back-patching there.  
  
The libpq/win32.mak usage might represent an actual bug, if anyone were  
using this script to build for Windows64, which perhaps nobody is.  
Given the lack of field complaints, no back-patch here either.  
  
pg_regress.c problem found by Christian Ullrich, the other by me.  
  

Fix freshly-introduced PL/Python portability bug.

  
commit   : 1d2f9de38d18152f83cf570581cebac0733ff504    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Apr 2016 18:17:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Apr 2016 18:17:02 -0400    

Click here for diff

  
It turns out that those PyErr_Clear() calls I removed from plpy_elog.c  
in 7e3bb080387f4143 et al were not quite as random as they appeared: they  
mask a Python 2.3.x bug.  (Specifically, it turns out that PyType_Ready()  
can fail if the error indicator is set on entry, and PLy_traceback's fetch  
of frame.f_code may be the first operation in a session that requires the  
"frame" type to be readied.  Ick.)  Put back the clear call, but in a more  
centralized place closer to what it's protecting, and this time with a  
comment warning what it's really for.  
  
Per buildfarm member prairiedog.  Although prairiedog was only failing  
on HEAD, it seems clearly possible for this to occur in older branches  
as well, so back-patch to 9.2 the same as the previous patch.  
  

Use static inline function for BufferGetPage()

  
commit   : a6f6b78196a701702ec4ff6df56c346bdcf9abd2    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Mon, 11 Apr 2016 16:47:50 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Mon, 11 Apr 2016 16:47:50 -0500    

Click here for diff

  
I was initially concerned that the some of the hundreds of  
references to BufferGetPage() where the literal  
BGP_NO_SNAPSHOT_TEST were passed might not optimize as well as a  
macro, leading to some hard-to-find performance regressions in  
corner cases.  Inspection of disassembled code has shown identical  
code at all inspected locations, and the size difference doesn't  
amount to even one byte per such call.  So make it readable.  
  
Per gripes from Álvaro Herrera and Tom Lane  
  

Make oldSnapshotControl a pointer to a volatile structure

  
commit   : 80647bf65a03e232c995c0826ef394dad8d685fe    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Mon, 11 Apr 2016 15:43:52 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Mon, 11 Apr 2016 15:43:52 -0500    

Click here for diff

  
It was incorrectly declared as a volatile pointer to a non-volatile  
structure.  Eliminate the OldSnapshotControl struct definition; it  
is really not needed.  Pointed out by Tom Lane.  
  
While at it, add OldSnapshotControlData to pgindent's list of  
structures.  
  

Fix whitespace

  
commit   : d8ed83cd7fd1082f60a5b9897b62216f6b3e2587    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Apr 2016 14:44:51 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Apr 2016 14:44:51 -0400    

Click here for diff

  
  

Prefix RLS regression test roles with ‘regress_’

  
commit   : 6c7b0388c568e3063c3d40a7d90e1bca9006d505    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 11 Apr 2016 14:12:33 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 11 Apr 2016 14:12:33 -0400    

Click here for diff

  
To avoid any possible overlap with existing roles on a system when  
doing a 'make installcheck', use role names which start with  
'regress_'.  
  
Pointed out by Tom.  
  

Add directory created during build to gitignore

  
commit   : 29ca231b83a142ea1633e7c496619accb7dd9e4f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Apr 2016 14:01:15 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Apr 2016 14:01:15 -0400    

Click here for diff

  
  

Fix missing “volatile” in PLy_output().

  
commit   : 81ba9348d85fdf87e84cc02112933b592845bda2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Apr 2016 11:49:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Apr 2016 11:49:48 -0400    

Click here for diff

  
Commit 5c3c3cd0a3046339 plastered "volatile" on a bunch of variables  
in PLy_output(), but removed the one that actually mattered, ie the  
one on "oldcontext".  This allows some versions of clang to generate  
code in which "oldcontext" has been trashed when control reaches the  
PG_CATCH block.  Per buildfarm member tick.  
  

cpluspluscheck: Update include path

  
commit   : ee5dbc8173d8f434a467380bfd218ef6f91a8e31    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Apr 2016 11:16:16 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 11 Apr 2016 11:16:16 -0400    

Click here for diff

  
Some things in src/include/fe_utils require libpq headers, so add  
libpq's include path to the command line used here.  
  

Fix documented return type of pg_logical_emit_message() in func.sgml.

  
commit   : cfe96ae24c97ff376157c48ccd5ca6d3938632be    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 11 Apr 2016 21:28:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 11 Apr 2016 21:28:17 +0900    

Click here for diff

  
  

Use ereport(ERROR) instead of Assert() to emit syncrep_parser error.

  
commit   : 0038c1e2181b520a9307aae6587e110468072392    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 11 Apr 2016 15:52:27 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 11 Apr 2016 15:52:27 +0900    

Click here for diff

  
The existing code would either Assert or generate an invalid  
SyncRepConfig variable, neither of which is desirable. A regular  
error should be thrown instead.  
  
This commit silences compiler warning in non assertion-enabled builds.  
  
Per report from Jeff Janes.  
Suggested fix by Tom Lane.  
  

Fix poorly thought-through code from commit 5c3c3cd0a3046339.

  
commit   : f73b2bbbdcb387aa90ff619fe03d1924ed82b868    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Apr 2016 00:28:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Apr 2016 00:28:44 -0400    

Click here for diff

  
It's not entirely clear to me whether PyString_AsString can return  
null (looks like the answer might vary between Python 2 and 3).  
But in any case, this code's attempt to cope with the possibility  
was quite broken, because pstrdup() neither allows a null argument  
nor ever returns a null.  
  
Moreover, the code below this point assumes that "message" is a  
palloc'd string, which would not be the case for a dgettext result.  
  
Fix both problems by doing the pstrdup step separately.  
  

pg_dump: add missing “destroyPQExpBuffer(query)” in dumpForeignServer().

  
commit   : 074050f16a2db9b5ebe5c9f8fdb211cbb810e746    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Apr 2016 00:00:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Apr 2016 00:00:08 -0400    

Click here for diff

  
Coverity complained about this resource leak (why now, I don't know,  
since it's been like that a long time).  Our general policy in pg_dump  
is that PQExpBuffers are worth cleaning up, so do it here too.  But  
don't bother with a back-patch, because it seems unlikely that very  
many databases contain enough FOREIGN SERVER objects to notice.  
  

Add comment about intentional fallthrough in switch.

  
commit   : 1630f5b92a3a00aff5674f31af1d418628a00ac7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Apr 2016 23:52:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Apr 2016 23:52:34 -0400    

Click here for diff

  
Coverity complained about an apparent missing "break" in a switch  
added by bb140506df605fab.  The human-readable comments are pretty  
clear that this is intentional, but add a standard /* FALL THRU */  
comment to make it clear to tools too.  
  

Clean up foreign-key caching code in planner.

  
commit   : 5306df2831ab012d8008691f833457bc299962aa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Apr 2016 23:47:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Apr 2016 23:47:30 -0400    

Click here for diff

  
Coverity complained that the code added by 015e88942aa50f0d lacked an  
error check for SearchSysCache1 failures, which it should have.  But  
the code was pretty duff in other ways too, including failure to think  
about whether it could really cope with arrays of different lengths.  
  

Fix access-to-already-freed-memory issue in plpython’s error handling.

  
commit   : 7e3bb080387f4143cdc908bf97daf9a8abdc445f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Apr 2016 23:15:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Apr 2016 23:15:55 -0400    

Click here for diff

  
PLy_elog() could attempt to access strings that Python had already freed,  
because the strings that PLy_get_spi_error_data() returns are simply  
pointers into storage associated with the error "val" PyObject.  That's  
fine at the instant PLy_get_spi_error_data() returns them, but just after  
that PLy_traceback() intentionally releases the only refcount on that  
object, allowing it to be freed --- so that the strings we pass to  
ereport() are dangling pointers.  
  
In principle this could result in garbage output or a coredump.  In  
practice, I think the risk is pretty low, because there are no Python  
operations between where we decrement that refcount and where we use the  
strings (and copy them into PG storage), and thus no reason for Python  
to recycle the storage.  Still, it's clearly hazardous, and it leads to  
Valgrind complaints when running under a Valgrind that hasn't been  
lobotomized to ignore Python memory allocations.  
  
The code was a mess anyway: we fetched the error data out of Python  
(clearing Python's error indicator) with PyErr_Fetch, examined it, pushed  
it back into Python with PyErr_Restore (re-setting the error indicator),  
then immediately pulled it back out with another PyErr_Fetch.  Just to  
confuse matters even more, there were some gratuitous-and-yet-hazardous  
PyErr_Clear calls in the "examine" step, and we didn't get around to doing  
PyErr_NormalizeException until after the second PyErr_Fetch, making it even  
less clear which object was being manipulated where and whether we still  
had a refcount on it.  (If PyErr_NormalizeException did substitute a  
different "val" object, it's possible that the problem could manifest for  
real, because then we'd be doing assorted Python stuff with no refcount  
on the object we have string pointers into.)  
  
So, rearrange all that into some semblance of sanity, and don't decrement  
the refcount on the Python error objects until the end of PLy_elog().  
In HEAD, I failed to resist the temptation to reformat some messy bits  
from 5c3c3cd0a3046339 along the way.  
  
Back-patch as far as 9.2, because the code is substantially the same  
that far back.  I believe that 9.1 has the bug as well; but the code  
around it is rather different and I don't want to take a chance on  
breaking something for what seems a low-probability problem.  
  

Avoid the use of a separate spinlock to protect a LWLock’s wait queue.

  
commit   : 008608b9d51061b1f598c197477b3dc7be9c4a64    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 10 Apr 2016 20:12:32 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 10 Apr 2016 20:12:32 -0700    

Click here for diff

  
Previously we used a spinlock, in adition to the atomically manipulated  
->state field, to protect the wait queue. But it's pretty simple to  
instead perform the locking using a flag in state.  
  
Due to 6150a1b0 BufferDescs, on platforms (like PPC) with > 1 byte  
spinlocks, increased their size above 64byte. As 64 bytes are the size  
we pad allocated BufferDescs to, this can increase false sharing;  
causing performance problems in turn. Together with the previous commit  
this reduces the size to <= 64 bytes on all common platforms.  
  
Author: Andres Freund  
Discussion: CAA4eK1+ZeB8PMwwktf+3bRS0Pt4Ux6Rs6Aom0uip8c6shJWmyg@mail.gmail.com  
    20160327121858.zrmrjegmji2ymnvr@alap3.anarazel.de  
  

Allow Pin/UnpinBuffer to operate in a lockfree manner.

  
commit   : 48354581a49c30f5757c203415aa8412d85b0f70    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 10 Apr 2016 20:12:32 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 10 Apr 2016 20:12:32 -0700    

Click here for diff

  
Pinning/Unpinning a buffer is a very frequent operation; especially in  
read-mostly cache resident workloads. Benchmarking shows that in various  
scenarios the spinlock protecting a buffer header's state becomes a  
significant bottleneck. The problem can be reproduced with pgbench -S on  
larger machines, but can be considerably worse for queries which touch  
the same buffers over and over at a high frequency (e.g. nested loops  
over a small inner table).  
  
To allow atomic operations to be used, cram BufferDesc's flags,  
usage_count, buf_hdr_lock, refcount into a single 32bit atomic variable;  
that allows to manipulate them together using 32bit compare-and-swap  
operations. This requires reducing MAX_BACKENDS to 2^18-1 (which could  
be lifted by using a 64bit field, but it's not a realistic configuration  
atm).  
  
As not all operations can easily implemented in a lockfree manner,  
implement the previous buf_hdr_lock via a flag bit in the atomic  
variable. That way we can continue to lock the header in places where  
it's needed, but can get away without acquiring it in the more frequent  
hot-paths.  There's some additional operations which can be done without  
the lock, but aren't in this patch; but the most important places are  
covered.  
  
As bufmgr.c now essentially re-implements spinlocks, abstract the delay  
logic from s_lock.c into something more generic. It now has already two  
users, and more are coming up; there's a follupw patch for lwlock.c at  
least.  
  
This patch is based on a proof-of-concept written by me, which Alexander  
Korotkov made into a fully working patch; the committed version is again  
revised by me.  Benchmarking and testing has, amongst others, been  
provided by Dilip Kumar, Alexander Korotkov, Robert Haas.  
  
On a large x86 system improvements for readonly pgbench, with a high  
client count, of a factor of 8 have been observed.  
  
Author: Alexander Korotkov and Andres Freund  
Discussion: 2400449.GjM57CE0Yg@dinodell  
  

Improve contrib/bloom regression test using code coverage info.

  
commit   : cf223c3bf5ba16232147c66b5fef4037aafe747c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Apr 2016 13:12:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Apr 2016 13:12:24 -0400    

Click here for diff

  
Originally, this test created a 100000-row test table, which made it  
run rather slowly compared to other contrib tests.  Investigation with  
gcov showed that we got no further improvement in code coverage after  
the first 700 or so rows, making the large table 99% a waste of time.  
Cut it back to 2000 rows to fix the runtime problem and still leave  
some headroom for testing behaviors that may appear later.  
  
A closer look at the gcov results showed that the main coverage  
omissions in contrib/bloom occurred because the test never filled more  
than one entry in the notFullPage array; which is unsurprising because  
it exercised index cleanup only in the scenario of complete table  
deletion, allowing every page in the index to become deleted rather  
than not-full.  Add testing that allows the not-full path to be  
exercised as well.  
  
Also, test the amvalidate function, because blvalidate.c had zero  
coverage without that, and besides it's a good idea to check for  
mistakes in the bloom opclass definitions.  
  

Fix possible NULL dereference in ExecAlterObjectDependsStmt

  
commit   : bd905a0d0416628b4aef153463c1f5e5b80b3e96    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 10 Apr 2016 11:03:35 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 10 Apr 2016 11:03:35 -0300    

Click here for diff

  
I used the wrong variable here.  Doesn't make a difference today because  
the only plausible caller passes a non-NULL variable, but someday it  
will be wrong, and even today's correctness is subtle: the caller that  
does pass a NULL is never invoked because of object type constraints.  
Surely not a condition to rely on.  
  
Noted by Coverity  
  

Further minor improvement in generic_xlog.c: always say REGBUF_STANDARD.

  
commit   : 660d5fb856c61df2de2cedb26249404ffc58cb89    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Apr 2016 00:24:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Apr 2016 00:24:28 -0400    

Click here for diff

  
Since we're requiring pages handled by generic_xlog.c to be standard  
format, specify REGBUF_STANDARD when doing a full-page image, so that  
xloginsert.c can compress out the "hole" between pd_lower and pd_upper.  
Given the current API in which this path will be taken only for a newly  
initialized page, the hole is likely to be particularly large in such  
cases, so that this oversight could easily be performance-significant.  
I don't notice any particular change in the runtime of contrib/bloom's  
regression test, though.  
  

Micro-optimize GenericXLogFinish().

  
commit   : 68689c66efcda6f217119432edfbdf95a50b26e2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Apr 2016 19:30:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Apr 2016 19:30:56 -0400    

Click here for diff

  
Make the inner comparison loops of computeDelta() as tight as possible by  
pulling considerations of valid and invalid ranges out of the inner loops,  
and extending a match or non-match detection as far as possible before  
deciding what to do next.  To keep this tractable, give up the possibility  
of merging fragments across the pd_lower to pd_upper gap.  The fraction of  
pages where that could happen (ie, there are 4 or fewer bytes in the gap,  
*and* data changes immediately adjacent to it on both sides) is too small  
to be worth spending cycles on.  
  
Also, avoid two BLCKSZ-length memcpy()s by computing the delta before  
moving data into the target buffer, instead of after.  This doesn't save  
nearly as many cycles as being tenser about computeDelta(), but it still  
seems worth doing.  
  
On my machine, this patch cuts a full 40% off the runtime of  
contrib/bloom's regression test.  
  

Fix PL/Python ereport() test to work on Python 2.3.

  
commit   : c7a141a9866b8c15d9e3b6fd5310e54837900394    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Apr 2016 16:44:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Apr 2016 16:44:54 -0400    

Click here for diff

  
Per buildfarm.  
  
Pavel Stehule  
  

Get rid of GenericXLogUnregister().

  
commit   : 08e785436f84f8824149a2182b0cb9ce2c28e31d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Apr 2016 16:39:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Apr 2016 16:39:30 -0400    

Click here for diff

  
This routine is unsafe as implemented, because it invalidates the page  
image pointers returned by previous GenericXLogRegister() calls.  
  
Rather than complicate the API or the implementation to avoid that,  
let's just get rid of it; the use-case for having it seems much  
too thin to justify a lot of work here.  
  
While at it, do some wordsmithing on the SGML docs for generic WAL.  
  

Get rid of blinsert()’s use of GenericXLogUnregister().

  
commit   : 80cf18910c8edf2575c306dde9ead192bdb0863a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Apr 2016 15:39:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Apr 2016 15:39:14 -0400    

Click here for diff

  
That routine is dangerous, and unnecessary once we get rid of this  
one caller.  
  
In passing, fix failure to clean up temp memory context, or switch  
back to caller's context, during slowest exit path.  
  

Code review/prettification for generic_xlog.c.

  
commit   : db03cf375d602e417eda6b7a55eead91618e1398    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Apr 2016 15:02:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Apr 2016 15:02:19 -0400    

Click here for diff

  
Improve commentary, use more specific names for the delta fields,  
const-ify pointer arguments where possible, avoid assuming that  
initializing only the first element of a local array will guarantee  
that the remaining elements end up as we need them.  (I think that  
code in generic_redo actually worked, but only because InvalidBuffer  
is zero; this is a particularly ugly way of depending on that ...)  
  

Run pgindent on generic_xlog.c.

  
commit   : 2dd318d277b8e1d8269b030f545240193943162f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Apr 2016 13:33:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Apr 2016 13:33:33 -0400    

Click here for diff

  
This code desperately needs some micro-optimization, and I'd like it  
to be formatted a bit more nicely while I work on it.  
  

Fix typo in C comment.

  
commit   : 381200be4b565292eba6f62200248cb775f06940    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 9 Apr 2016 09:07:42 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 9 Apr 2016 09:07:42 -0500    

Click here for diff

  
  

Turn special page pointer validation to static inline function

  
commit   : 56dffb5a73ab157fc8d35a76c1170d656a051f14    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 9 Apr 2016 08:17:22 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 9 Apr 2016 08:17:22 -0500    

Click here for diff

  
Inclusion of multiple macros inside another macro was pushing MSVC  
past its size liimit.  Reported by buildfarm.  
  

Move \crosstabview regression tests to a separate file

  
commit   : 1ff3f420d470fae46759e948a20e9550af012816    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 Apr 2016 23:42:24 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 Apr 2016 23:42:24 -0300    

Click here for diff

  
It cannot run in the same parallel group as misc, because it creates a  
table which is unpredictably visible in that test.  
  
Per buildfarm member crake.  
  

Support \crosstabview in psql

  
commit   : c09b18f21c52cbcf8718d6c267c84fcfea3739a9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 Apr 2016 20:23:18 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 Apr 2016 20:23:18 -0300    

Click here for diff

  
\crosstabview is a completely different way to display results from a  
query: instead of a vertical display of rows, the data values are placed  
in a grid where the column and row headers come from the data itself,  
similar to a spreadsheet.  
  
The sort order of the horizontal header can be specified by using  
another column in the query, and the vertical header determines its  
ordering from the order in which they appear in the query.  
  
This only allows displaying a single value in each cell.  If more than  
one value correspond to the same cell, an error is thrown.  Merging of  
values can be done in the query itself, if necessary.  This may be  
revisited in the future.  
  
Author: Daniel Verité  
Reviewed-by: Pavel Stehule, Dean Rasheed  
  

Add snapshot_too_old to NSVC @contrib_excludes

  
commit   : 279d86afdbed550425bc9d1327ade2dc0028ad33    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 8 Apr 2016 17:18:10 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 8 Apr 2016 17:18:10 -0500    

Click here for diff

  
The buildfarm showed failure for Windows MSVC builds due to this  
omission.  This might not be the only problem with the Makefile for  
this feature, but hopefully this will get it past the immediate  
problem.  
  
Fix suggested by Tom Lane  
  

Expose more out/readfuncs support functions.

  
commit   : c1ddd2361f6eb071d51b856c697a4aab22f8c776    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 8 Apr 2016 14:26:36 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 8 Apr 2016 14:26:36 -0700    

Click here for diff

  
Previously bcac23d exposed a subset of support functions, namely the  
ones Kaigai found useful. In  
20160304193704.elq773pyg5fyl3mi@alap3.anarazel.de I mentioned that  
there's some functions missing to use the facility in an external  
project.  
  
To avoid having to add functions piecemeal, add all the functions which  
are used to define READ_* and WRITE_* macros; users of the extensible  
node functionality are likely to need these. Additionally expose  
outDatum(), which doesn't have it's own WRITE_ macro, as it needs  
information from the embedding struct.  
  
Discussion: 20160304193704.elq773pyg5fyl3mi@alap3.anarazel.de  
  

Create default roles

  
commit   : 7a542700df25eaf97b794bff63606176433dcdda    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 8 Apr 2016 16:56:27 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 8 Apr 2016 16:56:27 -0400    

Click here for diff

  
This creates an initial set of default roles which administrators may  
use to grant access to, historically, superuser-only functions.  Using  
these roles instead of granting superuser access reduces the number of  
superuser roles required for a system.  Documention for each of the  
default roles has been added to user-manag.sgml.  
  
Bump catversion to 201604082, as we had a commit that bumped it to  
201604081 and another that set it back to 201604071...  
  
Reviews by José Luis Tallón and Robert Haas  
  

Reserve the “pg_” namespace for roles

  
commit   : 293007898d3fa5a815c1c5814df53627553f114d    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 8 Apr 2016 16:56:27 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 8 Apr 2016 16:56:27 -0400    

Click here for diff

  
This will prevent users from creating roles which begin with "pg_" and  
will check for those roles before allowing an upgrade using pg_upgrade.  
  
This will allow for default roles to be provided at initdb time.  
  
Reviews by José Luis Tallón and Robert Haas  
  

Fix improper usage of ‘dump’ bitmap

  
commit   : fa6075e5515c6878b2c1fe1c6435dd7ed847857d    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 8 Apr 2016 16:30:02 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 8 Apr 2016 16:30:02 -0400    

Click here for diff

  
Now that 'dump' is a bitmap, we can't simply set it to 'true'.  
  
Noticed while debugging the prior issue.  
  

Add the “snapshot too old” feature

  
commit   : 848ef42bb8c7909c9d7baa38178d4a209906e7c1    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 8 Apr 2016 14:36:30 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 8 Apr 2016 14:36:30 -0500    

Click here for diff

  
This feature is controlled by a new old_snapshot_threshold GUC.  A  
value of -1 disables the feature, and that is the default.  The  
value of 0 is just intended for testing.  Above that it is the  
number of minutes a snapshot can reach before pruning and vacuum  
are allowed to remove dead tuples which the snapshot would  
otherwise protect.  The xmin associated with a transaction ID does  
still protect dead tuples.  A connection which is using an "old"  
snapshot does not get an error unless it accesses a page modified  
recently enough that it might not be able to produce accurate  
results.  
  
This is similar to the Oracle feature, and we use the same SQLSTATE  
and error message for compatibility.  
  

Modify BufferGetPage() to prepare for “snapshot too old” feature

  
commit   : 8b65cf4c5edabdcae45ceaef7b9ac236879aae50    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 8 Apr 2016 14:30:10 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 8 Apr 2016 14:30:10 -0500    

Click here for diff

  
This patch is a no-op patch which is intended to reduce the chances  
of failures of omission once the functional part of the "snapshot  
too old" patch goes in.  It adds parameters for snapshot, relation,  
and an enum to specify whether the snapshot age check needs to be  
done for the page at this point.  This initial patch passes NULL  
for the first two new parameters and BGP_NO_SNAPSHOT_TEST for the  
third.  The follow-on patch will change the places where the test  
needs to be made.  
  

In dumpTable, re-instate the skipping logic

  
commit   : 689f9a058854a1a32e994818dd6d79f49d8f8a1b    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 8 Apr 2016 15:00:44 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 8 Apr 2016 15:00:44 -0400    

Click here for diff

  
Pretty sure I removed this based on some incorrect thinking that it was  
no longer possible to reach this point for a table which will not be  
dumped, but that's clearly wrong.  
  
Pointed out on IRC by Erik Rijkers.  
  

Revert CREATE INDEX … INCLUDING …

  
commit   : 8b99edefcab1e82c43139a2c7dc06d31fb27b3e4    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 8 Apr 2016 21:52:13 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 8 Apr 2016 21:52:13 +0300    

Click here for diff

  
It's not ready yet, revert two commits  
690c543550b0d2852060c18d270cdb534d339d9a - unstable test output  
386e3d7609c49505e079c40c65919d99feb82505 - patch itself  
  

Add authentication parameters compat_realm and upn_usename for SSPI

  
commit   : 35e2e357cb054dc9e5d890fe754c56f0722f015e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 8 Apr 2016 20:23:52 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 8 Apr 2016 20:23:52 +0200    

Click here for diff

  
These parameters are available for SSPI authentication only, to make  
it possible to make it behave more like "normal gssapi", while  
making it possible to maintain compatibility.  
  
compat_realm is on by default, but can be turned off to make the  
authentication use the full Kerberos realm instead of the NetBIOS name.  
  
upn_username is off by default, and can be turned on to return the users  
Kerberos UPN rather than the SAM-compatible name (a user in Active  
Directory can have both a legacy SAM-compatible username and a new  
Kerberos one. Normally they are the same, but not always)  
  
Author: Christian Ullrich  
Reviewed by: Robbie Harwood, Alvaro Herrera, me  
  

Fix possible use of uninitialised value in ts_headline()

  
commit   : cb0c8cbf316f9362c11d7a8356e6f459258ae78e    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 8 Apr 2016 21:25:14 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 8 Apr 2016 21:25:14 +0300    

Click here for diff

  
Found during investigation of failure of skink buildfarm member and its  
valgrind report.  
  
Backpatch to all supported branches  
  

Fix unstable regression test output.

  
commit   : 690c543550b0d2852060c18d270cdb534d339d9a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Apr 2016 14:15:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Apr 2016 14:15:12 -0400    

Click here for diff

  
Output order from the pg_indexes view might vary depending on the  
phase of the moon, so add ORDER BY to ensure stable results of tests  
added by commit 386e3d7609c49505e079c40c65919d99feb82505.  
Per buildfarm.  
  

Distrust external OpenSSL clients; clear err queue

  
commit   : 7c7d4fddab82dc756d8caa67b1b31fcdde355aab    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Apr 2016 13:48:14 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Apr 2016 13:48:14 -0400    

Click here for diff

  
OpenSSL has an unfortunate tendency to mix per-session state error  
handling with per-thread error handling.  This can cause problems when  
programs that link to libpq with OpenSSL enabled have some other use of  
OpenSSL; without care, one caller of OpenSSL may cause problems for the  
other caller.  Backend code might similarly be affected, for example  
when a third party extension independently uses OpenSSL without taking  
the appropriate precautions.  
  
To fix, don't trust other users of OpenSSL to clear the per-thread error  
queue.  Instead, clear the entire per-thread queue ahead of certain I/O  
operations when it appears that there might be trouble (these I/O  
operations mostly need to call SSL_get_error() to check for success,  
which relies on the queue being empty).  This is slightly aggressive,  
but it's pretty clear that the other callers have a very dubious claim  
to ownership of the per-thread queue.  Do this is both frontend and  
backend code.  
  
Finally, be more careful about clearing our own error queue, so as to  
not cause these problems ourself.  It's possibly that control previously  
did not always reach SSLerrmessage(), where ERR_get_error() was supposed  
to be called to clear the queue's earliest code.  Make sure  
ERR_get_error() is always called, so as to spare other users of OpenSSL  
the possibility of similar problems caused by libpq (as opposed to  
problems caused by a third party OpenSSL library like PHP's OpenSSL  
extension).  Again, do this is both frontend and backend code.  
  
See bug #12799 and https://bugs.php.net/bug.php?id=68276  
  
Based on patches by Dave Vitek and Peter Eisentraut.  
  
From: Peter Geoghegan <pg@bowt.ie>  
  

Add BSD authentication method.

  
commit   : 34c33a1f00259ce5e3e1d1b4a784037adfca6057    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Apr 2016 13:51:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Apr 2016 13:51:54 -0400    

Click here for diff

  
Create a "bsd" auth method that works the same as "password" so far as  
clients are concerned, but calls the BSD Authentication service to  
check the password.  This is currently only available on OpenBSD.  
  
Marisa Emerson, reviewed by Thomas Munro  
  

Add combine functions for various floating-point aggregates.

  
commit   : af025eed536d3842d085ed9e4f9107eb976575cc    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 8 Apr 2016 13:44:50 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 8 Apr 2016 13:44:50 -0400    

Click here for diff

  
This allows parallel aggregation to use them.  It may seem surprising  
that we use float8_combine for both float4_accum and float8_accum  
transition functions, but that's because those functions differ only  
in the type of the non-transition-state argument.  
  
Haribabu Kommi, reviewed by David Rowley and Tomas Vondra  
  

Fix output of regression test of contrib/tsearch2

  
commit   : 38627f687823eae57e932c3b234656342403e909    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 8 Apr 2016 20:37:12 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 8 Apr 2016 20:37:12 +0300    

Click here for diff

  
Just forget to add in 1ec4c7c055ca045c5df6352a4cdacd9aa778e598  
  

Restore original tsquery operation numbering.

  
commit   : 1ec4c7c055ca045c5df6352a4cdacd9aa778e598    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 8 Apr 2016 20:11:30 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 8 Apr 2016 20:11:30 +0300    

Click here for diff

  
As noticed by Tom Lane changing operation's number in commit  
bb140506df605fab58f48926ee1db1f80bdafb59 causes on-disk format incompatibility.  
Revert to previous numbering, that is reason to add special array to store  
priorities of operation. Also it reverts order of tsquery to previous.  
  
Author: Dmitry Ivanov  
  

Silence warning from modern perl about unescaped braces

  
commit   : 76a1c97bf21c301f61bb41345e0cdd0d365b2086    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 8 Apr 2016 12:50:30 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 8 Apr 2016 12:50:30 -0400    

Click here for diff

  
  

CREATE INDEX … INCLUDING (column[, …])

  
commit   : 386e3d7609c49505e079c40c65919d99feb82505    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 8 Apr 2016 19:31:49 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 8 Apr 2016 19:31:49 +0300    

Click here for diff

  
Now indexes (but only B-tree for now) can contain "extra" column(s) which  
doesn't participate in index structure, they are just stored in leaf  
tuples. It allows to use index only scan by using single index instead  
of two or more indexes.  
  
Author: Anastasia Lubennikova with minor editorializing by me  
Reviewers: David Rowley, Peter Geoghegan, Jeff Janes  
  

Replace printf format %i by %d

  
commit   : 339025c68f95d3cb2c42478109cafeaf414c7fe0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Apr 2016 12:40:15 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Apr 2016 12:40:15 -0400    

Click here for diff

  
see also ce8d7bb6440710058503d213b2aafcdf56a5b481  
  

Turn down MSVC compiler verbosity

  
commit   : 01a07e6c11562127ad5e6f58d3d6128416b8ab65    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 8 Apr 2016 12:25:10 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 8 Apr 2016 12:25:10 -0400    

Click here for diff

  
Most of what is produced by the detailed verbosity level is of no  
interest at all, so switch to the normal level for more usable output.  
  
Christian Ullrich  
  
Backpatch to all live branches  
  

Fix printf format

  
commit   : 8b737f90843157706b8b5eb401b2aff08da77781    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Apr 2016 12:31:44 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Apr 2016 12:31:44 -0400    

Click here for diff

  
  

  
commit   : 93c301fc4ff7d4f06bff98fea8db47ce67f28155    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Apr 2016 12:31:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Apr 2016 12:31:42 -0400    

Click here for diff

  
Don't try to examine S_ISLNK(st.st_mode) after a failed lstat().  
It's undefined.  
  
Also, if the lstat() reported ENOENT, we do not wish that to be a hard  
error, but the code might nonetheless treat it as one (giving an entirely  
misleading error message, too) depending on luck-of-the-draw as to what  
S_ISLNK() returned.  
  
Don't throw error for ENOENT from rmdir(), either.  (We're not really  
expecting ENOENT because we just stat'd the file successfully; but  
if we're going to allow ENOENT in the symlink code path, surely the  
directory code path should too.)  
  
Generate an appropriate errcode for its-the-wrong-type-of-file complaints.  
(ERRCODE_SYSTEM_ERROR doesn't seem appropriate, and failing to write  
errcode() around it certainly doesn't work, and not writing an errcode  
at all is not per project policy.)  
  
Valgrind noticed the undefined S_ISLNK result; the other problems emerged  
while reading the code in the area.  
  
All of this appears to have been introduced in 8f15f74a44f68f9c.  
Back-patch to 9.5 where that commit appeared.  
  

Document which aggregates support partial mode.

  
commit   : 752b948dfca23ca8229d4490adc1d54be41c09a3    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 8 Apr 2016 12:09:58 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 8 Apr 2016 12:09:58 -0400    

Click here for diff