PostgreSQL 9.5.0 commit log

commit   : cdd4ed5449bf317cc71b45a8deee0173822e7592    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Jan 2016 16:29:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Jan 2016 16:29:34 -0500    

commit   : d878b115c350c18c0c9836c7652d5a179b5f9a33    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Jan 2016 15:11:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Jan 2016 15:11:44 -0500    

Commit 43cd468cf01007f3 added some wording to create_policy.sgml purporting  
to warn users against a race condition of the sort that had been noted some  
time ago by Peter Geoghegan.  However, that warning was far too vague to be  
useful (or at least, I completely failed to grasp what it was on about).  
Since the problem case occurs with a security design pattern that lots of  
people are likely to try to use, we need to be as clear as possible about  
it.  Provide a concrete example in the main-line docs in place of the  
original warning.  

commit   : 6a77404f5cd9380ccae24414d3f178e79011e96d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Jan 2016 12:21:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Jan 2016 12:21:31 -0500    

Some time back we agreed that row_security=off should not be a way to  
bypass RLS entirely, but only a way to get an error if it was being  
applied.  However, the code failed to act that way for table owners.  
Per discussion, this is a must-fix bug for 9.5.0.  
  
Adjust the logic in rls.c to behave as expected; also, modify the  
error message to be more consistent with the new interpretation.  
The regression tests need minor corrections as well.  Also update  
the comments about row_security in ddl.sgml to be correct.  (The  
official description of the GUC in config.sgml is already correct.)  
  
I failed to resist the temptation to do some other very minor  
cleanup as well, such as getting rid of a duplicate extern declaration.  

commit   : fa39e891b08a5cb283a721592d0fa2c19b4c7176    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 4 Jan 2016 10:12:37 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 4 Jan 2016 10:12:37 -0500    

Masahiko Sawada  

commit   : 00dfd5c94c41685e867e3a686900cc2f9e4dd829    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 4 Jan 2016 08:18:48 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 4 Jan 2016 08:18:48 -0500    

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

commit   : de93252386e25b78400228b08326a50c43dd232b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Jan 2016 01:53:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Jan 2016 01:53:24 -0500    

We discussed this but somehow failed to implement it...  

commit   : fa038f830b64779475b746a6840db9bdd0298d80    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Jan 2016 01:03:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Jan 2016 01:03:53 -0500    

Aside from any consistency arguments, this is logically necessary because  
the I/O functions for these types also handle numeric OID values.  Without  
a quoting rule it is impossible to distinguish numeric OIDs from role or  
namespace names that happen to contain only digits.  
  
Also change the to_regrole and to_regnamespace functions to dequote their  
arguments.  While not logically essential, this seems like a good idea  
since the other to_reg* functions do it.  Anyone who really wants raw  
lookup of an uninterpreted name can fall back on the time-honored solution  
of (SELECT oid FROM pg_namespace WHERE nspname = whatever).  
  
Report and patch by Jim Nasby, reviewed by Michael Paquier  

commit   : c244a511ba7f40dd43516eb025b1b299f2978f23    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jan 2016 20:53:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jan 2016 20:53:35 -0500    

Can't release the AccessExclusiveLock on the target table until commit.  
Otherwise there is a race condition whereby other backends might service  
our cache invalidation signals before they can actually see the updated  
catalog rows.  
  
Just to add insult to injury, RemovePolicyById was closing the rel (with  
incorrect lock drop) and then passing the now-dangling rel pointer to  
CacheInvalidateRelcache.  Probably the reason this doesn't fall over on  
CLOBBER_CACHE buildfarm members is that some outer level of the DROP logic  
is still holding the rel open ... but it'd have bit us on the arse  
eventually, no doubt.  

commit   : 35adf6e44cb65111f7caf5a9988c0738790ef02d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jan 2016 20:04:11 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jan 2016 20:04:11 -0500    

Clarifications, markup improvements, corrections of misleading or  
outright wrong statements.  

commit   : ab1f08a3a4a855cb9245456866918706ca2fdf06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jan 2016 16:26:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jan 2016 16:26:38 -0500    

The CHECK_IS_BINARY_UPGRADE macro is not sufficient security protection  
if we're going to dereference pass-by-reference arguments before it.  
  
But in any case we really need to explicitly check PG_ARGISNULL for all  
the arguments of a non-strict function, not only the ones we expect null  
values for.  
  
Oversight in commits 30982be4e5019684e1772dd9170aaa53f5a8e894 and  
f92fc4c95ddcc25978354a8248d3df22269201bc.  Found by Andreas Seltenreich.  
(The other usages in pg_upgrade_support.c seem safe.)  

commit   : 2e5c9284f688d124b0169ff5b86003ca86842666    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jan 2016 16:03:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jan 2016 16:03:42 -0500    

Minor grammar and markup improvements.  

commit   : 78d0e582ab1087d0cde9d00d8c8994591ae3c955    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jan 2016 15:33:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jan 2016 15:33:12 -0500    

commit   : 29692bdbb1dffed0eda38ad8268655425a7dcdf5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jan 2016 13:56:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jan 2016 13:56:29 -0500    

pgwin32_recv() has treated a non-error return of zero bytes from WSARecv()  
as being a reason to block ever since the current implementation was  
introduced in commit a4c40f140d23cefb.  However, so far as one can tell  
from Microsoft's documentation, that is just wrong: what it means is  
graceful connection closure (in stream protocols) or receipt of a  
zero-length message (in message protocols), and neither case should result  
in blocking here.  The only reason the code worked at all was that control  
then fell into the retry loop, which did *not* treat zero bytes specially,  
so we'd get out after only wasting some cycles.  But as of 9.5 we do not  
normally reach the retry loop and so the bug is exposed, as reported by  
Shay Rojansky and diagnosed by Andres Freund.  
  
Remove the unnecessary test on the byte count, and rearrange the code  
in the retry loop so that it looks identical to the initial sequence.  
  
Back-patch to 9.5.  The code is wrong all the way back, AFAICS, but  
since it's relatively harmless in earlier branches we'll leave it alone.  

commit   : b01828e97df66b7ae5e1f8a583e2dc509e13a365    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Jan 2016 19:04:45 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Jan 2016 19:04:45 -0500    

Commit c7e27becd2e6eb93 fixed this on the backend side, but we neglected  
the fact that several code paths in pg_dump were printing reloptions  
values that had not gotten massaged by ruleutils.  Apply essentially the  
same quoting logic in those places, too.  

commit   : 701303590053e100aa3a4ea87ac498d7fe00243f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Jan 2016 16:24:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Jan 2016 16:24:50 -0500    

spg_text_inner_consistent is capable of reconstructing an empty string  
to pass down to the next index level; this happens if we have an empty  
string coming in, no prefix, and a dummy node label.  (In practice, what  
is needed to trigger that is insertion of a whole bunch of empty-string  
values.)  Then, we will arrive at the next level with in->level == 0  
and a non-NULL (but zero length) in->reconstructedValue, which is valid  
but the Assert tests weren't expecting it.  
  
Per report from Andreas Seltenreich.  This has no impact in non-Assert  
builds, so should not be a problem in production, but back-patch to  
all affected branches anyway.  
  
In passing, remove a couple of useless variable initializations and  
shorten the code by not duplicating DatumGetPointer() calls.  

commit   : 9200e5664405600ab0bf588a8ff48621682b9fa2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Jan 2016 15:29:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Jan 2016 15:29:03 -0500    

As pointed out by Michael Paquier, recovery_min_apply_delay didn't exist  
in 9.0-9.3, making the release note text not very useful.  Instead make it  
talk about recovery_target_xid, which did exist then.  
  
9.0 is already out of support, but we can fix the text in the newer  
branches' copies of its release notes.  

commit   : d47bc474b325099da381aa52a3a2a95354a2c80e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 2 Jan 2016 13:33:39 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 2 Jan 2016 13:33:39 -0500    

Backpatch certain files through 9.1  

commit   : 404c45bac64d312033dcf0373f7b1c0133b03afc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jan 2016 15:27:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jan 2016 15:27:53 -0500    

flatten_reloptions() supposed that it didn't really need to do anything  
beyond inserting commas between reloption array elements.  However, in  
principle the value of a reloption could be nearly anything, since the  
grammar allows a quoted string there.  Any restrictions on it would come  
from validity checking appropriate to the particular option, if any.  
  
A reloption value that isn't a simple identifier or number could thus lead  
to dump/reload failures due to syntax errors in CREATE statements issued  
by pg_dump.  We've gotten away with not worrying about this so far with  
the core-supported reloptions, but extensions might allow reloption values  
that cause trouble, as in bug #13840 from Kouhei Sutou.  
  
To fix, split the reloption array elements explicitly, and then convert  
any value that doesn't look like a safe identifier to a string literal.  
(The details of the quoting rule could be debated, but this way is safe  
and requires little code.)  While we're at it, also quote reloption names  
if they're not safe identifiers; that may not be a likely problem in the  
field, but we might as well try to be bulletproof here.  
  
It's been like this for a long time, so back-patch to all supported  
branches.  
  
Kouhei Sutou, adjusted some by me  

commit   : d932391fd832aa62c5f86ddf7012622bb01bde9a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jan 2016 13:42:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jan 2016 13:42:21 -0500    

A report from Andy Colson showed that gincostestimate() was not being  
nearly paranoid enough about whether to believe the statistics it finds in  
the index metapage.  The problem is that the metapage stats (other than the  
pending-pages count) are only updated by VACUUM, and in the worst case  
could still reflect the index's original empty state even when it has grown  
to many entries.  We attempted to deal with that by scaling up the stats to  
match the current index size, but if nEntries is zero then scaling it up  
still gives zero.  Moreover, the proportion of pages that are entry pages  
vs. data pages vs. pending pages is unlikely to be estimated very well by  
scaling if the index is now orders of magnitude larger than before.  
  
We can improve matters by expanding the use of the rule-of-thumb estimates  
I introduced in commit 7fb008c5ee59b040: if the index has grown by more  
than a cutoff amount (here set at 4X growth) since VACUUM, then use the  
rule-of-thumb numbers instead of scaling.  This might not be exactly right  
but it seems much less likely to produce insane estimates.  
  
I also improved both the scaling estimate and the rule-of-thumb estimate  
to account for numPendingPages, since it's reasonable to expect that that  
is accurate in any case, and certainly pages that are in the pending list  
are not either entry or data pages.  
  
As a somewhat separate issue, adjust the estimation equations that are  
concerned with extra fetches for partial-match searches.  These equations  
suppose that a fraction partialEntries / numEntries of the entry and data  
pages will be visited as a consequence of a partial-match search.  Now,  
it's physically impossible for that fraction to exceed one, but our  
estimate of partialEntries is mostly bunk, and our estimate of numEntries  
isn't exactly gospel either, so we could arrive at a silly value.  In the  
example presented by Andy we were coming out with a value of 100, leading  
to insane cost estimates.  Clamp the fraction to one to avoid that.  
  
Like the previous patch, back-patch to all supported branches; this  
problem can be demonstrated in one form or another in all of them.  

commit   : 2d774aaf1801b0338241cca9409803451ef28a6a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jan 2016 13:00:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 Jan 2016 13:00:13 -0500    

Commit a2e35b53c39b2a27 added an #include of catalog/objectaddress.h to  
pg_operator.h, making it impossible for client-side code to #include  
pg_operator.h.  It's not entirely clear whether any client-side code needs  
to include pg_operator.h, but it seems prudent to assume that there is some  
such code somewhere.  Therefore, split off the function definitions into a  
new file pg_operator_fn.h, similarly to what we've done for some other  
catalog header files.  
  
Back-patch of part of commit 0dab5ef39b3d9d86.  

commit   : 69892d58c9881acac934629187c7301f8e296eb4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 Dec 2015 17:59:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 Dec 2015 17:59:10 -0500    

postgresImportForeignSchema pays attention to IMPORT's EXCEPT and LIMIT TO  
options, but only as an efficiency hack, not for correctness' sake.  The  
FDW documentation does explain that, but someone using postgres_fdw.c  
as a coding guide might not remember it, so let's add a comment here.  
Per question from Regina Obe.  

commit   : 30858be2f83b57517f84ce2e149f2d1c536c0252    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Dec 2015 16:45:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Dec 2015 16:45:47 -0500    

Commit 6f8cb1e23485bd6d tried to centralize rewriteTargetView's copying  
of a target view's Query struct.  However, it ignored the fact that the  
jointree->quals field was used twice.  This only accidentally failed to  
fail immediately because the same ChangeVarNodes mutation is applied in  
both cases, so that we end up with logically identical expression trees  
for both uses (and, as the code stands, the second ChangeVarNodes call  
actually does nothing).  However, we end up linking *physically*  
identical expression trees into both an RTE's securityQuals list and  
the WithCheckOption list.  That's pretty dangerous, mainly because  
prepsecurity.c is utterly cavalier about further munging such structures  
without copying them first.  
  
There may be no live bug in HEAD as a consequence of the fact that we apply  
preprocess_expression in between here and prepsecurity.c, and that will  
make a copy of the tree anyway.  Or it may just be that the regression  
tests happen to not trip over it.  (I noticed this only because things  
fell over pretty badly when I tried to relocate the planner's call of  
expand_security_quals to before expression preprocessing.)  In any case  
it's very fragile because if anyone tried to make the securityQuals and  
WithCheckOption trees diverge before we reach preprocess_expression, it  
would not work.  The fact that the current code will preprocess  
securityQuals and WithCheckOptions lists at completely different times in  
different query levels does nothing to increase my trust that that can't  
happen.  
  
In view of the fact that 9.5.0 is almost upon us and the aforesaid commit  
has seen exactly zero field testing, the prudent course is to make an extra  
copy of the quals so that the behavior is not different from what has been  
in the field during beta.  

commit   : 282fdfcdc8a8f987c06e839d581b94bf196def8a    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Mon, 28 Dec 2015 12:35:16 -0800    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Mon, 28 Dec 2015 12:35:16 -0800    

The variables newestCommitTs and oldestCommitTs sound as if they are  
timestamps, but in fact they are the transaction Ids that correspond  
to the newest and oldest timestamps rather than the actual timestamps.  
Rename these variables to reflect that they are actually xids: to wit  
newestCommitTsXid and oldestCommitTsXid respectively. Also modify  
related code in a similar fashion, particularly the user facing output  
emitted by pg_controldata and pg_resetxlog.  
  
Complaint and patch by me, review by Tom Lane and Alvaro Herrera.  
Backpatch to 9.5 where these variables were first introduced.  

commit   : 5bf939411ce7a4ae87cee65daca2e4add44b2b46    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 28 Dec 2015 15:28:19 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 28 Dec 2015 15:28:19 -0300    

Pointer out by Jeff Janes  

commit   : 508a26e2468fc4bb35f4b002552c304d51d97890    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2015 12:09:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2015 12:09:00 -0500    

Common mathematical convention is that exponentiation associates right to  
left.  We aren't going to change the parser for this, but we could note  
it in the operator's description.  (It's already noted in the operator  
precedence/associativity table, but users might not look there.)  
Per bug #13829 from Henrik Pauli.  

commit   : 3479b7984b01058993276d3d26ef47ec298ee219    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 28 Dec 2015 13:45:03 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 28 Dec 2015 13:45:03 -0300    

Reported by: Alain Laporte (#13836)  

commit   : ea786b278c2471c69602c4b268be1ce90340e408    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2015 11:04:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Dec 2015 11:04:42 -0500    

Tone down an overly strong statement about which pseudo-types PLs are  
likely to allow.  Add "event_trigger" to the list, as well as  
"pg_ddl_command" in 9.5/HEAD.  Back-patch to 9.3 where event_trigger  
was added.  

commit   : c3e068b26185e6c667dbb45f05bb2466ed11cfea    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 28 Dec 2015 10:50:35 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 28 Dec 2015 10:50:35 -0300    

For some reason, we've been overlooking the fact that pg_receivexlog  
and pg_recvlogical are using wrong translation domains all along,  
so their output hasn't ever been translated.  The right domain is  
pg_basebackup, not their own executable names.  
  
Noticed by Ioseph Kim, who's been working on the Korean translation.  
  
Backpatch pg_receivexlog to 9.2 and pg_recvlogical to 9.4.  

commit   : c886c30cc8731a3fab989a2b361fd38c5bb1ad53    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 27 Dec 2015 13:03:19 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 27 Dec 2015 13:03:19 -0300    

Both Blowfish and DES implementations of crypt() can take arbitrarily  
long time, depending on the number of rounds specified by the caller;  
make sure they can be interrupted.  
  
Author: Andreas Karlsson  
Reviewer: Jeff Janes  
  
Backpatch to 9.1.  

commit   : e10838026b373f01d1de0f4f7ea80a60c30565da    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Dec 2015 12:56:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Dec 2015 12:56:09 -0500    

brin_summarize_new_values() did not check that the passed OID was for  
an index at all, much less that it was a BRIN index, and would fail in  
obscure ways if it wasn't (possibly damaging data first?).  It also  
lacked any permissions test; by analogy to VACUUM, we should only allow  
the table's owner to summarize.  
  
Noted by Jeff Janes, fix by Michael Paquier and me  

commit   : 2e947ba977eba1c0c31a2981d090b7b1897c49c2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Dec 2015 11:38:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Dec 2015 11:38:31 -0500    

t/002_databases.pl was expecting to see a specific physical order of the  
rows in pg_database.  I broke that in HEAD with commit 01e386a325549b77,  
but I'd say it's a pretty fragile test methodology in any case, so fix  
it in 9.5 as well.  

commit   : 0bdcb04c7d9c72bf9071b4a3d4ffc3d37ddad89e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Dec 2015 10:50:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Dec 2015 10:50:03 -0500    

pg_replication_session_is_setup() exists nowhere; apparently this is  
meant to refer to pg_replication_origin_session_is_setup().  
  
Adrien Nayrat  

commit   : 84b363fb3476f5c5b3bb159d457aaf9966ba6b2d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Dec 2015 10:42:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Dec 2015 10:42:58 -0500    

Amit Langote, further adjusted by me  

commit   : 3945b6193240cd7fcb5ad3c67e9dca7f12d68b7e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Dec 2015 15:45:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Dec 2015 15:45:43 -0500    

This reverts most of commit 83dec5a71 in favor of having connectDatabase()  
store the possibly-reusable password in a static variable, similar to the  
coding we've had for a long time in pg_dump's version of that function.  
To avoid possible problems with unwanted password reuse, make callers  
specify whether it's reasonable to attempt to re-use the password.  
This is a wash for cases where re-use isn't needed, but it is far simpler  
for callers that do want that.  Functionally there should be no difference.  
  
Even though we're past RC1, it seems like a good idea to back-patch this  
into 9.5, like the prior commit.  Otherwise, if there are any third-party  
users of connectDatabase(), they'll have to deal with an API change in  
9.5 and then another one in 9.6.  
  
Michael Paquier  

commit   : a21994c1bf9e61d263a870c98ba1e5f559107b4e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Dec 2015 14:25:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Dec 2015 14:25:31 -0500    

When pg_dump prompts the user for a password, it remembers the password  
for possible re-use by parallel worker processes.  However, libpq might  
have extracted the password from a connection string originally passed  
as "dbname".  Since we don't record the original form of dbname but  
break it down to host/port/etc, the password gets lost.  Fix that by  
retrieving the actual password from the PGconn.  
  
(It strikes me that this whole approach is rather broken, as it will also  
lose other information such as options that might have been present in  
the connection string.  But we'll leave that problem for another day.)  
  
In passing, get rid of rather silly use of malloc() for small fixed-size  
arrays.  
  
Back-patch to 9.3 where parallel pg_dump was introduced.  
  
Report and fix by Zeus Kronion, adjusted a bit by Michael Paquier and me  

commit   : 120b31dc5406cf004b99150b84b48dc312577eca    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 22 Dec 2015 13:57:18 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 22 Dec 2015 13:57:18 -0500    

Peter Geoghegan and Robert Haas  

commit   : 496943ec2b6de0f22cd9e18f673e13635b5972ef    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 21 Dec 2015 10:34:20 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 21 Dec 2015 10:34:20 -0500    

Rather than expect the Query returned by get_view_query() to be  
read-only and then copy bits and pieces of it out, simply copy the  
entire structure when we get it.  This addresses an issue where  
AcquireRewriteLocks, which is called by acquireLocksOnSubLinks(),  
scribbles on the parsetree passed in, which was actually an entry  
in relcache, leading to segfaults with certain view definitions.  
This also future-proofs us a bit for anyone adding more code to this  
path.  
  
The acquireLocksOnSubLinks() was added in commit c3e0ddd40.  
  
Back-patch to 9.3 as that commit was.  

commit   : 0c28e767c612c9e90ae8ab188cf9b21114a34ddc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 Dec 2015 18:29:51 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 Dec 2015 18:29:51 -0500    

psql offered USING, WHERE, and SET in this context, but SET is not a valid  
possibility here.  Seems to have been a thinko in commit f5ab0a14ea83eb6c  
which added DELETE's USING option.  

commit   : 9ade78c65e1b98d2a8336be37d0442a53233c3b1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 20 Dec 2015 11:50:04 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 20 Dec 2015 11:50:04 -0500    

commit   : 3ef762e7d806f18db743fd10bbf75a9b2631033c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Dec 2015 16:55:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Dec 2015 16:55:14 -0500    

Commit e5e11c8cc added a bunch of EXPLAIN statements without COSTS OFF  
to the regression tests.  This is contrary to project policy since it  
results in unnecessary platform dependencies in the output (it's just  
luck that we didn't get buildfarm failures from it).  Per gripe from  
Mike Wilson.  

commit   : 8ae22e7d36e349d7d8fd616fbf7f78cc03e301e0    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 19 Dec 2015 17:37:11 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 19 Dec 2015 17:37:11 +0100    

Previously the completion used the wrong word to match 'BY'. This was  
introduced brokenly, in b2de2a. While at it, also add completion of  
IN TABLESPACE ... OWNED BY and fix comments referencing nonexistent  
syntax.  
  
Reported-By: Michael Paquier  
Author: Michael Paquier and Andres Freund  
Discussion: CAB7nPqSHDdSwsJqX0d2XzjqOHr==HdWiubCi4L=Zs7YFTUne8w@mail.gmail.com  
Backpatch: 9.4, like the commit introducing the bug  

commit   : 2c5b57ec7f0155eef7bd8d152e546ee96b2feb5e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 18 Dec 2015 13:24:51 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 18 Dec 2015 13:24:51 -0500    

Per a recommendation from Tomas Vondra, it's more helpful to refer to  
the value that determines how skewed a Gaussian or exponential  
distribution is as a parameter rather than a threshold.  
  
Since it's not quite too late to get this right in 9.5, where it was  
introduced, back-patch this.  Most of the patch changes only comments  
and documentation, but a few pgbench messages are altered to match.  
  
Fabien Coelho, reviewed by Michael Paquier and by me.  

commit   : 550e9c23053c2540620dd0f72525ce2e47fd40a5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 18 Dec 2015 12:17:35 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 18 Dec 2015 12:17:35 -0500    

This could result in the error context misidentifying where the error  
actually occurred.  
  
Craig Ringer  

commit   : 30020c3fc3b6de5592978313df929d370f5770ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Dec 2015 20:21:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Dec 2015 20:21:42 -0500    

datapagemap_create() and datapagemap_destroy() were declared extern,  
but they don't actually exist anywhere.  Per YUriy Zhuravlev and  
Michael Paquier.  

commit   : 5ec0aad018c3f36f9bd3e844f20562fb3c5d4590    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Dec 2015 16:55:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Dec 2015 16:55:23 -0500    

Turns out we must set rl_basic_word_break_characters *before* we call  
rl_initialize() the first time, because it will quietly copy that value  
elsewhere --- but only on the first call.  (Love these undocumented  
dependencies.)  I broke this yesterday in commit 2ec477dc8108339d;  
like that commit, back-patch to all active branches.  Per report from  
Pavel Stehule.  

commit   : 0c6881fd142383845974ac836f3e6476cbe974ee    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 17 Dec 2015 14:25:41 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 17 Dec 2015 14:25:41 -0300    

This is necessary so that REASSIGN OWNED does the right thing with  
composite types, to wit, that it also alters ownership of the type's  
pg_class entry -- previously, the pg_class entry remained owned by the  
original user, which caused later other failures such as the new owner's  
inability to use ALTER TYPE to rename an attribute of the affected  
composite.  Also, if the original owner is later dropped, the pg_class  
entry becomes owned by a non-existant user which is bogus.  
  
To fix, create a new routine AlterTypeOwner_oid which knows whether to  
pass the request to ATExecChangeOwner or deal with it directly, and use  
that in shdepReassignOwner rather than calling AlterTypeOwnerInternal  
directly.  AlterTypeOwnerInternal is now simpler in that it only  
modifies the pg_type entry and recurses to handle a possible array type;  
higher-level tasks are handled by either AlterTypeOwner directly or  
AlterTypeOwner_oid.  
  
I took the opportunity to add a few more objects to the test rig for  
REASSIGN OWNED, so that more cases are exercised.  Additional ones could  
be added for superuser-only-ownable objects (such as FDWs and event  
triggers) but I didn't want to push my luck by adding a new superuser to  
the tests on a backpatchable bug fix.  
  
Per bug #13666 reported by Chris Pacejo.  
  
Backpatch to 9.5.  
  
(I would back-patch this all the way back, except that it doesn't apply  
cleanly in 9.4 and earlier because 59367fdf9 wasn't backpatched.  If we  
decide that we need this in earlier branches too, we should backpatch  
both.)  

commit   : f1c152866c4a0786e4ec5504348c10735456f630    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Dec 2015 16:58:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Dec 2015 16:58:55 -0500    

It emerges that libreadline doesn't notice terminal window size change  
events unless they occur while collecting input.  This is easy to stumble  
over if you resize the window while using a pager to look at query output,  
but it can be demonstrated without any pager involvement.  The symptom is  
that queries exceeding one line are misdisplayed during subsequent input  
cycles, because libreadline has the wrong idea of the screen dimensions.  
  
The safest, simplest way to fix this is to call rl_reset_screen_size()  
just before calling readline().  That causes an extra ioctl(TIOCGWINSZ)  
for every command; but since it only happens when reading from a tty, the  
performance impact should be negligible.  A more valid objection is that  
this still leaves a tiny window during entry to readline() wherein delivery  
of SIGWINCH will be missed; but the practical consequences of that are  
probably negligible.  In any case, there doesn't seem to be any good way to  
avoid the race, since readline exposes no functions that seem safe to call  
from a generic signal handler --- rl_reset_screen_size() certainly isn't.  
  
It turns out that we also need an explicit rl_initialize() call, else  
rl_reset_screen_size() dumps core when called before the first readline()  
call.  
  
rl_reset_screen_size() is not present in old versions of libreadline,  
so we need a configure test for that.  (rl_initialize() is present at  
least back to readline 4.0, so we won't bother with a test for it.)  
We would need a configure test anyway since libedit's emulation of  
libreadline doesn't currently include such a function.  Fortunately,  
libedit seems not to have any corresponding bug.  
  
Merlin Moncure, adjusted a bit by me  

commit   : 8abb52fa2971e16844d2a3e61b92fa347dc49d45    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Dec 2015 17:25:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Dec 2015 17:25:44 -0500    

commit   : 3ac806ccb5207810c7fe947ee44de4d242d42f97    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Dec 2015 16:57:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Dec 2015 16:57:23 -0500    

Commit acd08d764 did not bother with updating the documentation.  

commit   : ddd78136764133b72bfe9102e60bbd49fa22b414    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Dec 2015 16:42:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Dec 2015 16:42:18 -0500    

Also do another round of copy-editing, and fix up remaining FIXME items.  

commit   : 46ae55c372761af5e02082ea934bebcba98040a4    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 15 Dec 2015 10:08:14 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 15 Dec 2015 10:08:14 -0500    

Clarify that SELECT policies are now applied when SELECT rights  
are required for a given query, even if the query is an UPDATE or  
DELETE query.  Pointed out by Noah.  
  
Additionally, note the risk regarding concurrently open transactions  
where a relation which controls access to the rows of another relation  
are updated and the rows of the primary relation are also being  
modified.  Pointed out by Peter Geoghegan.  
  
Back-patch to 9.5.  

commit   : 651e2ba74af997c2952672397828636dc6c6d017    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 14 Dec 2015 20:05:55 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 14 Dec 2015 20:05:55 -0500    

We carry around information about if a given query has row security or  
not to allow the plancache to use that information to invalidate a  
planned query in the event that the environment changes.  
  
Previously, the flag of one of the subqueries was simply being copied  
into place to indicate if the query overall included RLS components.  
That's wrong as we need the global OR of all subqueries.  Fix by  
changing the code to match how fireRIRules works, which is results  
in OR'ing all of the flags.  
  
Noted by Tom.  
  
Back-patch to 9.5 where RLS was introduced.  

commit   : 2c24f0f092acb59184c3a3ace4b6cea4ff308328    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Dec 2015 19:22:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Dec 2015 19:22:50 -0500    

Per Michael Paquier  

commit   : 4b021aa6103f49bece51d58fd5e307d4d03380bc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Dec 2015 18:21:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 14 Dec 2015 18:21:42 -0500    

This previously resulted in an error and a nonzero exit status, but  
after discussion this should rather be a noop with a zero exit status.  
  
This is a back-patch of commit 6b34e5563849edc12896bf5754e8fe7b88012697,  
plus two changes from commit e50cda78404d6400b1326a996a4fabb144871151  
that teach pg_rewind to allow the initial control file states to be  
DB_SHUTDOWNED_IN_RECOVERY as well as DB_SHUTDOWNED.  That's necessary  
to get the additional regression test case to pass, and the old behavior  
seems like rather a foot-gun anyway.  
  
Peter Eisentraut and Tom Lane  

commit   : 188675256e15f7ad4d24ae976d1bb5fbb84f43e1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 14 Dec 2015 16:44:40 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 14 Dec 2015 16:44:40 -0300    

Apparently, there are bugs in this code that cause it to loop endlessly.  
That bug still needs more research, but in the meantime it's clear that  
the loop is missing a check for interrupts so that it can be cancelled  
timely.  
  
Backpatch to 9.1 -- this has been missing since 49475aab8d0d.  

commit   : c6eced09b25d12d73b93a740f2d81c22bb7e3d1f    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Mon, 14 Dec 2015 11:46:47 -0600    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Mon, 14 Dec 2015 11:46:47 -0600    

This one test was behaving differently between the ubuntu fix for  
CVE-2015-7499 and the base "expected" file.  It's not worth having  
yet another version of the expected file for this test, so drop it.  
Perhaps at some point when all distros have settled down to the  
same behavior on this test, it can be restored.  
  
Problem found by me on libxml2 (2.9.1+dfsg1-3ubuntu4.6).  
Solution suggested by Tom Lane.  
Backpatch to 9.5, where the test was added.  

commit   : 34d136f92ac65c4ed8ede9459217ef900d603f97    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 14 Dec 2015 18:19:10 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 14 Dec 2015 18:19:10 +0200    

If libpq ran out of memory while constructing the result set, it would hang,  
waiting for more data from the server, which might never arrive. To fix,  
distinguish between out-of-memory error and not-enough-data cases, and give  
a proper error message back to the client on OOM.  
  
There are still similar issues in handling COPY start messages, but let's  
handle that as a separate patch.  
  
Michael Paquier, Amit Kapila and me. Backpatch to all supported versions.  

commit   : ccde00b9b97ed8b7307e39f95bd48922bf955bb2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 14 Dec 2015 11:34:16 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 14 Dec 2015 11:34:16 +0100    

Previously, if find_multixact_start() failed, SetOffsetVacuumLimit() would  
install 0 into MultiXactState->offsetStopLimit if it previously succeeded.  
Luckily, there are no known cases where find_multixact_start() will return  
an error in 9.5 and above. But if it were to happen, for example due to  
filesystem permission issues, it'd be somewhat bad: GetNewMultiXactId()  
could continue allocating mxids even if close to a wraparound, or it could  
erroneously stop allocating mxids, even if no wraparound is looming.  The  
wrong value would be corrected the next time SetOffsetVacuumLimit() is  
called, or by a restart.  
  
Reported-By: Noah Misch, although this is not his preferred fix  
Discussion: 20151210140450.GA22278@alap3.anarazel.de  
Backpatch: 9.5, where the bug was introduced as part of 4f627f  

commit   : cb89644bb0df1921c6a15aa294903a9458c2a67d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 14 Dec 2015 11:25:04 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 14 Dec 2015 11:25:04 +0100    

e3f4cfc7 introduced a LWLockHeldByMe() call, without the corresponding  
Assert() surrounding it.  
  
Spotted by Coverity.  
  
Backpatch: 9.1+, like the previous commit  

commit   : c9ed438817661238901f43ea10aab8f120ea837f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Dec 2015 23:42:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Dec 2015 23:42:54 -0500    

This has worked that way for a long time, maybe always, but you would  
not have known it from the documentation.  Also back-patch the notes  
I added to HEAD earlier today about behavior of the "-f -" switch,  
which likewise have been valid for many releases.  

commit   : 28c366789e78af82dfd89ecb6cc32724f58d6a1b    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 13 Dec 2015 16:53:38 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 13 Dec 2015 16:53:38 +0100    

Previously the "sent" field would be set to 0 and all other xlog  
pointers be set to NULL if there were no valid values (such as when  
in a backup sending walsender).  

commit   : a9c56ff0e1f19fd6c2e48cfe44407c8cb8c4fbd5    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 13 Dec 2015 16:40:37 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 13 Dec 2015 16:40:37 +0100    

These would leak random xlog positions if a walsender used for backup would  
a walsender slot previously used by a replication walsender.  
  
In passing also fix a couple of cases where the xlog pointer is directly  
compared to zero instead of using XLogRecPtrIsInvalid, noted by  
Michael Paquier.  

commit   : 332be65b5e6a99420dd9b2762fe3e5602538053d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Dec 2015 20:02:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Dec 2015 20:02:09 -0500    

Paul Ramsey  

commit   : ada9c09aebbe6c37d545fca29ac8c0e690158e80    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 12 Dec 2015 14:19:19 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 12 Dec 2015 14:19:19 +0100    

Changing the tablespace of an unlogged relation did not WAL log the  
creation and content of the init fork. Thus, after a standby is  
promoted, unlogged relation cannot be accessed anymore, with errors  
like:  
ERROR:  58P01: could not open file "pg_tblspc/...": No such file or directory  
Additionally the init fork was not synced to disk, independent of the  
configured wal_level, a relatively small durability risk.  
  
Investigation of that problem also brought to light that, even for  
permanent relations, the creation of !main forks was not WAL logged,  
i.e. no XLOG_SMGR_CREATE record were emitted. That mostly turns out not  
to be a problem, because these files were created when the actual  
relation data is copied; nonexistent files are not treated as an error  
condition during replay. But that doesn't work for empty files, and  
generally feels a bit haphazard. Luckily, outside init and main forks,  
empty forks don't occur often or are not a problem.  
  
Add the required WAL logging and syncing to disk.  
  
Reported-By: Michael Paquier  
Author: Michael Paquier and Andres Freund  
Discussion: 20151210163230.GA11331@alap3.anarazel.de  
Backpatch: 9.1, where unlogged relations were introduced  

commit   : ea7f7d8b322f0fd13419da1c0c46f7a9c74eef15    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Dec 2015 19:08:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Dec 2015 19:08:40 -0500    

Recent releases of libxml2 do not provide error context reports for errors  
detected at the very end of the input string.  This appears to be a bug, or  
at least an infelicity, introduced by the fix for libxml2's CVE-2015-7499.  
We can hope that this behavioral change will get undone before too long;  
but the security patch is likely to spread a lot faster/further than any  
follow-on cleanup, which means this behavior is likely to be present in the  
wild for some time to come.  As a stopgap, add a variant regression test  
expected-file that matches what you get with a libxml2 that acts this way.  

commit   : 31f88a12a0d9e340f7ccf49e5f133835499c981b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Dec 2015 18:39:09 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Dec 2015 18:39:09 -0300    

As reported in bug #13809 by Alexander Ashurkov, the code for REASSIGN  
OWNED hadn't gotten word about user mappings.  Deal with them in the  
same way default ACLs do, which is to ignore them altogether; they are  
handled just fine by DROP OWNED.  The other foreign object cases are  
already handled correctly by both commands.  
  
Also add a REASSIGN OWNED statement to foreign_data test to exercise the  
foreign data objects.  (The changes are just before the "cleanup" phase,  
so it shouldn't remove any existing live test.)  
  
Reported by Alexander Ashurkov, then independently by Jaime Casanova.  

commit   : 6061aa8ed763f1d9d37d402a0e5769c823dd797c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Dec 2015 16:14:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Dec 2015 16:14:27 -0500    

This allows sane behavior in a PGXS build done on a machine where build  
tools such as bison are missing.  
  
Jim Nasby  

commit   : fda18e46a65196b98d6ca4ce4911085b0d2f182f    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 11 Dec 2015 16:12:36 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 11 Dec 2015 16:12:36 -0500    

DROP OWNED BY handled GRANT-based ACLs but was not removing roles from  
policies.  Fix that by having DROP OWNED BY remove the role specified  
from the list of roles the policy (or policies) apply to, or the entire  
policy (or policies) if it only applied to the role specified.  
  
As with ACLs, the DROP OWNED BY caller must have permission to modify  
the policy or a WARNING is thrown and no change is made to the policy.  

commit   : dc4518814ecc2ae319c4d1679ee079e47dbd78e9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Dec 2015 15:52:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Dec 2015 15:52:16 -0500    

I originally modeled this data structure on SpecialJoinInfo, but after  
commit acfcd45cacb6df23 that looks like a pretty poor decision.  
All we really need is relid sets identifying laterally-referenced rels;  
and most of the time, what we want to know about includes indirect lateral  
references, a case the LateralJoinInfo data was unsuited to compute with  
any efficiency.  The previous commit redefined RelOptInfo.lateral_relids  
as the transitive closure of lateral references, so that it easily supports  
checking indirect references.  For the places where we really do want just  
direct references, add a new RelOptInfo field direct_lateral_relids, which  
is easily set up as a copy of lateral_relids before we perform the  
transitive closure calculation.  Then we can just drop lateral_info_list  
and LateralJoinInfo and the supporting code.  This makes the planner's  
handling of lateral references noticeably more efficient, and shorter too.  
  
Such a change can't be back-patched into stable branches for fear of  
breaking extensions that might be looking at the planner's data structures;  
but it seems not too late to push it into 9.5, so I've done so.  

commit   : 12a54c888cf7bd9c37c4ce420e84cb52debe0184    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 11 Dec 2015 15:44:03 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 11 Dec 2015 15:44:03 -0500    

ALTER POLICY hadn't fully considered partial policy alternation  
(eg: change just the roles on the policy, or just change one of  
the expressions) when rebuilding the dependencies.  Instead, it  
would happily remove all dependencies which existed for the  
policy and then only recreate the dependencies for the objects  
referred to in the specific ALTER POLICY command.  
  
Correct that by extracting and building the dependencies for all  
objects referenced by the policy, regardless of if they were  
provided as part of the ALTER POLICY command or were already in  
place as part of the pre-existing policy.  

commit   : 564c19e86eff3f2221471e60a963d55bd5f76954    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Dec 2015 14:22:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Dec 2015 14:22:20 -0500    

More fuzz testing by Andreas Seltenreich exposed that the planner did not  
cope well with chains of lateral references.  If relation X references Y  
laterally, and Y references Z laterally, then we will have to scan X on the  
inside of a nestloop with Z, so for all intents and purposes X is laterally  
dependent on Z too.  The planner did not understand this and would generate  
intermediate joins that could not be used.  While that was usually harmless  
except for wasting some planning cycles, under the right circumstances it  
would lead to "failed to build any N-way joins" or "could not devise a  
query plan" planner failures.  
  
To fix that, convert the existing per-relation lateral_relids and  
lateral_referencers relid sets into their transitive closures; that is,  
they now show all relations on which a rel is directly or indirectly  
laterally dependent.  This not only fixes the chained-reference problem  
but allows some of the relevant tests to be made substantially simpler  
and faster, since they can be reduced to simple bitmap manipulations  
instead of searches of the LateralJoinInfo list.  
  
Also, when a PlaceHolderVar that is due to be evaluated at a join contains  
lateral references, we should treat those references as indirect lateral  
dependencies of each of the join's base relations.  This prevents us from  
trying to join any individual base relations to the lateral reference  
source before the join is formed, which again cannot work.  
  
Andreas' testing also exposed another oversight in the "dangerous  
PlaceHolderVar" test added in commit 85e5e222b1dd02f1.  Simply rejecting  
unsafe join paths in joinpath.c is insufficient, because in some cases  
we will end up rejecting *all* possible paths for a particular join, again  
leading to "could not devise a query plan" failures.  The restriction has  
to be known also to join_is_legal and its cohort functions, so that they  
will not select a join for which that will happen.  I chose to move the  
supporting logic into joinrels.c where the latter functions are.  
  
Back-patch to 9.3 where LATERAL support was introduced.  

commit   : 0f2c089d3423bcf2bb11d1e5d2d38638cc31fec4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Dec 2015 14:30:43 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Dec 2015 14:30:43 -0300    

This module needs explicit initialization in order to replay WAL records  
in recovery, but we had broken this recently following changes to make  
other (stranger) scenarios work correctly.  To fix, rework the  
initialization sequence so that it always takes place before WAL replay  
commences for both master and standby.  
  
I could have gone for a more localized fix that just added a "startup"  
call for the master server, but it seemed better to restructure the  
existing callers as well so that the whole thing made more sense.  As a  
drawback, there is more control logic in xlog.c now than previously, but  
doing otherwise meant passing down the ControlFile flag, which seemed  
uglier as a whole.  
  
This also meant adding a check to not re-execute ActivateCommitTs if it  
had already been called.  
  
Reported by Fujii Masao.  
  
Backpatch to 9.5.  

commit   : 0fc7c4a557752652ebddddb55ad11228129b530e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 10 Dec 2015 22:05:27 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 10 Dec 2015 22:05:27 -0500    

commit   : dcf5d7fb14b3ec59b436ce27d843574b6407e5b4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Dec 2015 12:28:46 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Dec 2015 12:28:46 -0500    

Complete "ALTER POLICY" with a policy name, as we do for DROP POLICY.  
And, complete "ALTER POLICY polname ON" with a table name that has such  
a policy, as we do for DROP POLICY, rather than with any table name  
at all.  
  
Masahiko Sawada  

commit   : b994acf705bea9840880b1860dca9ceb0f4785ee    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Dec 2015 11:13:24 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 10 Dec 2015 11:13:24 -0500    

Etsuro Fujita  

commit   : 34263e8e4a679ee785e601566bf144bf1f50a2b6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 10 Dec 2015 16:26:45 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 10 Dec 2015 16:26:45 +0100    

ExecOnConflictUpdate() passed t_ctid of the to-be-updated tuple to  
ExecUpdate(). That's problematic primarily because of two reason: First  
and foremost t_ctid could point to a different tuple. Secondly, and  
that's what triggered the complaint by Stanislav, t_ctid is changed by  
heap_update() to point to the new tuple version.  The behavior of AFTER  
UPDATE triggers was therefore broken, with NEW.* and OLD.* tuples  
spuriously identical within AFTER UPDATE triggers.  
  
To fix both issues, pass a pointer to t_self of a on-stack HeapTuple  
instead.  
  
Fixing this bug lead to one change in regression tests, which previously  
failed due to the first issue mentioned above. There's a reasonable  
expectation that test fails, as it updates one row repeatedly within one  
INSERT ... ON CONFLICT statement. That is only possible if the second  
update is triggered via ON CONFLICT ... SET, ON CONFLICT ... WHERE, or  
by a WITH CHECK expression, as those are executed after  
ExecOnConflictUpdate() does a visibility check. That could easily be  
prohibited, but given it's allowed for plain UPDATEs and a rare corner  
case, it doesn't seem worthwhile.  
  
Reported-By: Stanislav Grozev  
Author: Andres Freund and Peter Geoghegan  
Discussion: CAA78GVqy1+LisN-8DygekD_Ldfy=BJLarSpjGhytOsgkpMavfQ@mail.gmail.com  
Backpatch: 9.5, where ON CONFLICT was introduced  

commit   : 5b51805fe4b9fec95274924c5733093a5f685a58    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 10 Dec 2015 16:25:12 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 10 Dec 2015 16:25:12 +0100    

At the end of crash recovery, unlogged relations are reset to the empty  
state, using their init fork as the template. The init fork is copied to  
the main fork without going through shared buffers. Unfortunately WAL  
replay so far has not necessarily flushed writes from shared buffers to  
disk at that point. In normal crash recovery, and before the  
introduction of 'fast promotions' in fd4ced523 / 9.3, the  
END_OF_RECOVERY checkpoint flushes the buffers out in time. But with  
fast promotions that's not the case anymore.  
  
To fix, force WAL writes targeting the init fork to be flushed  
immediately (using the new FlushOneBuffer() function). In 9.5+ that  
flush can centrally be triggered from the code dealing with restoring  
full page writes (XLogReadBufferForRedoExtended), in earlier releases  
that responsibility is in the hands of XLOG_HEAP_NEWPAGE's replay  
function.  
  
Backpatch to 9.1, even if this currently is only known to trigger in  
9.3+. Flushing earlier is more robust, and it is advantageous to keep  
the branches similar.  
  
Typical symptoms of this bug are errors like  
'ERROR:  index "..." contains unexpected zero page at block 0'  
shortly after promoting a node.  
  
Reported-By: Thom Brown  
Author: Andres Freund and Michael Paquier  
Discussion: 20150326175024.GJ451@alap3.anarazel.de  
Backpatch: 9.1-  

commit   : 2355faae010591febd2b39e74b209a5236f6682a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Dec 2015 10:19:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Dec 2015 10:19:13 -0500    

Commit 32f15d05c fixed this in configure, but missed the similar check  
in the MSVC scripts.  
  
Michael Paquier, per report from Victor Wagner  

commit   : c3c5c02881d47b3bf8d9e1e1e3460ef348863035    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Dec 2015 18:54:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Dec 2015 18:54:25 -0500    

While convincing myself that commit 7e19db0c09719d79 would solve both of  
the problems recently reported by Andreas Seltenreich, I realized that  
add_paths_to_joinrel's handling of LATERAL restrictions could be made  
noticeably simpler and faster if we were to retain the minimum possible  
parameterization for each joinrel (that is, the set of relids supplying  
unsatisfied lateral references in it).  We already retain that for  
baserels, in RelOptInfo.lateral_relids, so we can use that field for  
joinrels too.  
  
This is a back-port of commit edca44b1525b3d591263d032dc4fe500ea771e0e.  
I originally intended not to back-patch that, but additional hacking  
in this area turns out to be needed, making it necessary not optional  
to compute lateral_relids for joinrels.  In preparation for those fixes,  
sync the relevant code with HEAD as much as practical.  (I did not risk  
rearranging fields of RelOptInfo in released branches, however.)  

commit   : 4acee11e660aa5dd22d81a1d1d4476e158c16a59    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Dec 2015 14:11:58 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 9 Dec 2015 14:11:58 -0500    

Peter Geoghegan  

commit   : e90371d1a79f4398867f4f3bb8547e94259b07b5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Dec 2015 17:14:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Dec 2015 17:14:46 -0500    

Commit 344cdff2c made failure to open the target of --output fatal.  
For consistency, the --log-file switch should behave similarly.  
Like the previous commit, back-patch to 9.5 but no further.  
  
Daniel Verite  

commit   : 59f10ffa5bc1f39a5ce00806b394feb8f207bb33    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Dec 2015 16:58:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Dec 2015 16:58:05 -0500    

For unclear reasons, this function doesn't always read the expected data  
in some old Perl versions.  Rewriting it to avoid use of ARGV seems to  
dodge the problem, and this version is clearer anyway if you ask me.  
  
In passing, also improve error message in adjacent append_to_file function.  

commit   : 325b357bc255149c5ace7d77f5c15c941bafef0a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 8 Dec 2015 12:31:03 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 8 Dec 2015 12:31:03 -0500    

Commit e7cb7ee14555cc9c5773e2c102efd6371f6f2005 provided basic  
infrastructure for allowing a foreign data wrapper or custom scan  
provider to replace a join of one or more tables with a scan.  
However, this infrastructure failed to take into account the need  
for possible EvalPlanQual rechecks, and ExecScanFetch would fail  
an assertion (or just overwrite memory) if such a check was attempted  
for a plan containing a pushed-down join.  To fix, adjust the EPQ  
machinery to skip some processing steps when scanrelid == 0, making  
those the responsibility of scan's recheck method, which also has  
the responsibility in this case of correctly populating the relevant  
slot.  
  
To allow foreign scans to gain control in the right place to make  
use of this new facility, add a new, optional RecheckForeignScan  
method.  Also, allow a foreign scan to have a child plan, which can  
be used to correctly populate the slot (or perhaps for something  
else, but this is the only use currently envisioned).  
  
KaiGai Kohei, reviewed by Robert Haas, Etsuro Fujita, and Kyotaro  
Horiguchi.  

commit   : 25517ee14c1a018876b64dce73e8f7fb7e937783    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Dec 2015 17:41:45 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Dec 2015 17:41:45 -0500    

It was possible for the planner to decide to join a LATERAL subquery to  
the outer side of an outer join before the outer join itself is completed.  
Normally that's fine because of the associativity rules, but it doesn't  
work if the subquery contains a lateral reference to the inner side of the  
outer join.  In such a situation the outer join *must* be done first.  
join_is_legal() missed this consideration and would allow the join to be  
attempted, but the actual path-building code correctly decided that no  
valid join path could be made, sometimes leading to planner errors such as  
"failed to build any N-way joins".  
  
Per report from Andreas Seltenreich.  Back-patch to 9.3 where LATERAL  
support was added.  

commit   : 9d1839fad945cba7e23e645a3c212f34e56495f7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Dec 2015 12:42:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Dec 2015 12:42:32 -0500    

Commit d04c8ed9044ec added another support function to the GIST API,  
but overlooked mentioning it in xindex.sgml's summary of index support  
functions.  
  
Anastasia Lubennikova  

commit   : 20c444f5b5ef155147b8f3ef115f6bc5382fd2c6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Dec 2015 13:23:48 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Dec 2015 13:23:48 -0500    

This way, existing .gitignore entries and makefile clean actions will  
automatically apply to the tempdir, should it survive a TAP test run  
(which can happen if the user control-C's out of the run, for example).  
  
Michael Paquier, per a complaint from me  

commit   : 0d46bdde2b59e67446e10165e487935a54dfd225    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 5 Dec 2015 03:04:17 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 5 Dec 2015 03:04:17 -0500    

This should make Coverity deduce that plperl_call_perl_func() does not  
dereference NULL argtypes.  Back-patch to 9.5, where the affected code  
was introduced.  
  
Michael Paquier  

commit   : d3762fe6c208c4f5e66db24a10ddc549e9e08e0f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Dec 2015 14:44:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Dec 2015 14:44:13 -0500    

In commit 1ea0c73c2 I added a section to user-manag.sgml about how to drop  
roles that own objects; but as pointed out by Stephen Frost, I neglected  
that shared objects (databases or tablespaces) may need special treatment.  
Fix that.  Back-patch to supported versions, like the previous patch.  

commit   : 16e8e62d274a6026045bf809da38bc8ac33b9185    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 3 Dec 2015 19:22:31 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 3 Dec 2015 19:22:31 -0300    

As pointed out by Fujii Masao, we weren't quite there on a standby  
behaving sanely: first because we were failing to acquire the correct  
state in the case where no XLOG_PARAMETER_CHANGE message was sent  
(because a checkpoint had already happened after the setting was changed  
in the master, and then the standby was restarted); and second because  
promoting the standby with the feature enabled failed to activate it if  
the master had the feature disabled.  
  
This patch fixes both those misbehaviors hopefully without  
re-introducing any old problems.  
  
Also change the hint emitted in a standby together with the error  
message about the feature being disabled, to make it point out that the  
place to chance the setting is the master.  Otherwise, if the setting is  
already enabled in the standby, it is very confusing to have it say that  
the setting must be enabled ...  
  
Authors: Álvaro Herrera, Petr Jelínek.  
Backpatch to 9.5.  

commit   : 07338cb7425ee661ea2b80c1a3826bee1bc1a1de    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Dec 2015 14:29:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Dec 2015 14:29:07 -0500    

Formerly, if "psql -o foo" failed to open the output file "foo", it would  
print an error message but then carry on as though -o had not been  
specified at all.  This seems contrary to expectation: a program that  
cannot open its output file normally fails altogether.  Make psql do  
exit(1) after reporting the error.  
  
If "\o foo" failed to open "foo", it would print an error message but then  
reset the output file to stdout, as if the argument had been omitted.  
This is likewise pretty surprising behavior.  Make it keep the previous  
output state, instead.  
  
psql keeps SIGPIPE interrupts disabled when it is writing to a pipe, either  
a pipe specified by -o/\o or a transient pipe opened for purposes such as  
using a pager on query output.  The logic for this was too simple and could  
sometimes re-enable SIGPIPE when a -o pipe was still active, thus possibly  
leading to an unexpected psql crash later.  
  
Fixing the last point required getting rid of the kluge in PrintQueryTuples  
and ExecQueryUsingCursor whereby they'd transiently change the global  
queryFout state, but that seems like good cleanup anyway.  
  
Back-patch to 9.5 but not further; these are minor-enough issues that  
changing the behavior in stable branches doesn't seem appropriate.  

commit   : 28bfdc581a552e2a3b1f0faded352188559e5aca    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 3 Dec 2015 10:23:59 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 3 Dec 2015 10:23:59 -0500    

commit   : 0638a62dec88b148b560e5fb240087098fe58887    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 3 Dec 2015 10:20:54 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 3 Dec 2015 10:20:54 -0500    

commit   : 375a3b3397487e46c9c607f23db4851eb5bb9ece    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Dec 2015 18:20:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Dec 2015 18:20:34 -0500    

The formatting modes that depend on knowledge of the terminal window width  
did not work right when printing a query result that's been fetched in  
sections (as a result of FETCH_SIZE).  ExecQueryUsingCursor() would force  
use of the pager as soon as there's more than one result section, and then  
print.c would see an output file pointer that's not stdout and incorrectly  
conclude that the terminal window width isn't relevant.  
  
This has been broken all along for non-expanded "wrapped" output format,  
and as of 9.5 the issue affects expanded mode as well.  The problem also  
caused "\pset expanded auto" mode to invariably *not* switch to expanded  
output in a segmented result, which seems to me to be exactly backwards.  
  
To fix, we need to pass down an "is_pager" flag to inform the print.c  
subroutines that some calling level has already replaced stdout with a  
pager pipe, so they should (a) not do that again and (b) nonetheless honor  
the window size.  (Notably, this makes the first is_pager test in  
print_aligned_text() not be dead code anymore.)  
  
This patch is a bit invasive because there are so many existing calls of  
printQuery()/printTable(), but fortunately all but a couple can just pass  
"false" for the added parameter.  
  
Back-patch to 9.5 but no further.  Given the lack of field complaints,  
it's not clear that we should change the behavior in stable branches.  
Also, the API change for printQuery()/printTable() might possibly break  
third-party code, again something we don't like to do in stable branches.  
However, it's not quite too late to do this in 9.5, and with the larger  
scope of the problem there, it seems worth doing.  

commit   : e9986a811cbed36915ce7a7bb76bca8df69ab1d5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Dec 2015 16:24:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Dec 2015 16:24:34 -0500    

We tried to fetch statistics data from the index metapage, which does not  
work if the index isn't actually present.  If the index is hypothetical,  
instead extrapolate some plausible internal statistics based on the index  
page count provided by the index-advisor plugin.  
  
There was already some code in gincostestimate() to invent internal stats  
in this way, but since it was only meant as a stopgap for pre-9.1 GIN  
indexes that hadn't been vacuumed since upgrading, it was pretty crude.  
If we want it to support index advisors, we should try a little harder.  
A small amount of testing says that it's better to estimate the entry pages  
as 90% of the index, not 100%.  Also, estimating the number of entries  
(keys) as equal to the heap tuple count could be wildly wrong in either  
direction.  Instead, let's estimate 100 entries per entry page.  
  
Perhaps someday somebody will want the index advisor to be able to provide  
these numbers more directly, but for the moment this should serve.  
  
Problem report and initial patch by Julien Rouhaud; modified by me to  
invent less-bogus internal statistics.  Back-patch to all supported  
branches, since we've supported index advisors since 9.0.  

commit   : 181346cf9892820c94f51525d2c38684148812bf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Dec 2015 14:47:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Dec 2015 14:47:13 -0500    

Don't force the data width to extend all the way to the right margin if it  
doesn't need to.  This reverts the behavior in non-wrapping cases to be  
what it was in 9.4.  Also, make the logic that ensures the data line width  
is at least equal to the record-header line width a little less obscure.  
  
In passing, avoid possible calculation of log10(0).  Probably that's  
harmless, given the lack of field complaints, but it seems risky:  
conversion of NaN to an integer isn't well defined.  

commit   : c79bdc9904afefeee495455be7dea737d714fbb4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Dec 2015 11:42:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Dec 2015 11:42:25 -0500    

The previous coding could overrun the provided buffer size for a very large  
input, or lose precision for a very small input.  Adopt the methodology  
that's been in use in the equivalent backend code for a long time.  
  
Per private report from Bas van Schaik.  Back-patch to all supported  
branches.  

commit   : 6fe8ca0a2f8ac5ce2656addb0f6741b5315a8a23    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Dec 2015 11:07:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Dec 2015 11:07:29 -0500    

We should ignore output_columns unless it's greater than zero.  
A zero means we couldn't get any information from ioctl(TIOCGWINSZ);  
in that case the expected behavior is to print the data at native width,  
not to wrap it at the smallest possible value.  print_aligned_text()  
gets this consideration right, but print_aligned_vertical() lost track  
of this detail somewhere along the line.  

commit   : 4122ebcb1056655f23193e4632dccce68c524e43    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Nov 2015 17:53:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Nov 2015 17:53:32 -0500    

This area was rather heavily whacked around in 6513633b9 and follow-on  
commits, and it was showing it, because the logic to calculate the  
allowable data width in wrapped expanded mode had only the vaguest  
relationship to the logic that was actually printing the data.  It was  
not very close to being right about the conditions requiring overhead  
columns to be added.  Aside from being wrong, it was pretty unreadable  
and under-commented.  Rewrite it so it corresponds to what the printing  
code actually does.  
  
In passing, remove a couple of dead tests in the printing logic, too.  
  
Per a complaint from Jeff Janes, though this doesn't look much like his  
patch because it fixes a number of other corner-case bogosities too.  
One such fix that's visible in the regression test results is that  
although the code was attempting to enforce a minimum data width of  
3 columns, it sometimes left less space than that available.  

commit   : e69d3a82e46461da4c3878487fb99c1294fb1d8f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Nov 2015 18:18:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Nov 2015 18:18:42 -0500    

In commit 8abb3cda0ddc00a0ab98977a1633a95b97068d4e I attempted to cache  
the expression state trees constructed for domain CHECK constraints for  
the life of the backend (assuming the domain's constraints don't get  
redefined).  However, this turns out not to work very well, because  
execQual.c will run those state trees with ecxt_per_query_memory pointing  
to a query-lifespan context, and in some situations we'll end up with  
pointers into that context getting stored into the state trees.  This  
happens in particular with SQL-language functions, as reported by  
Emre Hasegeli, but there are many other cases.  
  
To fix, keep only the expression plan trees for domain CHECK constraints  
in the typcache's data structure, and revert to performing ExecInitExpr  
(at least) once per query to set up expression state trees in the query's  
context.  
  
Eventually it'd be nice to undo this, but that will require some careful  
thought about memory management for expression state trees, and it seems  
far too late for any such redesign in 9.5.  This way is still much more  
efficient than what happened before 8abb3cda0.  

commit   : daefb9810807709d13ce42cc0e7220d77b368be9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Nov 2015 13:23:02 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Nov 2015 13:23:02 -0500    

Failure to initially palloc the comboCids array, or to realloc it bigger  
when needed, left combocid's data structures in an inconsistent state that  
would cause trouble if the top transaction continues to execute.  Noted  
while examining a user complaint about the amount of memory used for this.  
(There's not much we can do about that, but it does point up that repalloc  
failure has a non-negligible chance of occurring here.)  
  
In HEAD/9.5, also avoid possible invocation of memcpy() with a null pointer  
in SerializeComboCIDState; cf commit 13bba0227.  

commit   : 55a2cc844216838d743cae7d94bd4f38acc62d1e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Nov 2015 17:31:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Nov 2015 17:31:53 -0500    

PQhost() can return NULL in non-error situations, namely when a Unix-socket  
connection has been selected by default.  That behavior is a tad debatable  
perhaps, but for the moment we should make sure that psql copes with it.  
Unfortunately, do_connect() failed to: it could pass a NULL pointer to  
strcmp(), resulting in crashes on most platforms.  This was reported as a  
security issue by ChenQin of Topsec Security Team, but the consensus of  
the security list is that it's just a garden-variety bug with no security  
implications.  
  
For paranoia's sake, I made the keep_password test not trust PQuser or  
PQport either, even though I believe those will never return NULL given  
a valid PGconn.  
  
Back-patch to all supported branches.  

commit   : b17dbf26293e3805b5f7ab5a11a8e3f984c476ad    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 24 Nov 2015 17:18:28 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 24 Nov 2015 17:18:28 -0500    

Also fix getErrorText() to return the right error string on failure.  
This behavior now matches that of other operating systems.  
  
Report by Noah Misch  
  
Backpatch through 9.1  

commit   : b542d940c308d35446e86c2bb273823303afb25c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 23 Nov 2015 21:36:57 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 23 Nov 2015 21:36:57 -0500    

commit   : f01fcd0e41721510ca76906c670ddb051e628bc1    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 23 Nov 2015 19:30:36 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 23 Nov 2015 19:30:36 +0300    

Per http://www.postgresql.org/message-id/flat/564C4CE6.9000509@postgrespro.ru  
Pavel Luzanov <p.luzanov@postgrespro.ru>  

commit   : f1824e55137fc7a30d5ac11aafdaba533fc1a6b5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 23 Nov 2015 09:13:44 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 23 Nov 2015 09:13:44 -0500    

from Michael Paquier  

commit   : 5f5e68b087e557fcddb7d28b096eead417623375    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Nov 2015 20:21:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Nov 2015 20:21:32 -0500    

The POSIX standard for tar headers requires archive member sizes to be  
printed in octal with at most 11 digits, limiting the representable file  
size to 8GB.  However, GNU tar and apparently most other modern tars  
support a convention in which oversized values can be stored in base-256,  
allowing any practical file to be a tar member.  Adopt this convention  
to remove two limitations:  
* pg_dump with -Ft output format failed if the contents of any one table  
exceeded 8GB.  
* pg_basebackup failed if the data directory contained any file exceeding  
8GB.  (This would be a fatal problem for installations configured with a  
table segment size of 8GB or more, and it has also been seen to fail when  
large core dump files exist in the data directory.)  
  
File sizes under 8GB are still printed in octal, so that no compatibility  
issues are created except in cases that would have failed entirely before.  
  
In addition, this patch fixes several bugs in the same area:  
  
* In 9.3 and later, we'd defined tarCreateHeader's file-size argument as  
size_t, which meant that on 32-bit machines it would write a corrupt tar  
header for file sizes between 4GB and 8GB, even though no error was raised.  
This broke both "pg_dump -Ft" and pg_basebackup for such cases.  
  
* pg_restore from a tar archive would fail on tables of size between 4GB  
and 8GB, on machines where either "size_t" or "unsigned long" is 32 bits.  
This happened even with an archive file not affected by the previous bug.  
  
* pg_basebackup would fail if there were files of size between 4GB and 8GB,  
even on 64-bit machines.  
  
* In 9.3 and later, "pg_basebackup -Ft" failed entirely, for any file size,  
on 64-bit big-endian machines.  
  
In view of these potential data-loss bugs, back-patch to all supported  
branches, even though removal of the documented 8GB limit might otherwise  
be considered a new feature rather than a bug fix.  

commit   : a35c5b7c1ffcde123b7b9b717608ed8357af870f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Nov 2015 14:55:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Nov 2015 14:55:28 -0500    

The previous way of reconstructing check constraints was to do a separate  
"ALTER TABLE ONLY tab ADD CONSTRAINT" for each table in an inheritance  
hierarchy.  However, that way has no hope of reconstructing the check  
constraints' own inheritance properties correctly, as pointed out in  
bug #13779 from Jan Dirk Zijlstra.  What we should do instead is to do  
a regular "ALTER TABLE", allowing recursion, at the topmost table that  
has a particular constraint, and then suppress the work queue entries  
for inherited instances of the constraint.  
  
Annoyingly, we'd tried to fix this behavior before, in commit 5ed6546cf,  
but we failed to notice that it wasn't reconstructing the pg_constraint  
field values correctly.  
  
As long as I'm touching pg_get_constraintdef_worker anyway, tweak it to  
always schema-qualify the target table name; this seems like useful backup  
to the protections installed by commit 5f173040.  
  
In HEAD/9.5, get rid of get_constraint_relation_oids, which is now unused.  
(I could alternatively have modified it to also return conislocal, but that  
seemed like a pretty single-purpose API, so let's not pretend it has some  
other use.)  It's unused in the back branches as well, but I left it in  
place just in case some third-party code has decided to use it.  
  
In HEAD/9.5, also rename pg_get_constraintdef_string to  
pg_get_constraintdef_command, as the previous name did nothing to explain  
what that entry point did differently from others (and its comment was  
equally useless).  Again, that change doesn't seem like material for  
back-patching.  
  
I did a bit of re-pgindenting in tablecmds.c in HEAD/9.5, as well.  
  
Otherwise, back-patch to all supported branches.  

commit   : 8ee1a776a0c69cbd33b88f1210d1b94dfda18128    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Nov 2015 14:54:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Nov 2015 14:54:05 -0500    

Some versions of Perl export a macro named HS_KEY.  This creates a  
conflict in contrib/hstore_plperl against hstore's macro of the same  
name.  The most future-proof solution seems to be to rename our macro;  
I chose HSTORE_KEY.  For consistency, rename HS_VAL and related macros  
similarly.  
  
Back-patch to 9.5.  contrib/hstore_plperl doesn't exist before that  
so there is no need to worry about the conflict in older releases.  
  
Per reports from Marco Atzeri and Mike Blackwell.  

commit   : 04f5622b63d6c368c10ea76b0187858e1468c693    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 19 Nov 2015 14:19:04 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 19 Nov 2015 14:19:04 -0500    

commit   : bb8b17960386e7026c4b5a63419752f310fa386a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Nov 2015 14:16:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Nov 2015 14:16:39 -0500    

Silly mistake in my commit 09cecdf285ea9f51, reported by Erik Rijkers.  
  
The fact that the buildfarm didn't find this implies that we are not  
testing Perl builds that lack MULTIPLICITY, which is a bit disturbing  
from a coverage standpoint.  Until today I'd have said nobody cared  
about such configurations anymore; but maybe not.  

commit   : 3f222b676d5c2fe2a7d869c80b8f840e2ae47b41    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 19 Nov 2015 02:42:02 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 19 Nov 2015 02:42:02 -0500    

commit   : bfac7a69ba5d2dd9b77b9de5daa7de9920426377    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 18 Nov 2015 23:32:16 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 18 Nov 2015 23:32:16 -0500    

commit   : fed03032e57a3959524aaf22dd358a5cb4ad49e1    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 18 Nov 2015 22:47:41 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 18 Nov 2015 22:47:41 -0500    

The target is now named 'bincheck' rather than 'tapcheck' so that it  
reflects what is checked instead of the test mechanism. Some of the  
logic is improved, making it easier to add further sets of TAP based  
tests in future. Also, the environment setting logic is imrpoved.  
  
As discussed on -hackers a couple of months ago.  

commit   : 5021e3dac9878134ded01806807a9e17f9324425    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 18 Nov 2015 21:17:50 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 18 Nov 2015 21:17:50 -0500    

KaiGai Kohei  

commit   : af85779bf72e91ea43be3de8218e45d166dfe200    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 10 Nov 2015 00:02:49 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 10 Nov 2015 00:02:49 +0100    

Author: Peter Geoghegan and Andres Freund  
Discussion: CAM3SWZScpWzQ-7EJC77vwqzZ1GO8GNmURQ1QqDQ3wRn7AbW1Cg@mail.gmail.com  
Backpatch: 9.5, where ON CONFLICT was introduced  

commit   : 6f8519d130e198c9e924caf678c47903ab0de8b6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 19 Nov 2015 01:25:58 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 19 Nov 2015 01:25:58 +0100    

At least one of the names was, due to a function renaming late in the  
development of ON CONFLICT, wrong. Since including function names in  
error messages is against the message style guide anyway, remove them  
from the messages.  
  
Discussion: CAM3SWZT8paz=usgMVHm0XOETkQvzjRtAUthATnmaHQQY0obnGw@mail.gmail.com  
Backpatch: 9.5, where ON CONFLICT was introduced  

commit   : 659d472920e4cbc5f4c42912768e8301af036991    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Nov 2015 17:45:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Nov 2015 17:45:05 -0500    

Per buildfarm member anchovy, 2.6.0 exists in the wild now.  
Hopefully it works with Postgres; if not, we'll have to do something  
about that, but in any case claiming it's "too old" is pretty silly.  

commit   : 80be41979e3ac2b17a4f985ee9249c78e3bafeb6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Nov 2015 15:46:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Nov 2015 15:46:47 -0500    

div_var_fast() postpones propagating carries in the same way as mul_var(),  
so it has the same corner-case overflow risk we fixed in 246693e5ae8a36f0,  
namely that the size of the carries has to be accounted for when setting  
the threshold for executing a carry propagation step.  We've not devised  
a test case illustrating the brokenness, but the required fix seems clear  
enough.  Like the previous fix, back-patch to all active branches.  
  
Dean Rasheed  

commit   : 331828b754378733cb5c2e49227603e7354e4e39    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Nov 2015 14:10:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Nov 2015 14:10:24 -0500    

This back-ports commit 13d856e177e69083 and assorted followon patches  
into 9.4 and 9.5.  9.5 and HEAD are now substantially identical in all  
the files touched by this commit, except that 010_pg_basebackup.pl has  
a few more tests related to the new --slot option.  9.4 has many fewer  
TAP tests, but the test infrastructure files are substantially the same,  
with the exception that 9.4 lacks the single-tmp-install infrastructure  
introduced in 9.5 (commit dcae5faccab64776).  
  
The primary motivation for this patch is to ensure that TAP test case  
fixes can be back-patched without hazards of the kind seen in commits  
34557f544/06dd4b44f.  In principle it should also make the world safe  
for running the TAP tests in the buildfarm in these branches; although  
we might want to think about back-porting dcae5faccab64776 to 9.4 if  
we're going to do that for real, because the TAP tests are quite disk  
space hungry without it.  
  
Michael Paquier did the back-porting work; original patches were by  
him and assorted other people.  

commit   : a408bd58a6746f919d96c840331707172cc2bf02    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 17 Nov 2015 06:53:07 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 17 Nov 2015 06:53:07 -0500    

from Euler Taveira  

commit   : b6a6340b170c31d4fd07d9ddae1cfac4e2200884    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 16 Nov 2015 22:26:32 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 16 Nov 2015 22:26:32 -0500    

commit   : 689cabf402c33a69e595a0d25f61b1fb49fb1c78    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 16 Nov 2015 21:16:42 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 16 Nov 2015 21:16:42 -0500    

commit   : 75c8af902e07a2090df429f410df1e753e3358f1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 16 Nov 2015 18:59:55 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 16 Nov 2015 18:59:55 -0500    

commit   : 34d4f49bb9792c1dd3f73fcbab15df54c2402fe1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Nov 2015 13:45:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Nov 2015 13:45:17 -0500    

Since commit 11e131854f8231a21613f834c40fe9d046926387, ruleutils.c has  
attempted to ensure that each RTE in a query or plan tree has a unique  
alias name.  However, the code that was added for this could be quite slow,  
even as bad as O(N^3) if N identical RTE names must be replaced, as noted  
by Jeff Janes.  Improve matters by building a transient hash table within  
set_rtable_names.  The hash table in itself reduces the cost of detecting a  
duplicate from O(N) to O(1), and we can save another factor of N by storing  
the number of de-duplicated names already created for each entry, so that  
we don't have to re-try names already created.  This way is probably a bit  
slower overall for small range tables, but almost by definition, such cases  
should not be a performance problem.  
  
In principle the same problem applies to the column-name-de-duplication  
code; but in practice that seems to be less of a problem, first because  
N is limited since we don't support extremely wide tables, and second  
because duplicate column names within an RTE are fairly rare, so that in  
practice the cost is more like O(N^2) not O(N^3).  It would be very much  
messier to fix the column-name code, so for now I've left that alone.  
  
An independent problem in the same area was that the de-duplication code  
paid no attention to the identifier length limit, and would happily produce  
identifiers that were longer than NAMEDATALEN and wouldn't be unique after  
truncation to NAMEDATALEN.  This could result in dump/reload failures, or  
perhaps even views that silently behaved differently than before.  We can  
fix that by shortening the base name as needed.  Fix it for both the  
relation and column name cases.  
  
In passing, check for interrupts in set_rtable_names, just in case it's  
still slow enough to be an issue.  
  
Back-patch to 9.3 where this code was introduced.  

commit   : 0489a048d3914e4d5f89c91ac604350b9392e6fa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Nov 2015 14:41:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Nov 2015 14:41:09 -0500    

Normally ruleutils prints a whole-row Var as "foo.*".  We already knew that  
that doesn't work at top level of a SELECT list, because the parser would  
treat the "*" as a directive to expand the reference into separate columns,  
not a whole-row Var.  However, Joshua Yanovski points out in bug #13776  
that the same thing happens at top level of a ROW() construct; and some  
nosing around in the parser shows that the same is true in VALUES().  
Hence, apply the same workaround already devised for the SELECT-list case,  
namely to add a forced cast to the appropriate rowtype in these cases.  
(The alternative of just printing "foo" was rejected because it is  
difficult to avoid ambiguity against plain columns named "foo".)  
  
Back-patch to all supported branches.  

commit   : fae58d5bede8b5bf3dd17381e7f6b73c1772577f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 14 Nov 2015 11:47:11 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 14 Nov 2015 11:47:11 -0500    

Previously, file copy failures were ignored on Windows due to an  
incorrect return value check.  
  
Report by Manu Joye  
  
Backpatch through 9.1  

commit   : d324c7226104266bf9fd57380a0703e40ba24fd4    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 13 Nov 2015 11:06:42 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 13 Nov 2015 11:06:42 -0500    

The sepgsql docs included a comment that PG doesn't support RLS.  That  
is only true for versions prior to 9.5.  
  
Update the docs for 9.5 and master to say that PG supports RLS but that  
sepgsql does not yet.  
  
Pointed out by Heikki.  
  
Back-patch to 9.5  

commit   : 5094da99b901df42580b6e7494d036ee4be9eb81    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 Nov 2015 18:05:23 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 Nov 2015 18:05:23 -0300    

Having the script prompt for passwords over and over was a preexisting  
problem when it processed multiple databases or when it processed  
multiple analyze stages, but the parallel mode introduced in commit  
a179232047 made it worse.  
  
Fix the annoyance by keeping a copy of the password used by the first  
connection that requires one.  Since users can (currently) only have a  
single password, there's no need for more complex arrangements (such as  
remembering one password per database).  
  
Per bug #13741 reported by Eric Brown.  Patch authored and  
cross-reviewed by Haribabu Kommi and Michael Paquier, slightly tweaked  
by Álvaro Herrera.  
  
Discussion: http://www.postgresql.org/message-id/20151027193919.931.54948@wrigleys.postgresql.org  
Backpatch to 9.5, where parallel vacuumdb was introduced.  

commit   : 747854f010b168c4f076cf44b61b100b0fe20866    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Nov 2015 13:03:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Nov 2015 13:03:52 -0500    

In commit 210eb9b743c0645d I centralized libpq's logic for closing down  
the backend communication socket, and made the new pqDropConnection  
routine always reset the I/O buffers to empty.  Many of the call sites  
previously had not had such code, and while that amounted to an oversight  
in some cases, there was one place where it was intentional and necessary  
*not* to flush the input buffer: pqReadData should never cause that to  
happen, since we probably still want to process whatever data we read.  
  
This is the true cause of the problem Robert was attempting to fix in  
c3e7c24a1d60dc6a, namely that libpq no longer reported the backend's final  
ERROR message before reporting "server closed the connection unexpectedly".  
But that only accidentally fixed it, by invoking parseInput before the  
input buffer got flushed; and very likely there are timing scenarios  
where we'd still lose the message before processing it.  
  
To fix, pass a flag to pqDropConnection to tell it whether to flush the  
input buffer or not.  On review I think flushing is actually correct for  
every other call site.  
  
Back-patch to 9.3 where the problem was introduced.  In HEAD, also improve  
the comments added by c3e7c24a1d60dc6a.  

commit   : a8c209fce10b5b3208451987782fd38e0a840624    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Nov 2015 19:19:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Nov 2015 19:19:14 -0500    

Also fill in the previously empty "major enhancements" list.  YMMV as to  
which items should make the cut, but it's past time we had something more  
than a placeholder here.  
  
(I meant to get this done before beta2 was wrapped, but got distracted by  
PDF build problems.  Better late than never.)  

commit   : bcb8f96e6775c649564ac0fb946ab6a1629ff969    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Nov 2015 17:13:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Nov 2015 17:13:38 -0500    

These were discussed in three different sections of the manual, which  
unsurprisingly had diverged over time; and the descriptions of individual  
variables lacked stylistic consistency even within each section (and  
frequently weren't in very good English anyway).  Clean up the mess, and  
remove some of the redundant information in hopes that future additions  
will be less likely to re-introduce inconsistency.  For instance I see  
no need for maintenance.sgml to include its very own list of all the  
autovacuum storage parameters, especially since that list was already  
incomplete.  

commit   : 0819778c43e3bc19364c541c3ea099b5c3b7d224    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Nov 2015 22:11:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Nov 2015 22:11:39 -0500    

Commit 8457d0beca731bf0 introduced an example which, while not incorrect,  
failed to exhibit the behavior it meant to describe, as a result of omitting  
an E'' prefix that needed to be there.  Noticed and fixed by Peter Geoghegan.  
  
I (tgl) failed to resist the temptation to wordsmith nearby text a bit  
while at it.  

commit   : 8d20eaa62b943bd155013aa01e0d6909bf520be0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Nov 2015 15:59:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Nov 2015 15:59:59 -0500    

In commit a5ec86a7c787832d28d5e50400ec96a5190f2555 I wrote a quick hack  
that reduced the number of TeX string pool entries created while converting  
our documentation to PDF form.  That held the fort for awhile, but as of  
HEAD we're back up against the same limitation.  It turns out that the  
original coding of \FlowObjectSetup actually results in *three* string pool  
entries being generated for every "flow object" (that is, potential  
cross-reference target) in the documentation, and my previous hack only got  
rid of one of them.  With a little more care, we can reduce the string  
count to one per flow object plus one per actually-cross-referenced flow  
object (about 115000 + 5000 as of current HEAD); that should work until  
the documentation volume roughly doubles from where it is today.  
  
As a not-incidental side benefit, this change also causes pdfjadetex to  
stop emitting unreferenced hyperlink anchors (bookmarks) into the PDF file.  
It had been making one willy-nilly for every flow object; now it's just one  
per actually-cross-referenced object.  This results in close to a 2X  
savings in PDF file size.  We will still want to run the output through  
"jpdftweak" to get it to be compressed; but we no longer need removal of  
unreferenced bookmarks, so we might be able to find a quicker tool for  
that step.  
  
Although the failure only affects HEAD and US-format output at the moment,  
9.5 cannot be more than a few pages short of failing likewise, so it  
will inevitably fail after a few rounds of minor-version release notes.  
I don't have a lot of faith that we'll never hit the limit in the older  
branches; and anyway it would be nice to get rid of jpdftweak across the  
board.  Therefore, back-patch to all supported branches.  

commit   : eb66ee639e79b9ec85d877746aaca315ca82c2a4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 9 Nov 2015 14:53:52 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 9 Nov 2015 14:53:52 -0500    

commit   : 289da0a7a59f60efa1baeadaca750ef2bdb97c78    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 9 Nov 2015 10:21:11 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 9 Nov 2015 10:21:11 -0500    

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

commit   : 90e074baec2f052120271437a72d2ef6d1de1696    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2015 05:08:56 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 9 Nov 2015 05:08:56 +0100    

Author: Peter Geoghegan and Andres Freund  
Discussion: CAM3SWZScpWzQ-7EJC77vwqzZ1GO8GNmURQ1QqDQ3wRn7AbW1Cg@mail.gmail.com,  
    CAHGQGwFUCWwSU7dtc2aRdRk73ztyr_jY5cPOyts+K8xKJ92X4Q@mail.gmail.com  
Backpatch: 9.5, where UPSERT was introduced  

commit   : 04c0b63365c7d4ee584300737afe6ef7df3b1253    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 8 Nov 2015 23:01:53 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 8 Nov 2015 23:01:53 +0100    

By accident the replication origin was not set properly in  
DecodeCommit(). That's bad because the origin is passed to the output  
plugins origin filter, and accessible from the output plugin via  
ReorderBufferTXN->origin_id.  Accessing the origin of individual changes  
worked before the fix, which is why this wasn't notices earlier.  
  
Reported-By: Craig Ringer  
Author: Craig Ringer  
Discussion: CAMsr+YFhBJLp=qfSz3-J+0P1zLkE8zNXM2otycn20QRMx380gw@mail.gmail.com  
Backpatch: 9.5, where replication origins where introduced  

commit   : 40c28678aa65308f27347cd218a09fdc92c483ef    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 8 Nov 2015 17:40:19 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 8 Nov 2015 17:40:19 -0500    

commit   : bdb42bac3c96a5affe5e476a56b85562b2ed0da9    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 8 Nov 2015 17:28:53 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 8 Nov 2015 17:28:53 -0500    

At least OpenBSD, NetBSD, and Windows don't support it.  This repairs  
pg_ctl for listen_addresses='0.0.0.0' and listen_addresses='::'.  Since  
pg_ctl prefers to test a Unix-domain socket, Windows users are most  
likely to need this change.  Back-patch to 9.1 (all supported versions).  
This could change pg_ctl interaction with loopback-interface firewall  
rules.  Therefore, in 9.4 and earlier (released branches), activate the  
change only on known-affected platforms.  
  
Reported (bug #13611) and designed by Kondo Yuta.  

commit   : 5daafafe74e23f9e6a8971820b4233565a837b77    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Nov 2015 17:09:04 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Nov 2015 17:09:04 -0500    

commit   : ab994cc00ec3e3700b2e62de9777d410fbb6ae84    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Nov 2015 16:13:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Nov 2015 16:13:49 -0500    

Per discussion, the original name was a bit misleading, and  
PQsslAttributeNames() seems more apropos.  It's not quite too late to  
change this in 9.5, so let's change it while we can.  
  
Also, make sure that the pointer array is const, not only the pointed-to  
strings.  
  
Minor documentation wordsmithing while at it.  
  
Lars Kanis, slight adjustments by me  

commit   : 44fc25153681f0d3814275926f3c626a3f283cc2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Nov 2015 12:43:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Nov 2015 12:43:24 -0500    

Lookahead and lookbehind constraints aren't allowed to contain backrefs,  
and parentheses within them are always considered non-capturing.  Or so  
says the manual.  But the regexp parser forgot about these rules once  
inside a parenthesized subexpression, so that constructs like (\w)(?=(\1))  
were accepted (but then not correctly executed --- a case like this acted  
like (\w)(?=\w), without any enforcement that the two \w's match the same  
text).  And in (?=((foo))) the innermost parentheses would be counted as  
capturing parentheses, though no text would ever be captured for them.  
  
To fix, properly pass down the "type" argument to the recursive invocation  
of parse().  
  
Back-patch to all supported branches; it was agreed that silent  
misexecution of such patterns is worse than throwing an error, even though  
new errors in minor releases are generally not desirable.  

commit   : 695012a0d585844130bf3d82ad0b4ebe0b7bf581    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 Nov 2015 11:18:33 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 6 Nov 2015 11:18:33 -0500    

With include_realm=1 being set down in parse_hba_auth_opt, if multiple  
options are passed on the pg_hba line, such as:  
  
host all     all    0.0.0.0/0    gss include_realm=0 krb_realm=XYZ.COM  
  
We would mistakenly reset include_realm back to 1.  Instead, we need to  
set include_realm=1 up in parse_hba_line, prior to parsing any of the  
additional options.  
  
Discovered by Jeff McCormick during testing.  
  
Bug introduced by 9a08841.  
  
Back-patch to 9.5  

commit   : 4d867458fce3743adc95ad6513c9d2dea87cd7f4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Nov 2015 18:15:48 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Nov 2015 18:15:48 -0500    

The jsonb_path_ops code calculated hash values inconsistently in some cases  
involving nested arrays and objects.  This would result in queries possibly  
not finding entries that they should find, when using a jsonb_path_ops GIN  
index for the search.  The problem cases involve JSONB values that contain  
both scalars and sub-objects at the same nesting level, for example an  
array containing both scalars and sub-arrays.  To fix, reset the current  
stack->hash after processing each value or sub-object, not before; and  
don't try to be cute about the outermost level's initial hash.  
  
Correcting this means that existing jsonb_path_ops indexes may now be  
inconsistent with the new hash calculation code.  The symptom is the same  
--- searches not finding entries they should find --- but the specific  
rows affected are likely to be different.  Users will need to REINDEX  
jsonb_path_ops indexes to make sure that all searches work as expected.  
  
Per bug #13756 from Daniel Cheng.  Back-patch to 9.4 where the faulty  
logic was introduced.  

commit   : c98605cc47fe42fac5f685d611db2a0c1afa2fcf    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 5 Nov 2015 12:05:38 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 5 Nov 2015 12:05:38 -0500    

Up until now, the total amount of data that could be passed to a  
background worker at startup was one datum, which can be a small as  
4 bytes on some systems.  That's enough to pass a dsm_handle or an  
array index, but not much else.  Add a bgw_extra flag to the  
BackgroundWorker struct, allowing up to 128 bytes to be passed to  
a new worker on any platform.  
  
Use this to fix a problem I recently discovered with the parallel  
context machinery added in 9.5: the master assigns each worker an  
array index, and each worker subsequently assigns itself an array  
index, and there's nothing to guarantee that the two sets of indexes  
match, leading to chaos.  
  
Normally, I would not back-patch the change to add bgw_extra, since it  
is basically a feature addition.  However, since 9.5 is still in beta  
and there seems to be no other sensible way to repair the broken  
parallel context machinery, back-patch to 9.5.  Existing background  
worker code can ignore the bgw_extra field without a problem, but  
might need to be recompiled since the structure size has changed.  
  
Report and patch by me.  Review by Amit Kapila.  

commit   : 1d97b25501470716f5b93b1083d865bb5508b880    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 3 Nov 2015 14:11:49 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 3 Nov 2015 14:11:49 -0500    

Peter Geoghegan  

commit   : fdae4a93e9df6b9b0f0ef5b0ccff697e4859710f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Nov 2015 11:57:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Nov 2015 11:57:56 -0500    

Standard-conforming literals have been the default for long enough that  
it no longer seems necessary to go out of our way to tell people to write  
regex escapes illegibly.  

commit   : f4057cdffc355f5d4a9d8411fb953069be6d72ea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Nov 2015 11:49:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Nov 2015 11:49:21 -0500    

Fix some brain fade in commit a2dabf0e1dda93c8: erroneous variable names  
in docs, rearrangements that made sentences less clear not more so,  
undocumented and poorly-chosen-anyway API behaviors of subroutines,  
bad grammar in error messages, copy-and-paste faults.  
  
Albe Laurenz and Tom Lane  

commit   : fd5ce6b89b63bdb9632a925a80f6f7d4e7bd2e00    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 3 Nov 2015 09:12:52 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 3 Nov 2015 09:12:52 -0500    

Commit a1480ec1d3bacb9acb08ec09f22bc25bc033115b purported to fix the  
problems with commit b2ccb5f4e6c81305386edb34daf7d1d1e1ee112a, but it  
didn't completely fix them.  The problem is that the checks were  
performed in the wrong order, leading to a race condition.  If the  
sender attached, sent a message, and detached after the receiver  
called shm_mq_get_sender and before the receiver called  
shm_mq_counterparty_gone, we'd incorrectly return SHM_MQ_DETACHED  
before all messages were read.  Repair by reversing the order of  
operations, and add a long comment explaining why this new logic is  
(hopefully) correct.  

commit   : 67d4738d934e9df455d2f67b2617423319b377d5    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Mon, 2 Nov 2015 06:26:28 -0600    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Mon, 2 Nov 2015 06:26:28 -0600    

Backpatch to 9.3, where it was initially omitted.  
  
Craig Ringer, with minor adjustment by Kevin Grittner  

commit   : 50ca917d911485aa696a30943fda98f41ff92206    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 31 Oct 2015 14:42:46 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 31 Oct 2015 14:42:46 -0500    

On insert the CheckForSerializableConflictIn() test was performed  
before the page(s) which were going to be modified had been locked  
(with an exclusive buffer content lock).  If another process  
acquired a relation SIReadLock on the heap and scanned to a page on  
which an insert was going to occur before the page was so locked,  
a rw-conflict would be missed, which could allow a serialization  
anomaly to be missed.  The window between the check and the page  
lock was small, so the bug was generally not noticed unless there  
was high concurrency with multiple processes inserting into the  
same table.  
  
This was reported by Peter Bailis as bug #11732, by Sean Chittenden  
as bug #13667, and by others.  
  
The race condition was eliminated in heap_insert() by moving the  
check down below the acquisition of the buffer lock, which had been  
the very next statement.  Because of the loop locking and unlocking  
multiple buffers in heap_multi_insert() a check was added after all  
inserts were completed.  The check before the start of the inserts  
was left because it might avoid a large amount of work to detect a  
serialization anomaly before performing the all of the inserts and  
the related WAL logging.  
  
While investigating this bug, other SSI bugs which were even harder  
to hit in practice were noticed and fixed, an unnecessary check  
(covered by another check, so redundant) was removed from  
heap_update(), and comments were improved.  
  
Back-patch to all supported branches.  
  
Kevin Grittner and Thomas Munro  

commit   : 21e634e4b23309ec33dfa27854c0b9901859dda3    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 30 Oct 2015 12:18:55 +0100    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 30 Oct 2015 12:18:55 +0100    

Mistake introduced by commit 5bd91e3a835b5d5499fee5f49fc7c0c776fe63dd.  
  
Hari Babu  

commit   : 7852f73bdfe6022c9b23abc950fec63d0d1f4582    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 30 Oct 2015 10:35:33 +0100    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 30 Oct 2015 10:35:33 +0100    

commit   : 9a1a22980d3650e6e232bc4423ec74bfc6d0e7be    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Oct 2015 18:54:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Oct 2015 18:54:35 -0400    

Show how this can be used in practice to make queries simpler and more  
flexible.  Also, draw an explicit contrast to the existence operator,  
which doesn't work that way.  
  
Peter Geoghegan and Tom Lane  

commit   : 0bc3071796b33288cd912db196b90c76fa394c21    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 28 Oct 2015 20:23:53 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 28 Oct 2015 20:23:53 -0400    

Message style, plurals, quoting, spelling, consistency with similar  
messages  

commit   : d17d5125f68da155e3a8e555c0699b7679b06e3b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 28 Oct 2015 12:19:14 +0100    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 28 Oct 2015 12:19:14 +0100    

Amit Langote, per Etsuro Fujita  

commit   : e53e2a196887a60481bd0bb1b316062027c5f24d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 28 Oct 2015 11:44:47 +0100    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 28 Oct 2015 11:44:47 +0100    

Mistake introduced by commit 3bf3ab8c563699138be02f9dc305b7b77a724307.  
  
Etsuro Fujita  

commit   : c56949168cc0aeac703865c3239f7bc7ca670402    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Oct 2015 23:02:04 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Oct 2015 23:02:04 -0300    

Per red wall in buildfarm  

commit   : 3e9e03353966efa5cae5f927a77ba64a93f1ee8c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Oct 2015 19:03:15 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Oct 2015 19:03:15 -0300    

Backpatch to 9.5 -- this should have been part of b0b7be61337, but we  
didn't have 38b03caebc5de either at the time.  
  
Author: Emre Hasegeli  
Revised by: Ian Barwick  
Discussion:  
 http://www.postgresql.org/message-id/CAE2gYzyB39Q9up_-TO6FKhH44pcAM1x6n_Cuj15qKoLoFihUVg@mail.gmail.com  
 http://www.postgresql.org/message-id/562DA711.3020305@2ndquadrant.com  

commit   : cf42abcc653817849398b62c321de654ea2b28cc    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Oct 2015 18:17:55 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Oct 2015 18:17:55 -0300    

A bug in the original free space computation made it possible to  
return a page which wasn't actually able to fit the item.  Since the  
insertion code isn't prepared to deal with PageAddItem failing, a PANIC  
resulted ("failed to add BRIN tuple [to new page]").  Add a macro to  
encapsulate the correct computation, and use it in  
brin_getinsertbuffer's callers before calling that routine, to raise an  
early error.  
  
I became aware of the possiblity of a problem in this area while working  
on ccc4c074994d734.  There's no archived discussion about it, but it's  
easy to reproduce a problem in the unpatched code with something like  
  
CREATE TABLE t (a text);  
CREATE INDEX ti ON t USING brin (a) WITH (pages_per_range=1);  
  
for length in `seq 8000 8196`  
do  
	psql -f - <<EOF  
TRUNCATE TABLE t;  
INSERT INTO t VALUES ('z'), (repeat('a', $length));  
EOF  
done  
  
Backpatch to 9.5, where BRIN was introduced.  

commit   : 68cc162e454a166a2a6ca992aeb759edcc56adc3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Oct 2015 15:06:50 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Oct 2015 15:06:50 -0300    

Further tweak commit_ts.c so that on a standby the state is completely  
consistent with what that in the master, rather than behaving  
differently in the cases that the settings differ.  Now in standby and  
master the module should always be active or inactive in lockstep.  
  
Author: Petr Jelínek, with some further tweaks by Álvaro Herrera.  
  
Backpatch to 9.5, where commit timestamps were introduced.  
  
Discussion: http://www.postgresql.org/message-id/5622BF9D.2010409@2ndquadrant.com  

commit   : 80ae841f2f0c51ea766a75f4abe73c0c48e4ab0c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Oct 2015 13:20:40 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 27 Oct 2015 13:20:40 -0300    

Bernd Helmle complained that CreateReplicationSlot() was assigning the  
same value to the same variable twice, so we could remove one of them.  
Code inspection reveals that we can actually remove both assignments:  
according to the author the assignment was there for beauty of the  
strlen line only, and another possible fix to that is to put the strlen  
in its own line, so do that.  
  
To be consistent within the file, refactor all duplicated strlen()  
calls, which is what we do elsewhere in the backend anyway.  In  
basebackup.c, snprintf already returns the right length; no need for  
strlen afterwards.  
  
Backpatch to 9.4, where replication slots were introduced, to keep code  
identical.  Some of this is older, but the patch doesn't apply cleanly  
and it's only of cosmetic value anyway.  
  
Discussion: http://www.postgresql.org/message-id/BE2FD71DEA35A2287EA5F018@eje.credativ.lan  

commit   : 44390e30f8531906ed142336f84f172b93073038    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Oct 2015 22:01:11 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Oct 2015 22:01:11 -0400    

If the counterparty writes some data into the queue and then detaches,  
it's wrong to return SHM_MQ_DETACHED right away.  If we do that, we  
fail to read whatever was written.  

commit   : 17b07afae341c05f2dae1b6c588df6b267e699f2    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Oct 2015 17:00:53 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Oct 2015 17:00:53 -0400    

This way, we produce a better error message if someone tries to do  
something like ALTER INDEX .. ALTER COLUMN .. SET STORAGE.  
  
Amit Langote  

commit   : ac9a01615c5d45eb08e5b78c3d0155214e0ab498    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Oct 2015 16:33:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 Oct 2015 16:33:30 -0400    

The shm_mq mechanism was intended to optionally notice when the process  
on the other end of the queue fails to attach to the queue.  It does  
this by allowing the user to pass a BackgroundWorkerHandle; if the  
background worker in question is launched and dies without attaching  
to the queue, then we know it never will.  This logic works OK in  
blocking mode, but when called with nowait = true we fail to notice  
that this has happened due to an asymmetry in the logic.  Repair.  
  
Reported off-list by Rushabh Lathia.  Patch by me.  

commit   : 85e30f57cb33294107fc17704a5d8874439e0ae5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 22 Oct 2015 13:59:58 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 22 Oct 2015 13:59:58 -0400    

with suggestion from Michael Paquier  

commit   : 5fb20a5ba6ce963ad529224ff5359aa1731c4068    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Oct 2015 11:06:24 -0700    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 Oct 2015 11:06:24 -0700    

Commit bda76c1c8cfb1d11751ba6be88f0242850481733 caused both plus and  
minus infinity to be rendered as "infinity", which is not only wrong  
but inconsistent with the pre-9.4 behavior of to_json().  Fix that by  
duplicating the coding in date_out/timestamp_out/timestamptz_out more  
closely.  Per bug #13687 from Stepan Perlov.  Back-patch to 9.4, like  
the previous commit.  
  
In passing, also re-pgindent json.c, since it had gotten a bit messed up by  
recent patches (and I was already annoyed by indentation-related problems  
in back-patching this fix ...)  

commit   : 2bfd2fe58db88abf86a920fe532b80cf2ea84a7f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Oct 2015 13:33:39 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 20 Oct 2015 13:33:39 -0400    

commit   : b3967f89370755176f4da03fb042e7e3e45999b5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 20 Oct 2015 11:11:35 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 20 Oct 2015 11:11:35 -0400    

Etsuro Fujita  

commit   : b06f1f286d5b9beb10cf7dc365cdb7150064e191    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 20 Oct 2015 09:56:04 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 20 Oct 2015 09:56:04 -0400    

Per a report from Shay Rojansky, Npgsql sends ssl_renegotiation_limit=0  
in the startup packet because it does not support renegotiation; other  
clients which have not attempted to support renegotiation might well  
behave similarly.  The recent removal of this parameter forces them to  
break compatibility with either current PostgreSQL versions, or  
previous ones.  Per discussion, the best solution is to accept the  
parameter but only allow a value of 0.  
  
Shay Rojansky, edited a little by me.  

commit   : ed6c516728c695477c5b6140ce80bc12641f72e2    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 20 Oct 2015 00:57:25 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 20 Oct 2015 00:57:25 -0400    

master emits an extra context message compared to 9.5 and earlier.  

commit   : 01a96c77d638aad0d9d5b040ed62248481d3b5a0    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 20 Oct 2015 00:37:22 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 20 Oct 2015 00:37:22 -0400    

Instead, use transaction abort.  Given an unlucky bout of latency, the  
timeout would cancel the RESET itself.  Buildfarm members gharial,  
lapwing, mereswine, shearwater, and sungazer witness that.  Back-patch  
to 9.1 (all supported versions).  The query_canceled test still could  
timeout before entering its subtransaction; for whatever reason, that  
has yet to happen on the buildfarm.  

commit   : 43e36f8dd065ee2d73d0b010488e624b7e509c3f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Oct 2015 13:54:53 -0700    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Oct 2015 13:54:53 -0700    

pg_regprefix was doing nothing with lookahead constraints, which would  
be fine if it were the right kind of nothing, but it isn't: we have to  
terminate our search for a fixed prefix, not just pretend the LACON arc  
isn't there.  Otherwise, if the current state has both a LACON outarc and a  
single plain-color outarc, we'd falsely conclude that the color represents  
an addition to the fixed prefix, and generate an extracted index condition  
that restricts the indexscan too much.  (See added regression test case.)  
  
Terminating the search is conservative: we could traverse the LACON arc  
(thus assuming that the constraint can be satisfied at runtime) and then  
examine the outarcs of the linked-to state.  But that would be a lot more  
work than it seems worth, because writing a LACON followed by a single  
plain character is a pretty silly thing to do.  
  
This makes a difference only in rather contrived cases, but it's a bug,  
so back-patch to all supported branches.  

commit   : 93726145434c593770e51c129737342fb3634b8a    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Fri, 16 Oct 2015 17:29:05 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Fri, 16 Oct 2015 17:29:05 +0200    

commit   : 6a7a2ee77731fa21ef10a6f1cb7c3df727632d5d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2015 15:52:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2015 15:52:12 -0400    

Revert our previous addition of "all" flags to copyins() and copyouts();  
they're no longer needed, and were never anything but an unsightly hack.  
  
Improve a couple of infelicities in the REG_DEBUG code for dumping  
the NFA data structure, including adding code to count the total  
number of states and arcs.  
  
Add a couple of missed error checks.  
  
Add some more documentation in the README file, and some regression tests  
illustrating cases that exceeded the state-count limit and/or took  
unreasonable amounts of time before this set of patches.  
  
Back-patch to all supported branches.  

commit   : e91cfdead776111b62c3a4f36974544f4136421b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2015 15:36:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2015 15:36:17 -0400    

This code previously counted the number of NFA states it created, and  
complained if a limit was exceeded, so as to prevent bizarre regex patterns  
from consuming unreasonable time or memory.  That's fine as far as it went,  
but the code paid no attention to how many arcs linked those states.  Since  
regexes can be contrived that have O(N) states but will need O(N^2) arcs  
after fixempties() processing, it was still possible to blow out memory,  
and take a long time doing it too.  To fix, modify the bookkeeping to count  
space used by both states and arcs.  
  
I did not bother with including the "color map" in the accounting; it  
can only grow to a few megabytes, which is not a lot in comparison to  
what we're allowing for states+arcs (about 150MB on 64-bit machines  
or half that on 32-bit machines).  
  
Looking at some of the larger real-world regexes captured in the Tcl  
regression test suite suggests that the most that is likely to be needed  
for regexes found in the wild is under 10MB, so I believe that the current  
limit has enough headroom to make it okay to keep it as a hard-wired limit.  
  
In connection with this, redefine REG_ETOOBIG as meaning "regular  
expression is too complex"; the previous wording of "nfa has too many  
states" was already somewhat inapropos because of the error code's use  
for stack depth overrun, and it was not very user-friendly either.  
  
Back-patch to all supported branches.  

commit   : 1bb0fbca39b447d1ce6da5f6bcf9f468a6346a08    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2015 15:11:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2015 15:11:49 -0400    

The previous coding would create a new intermediate state every time it  
wanted to interchange the ordering of two constraint arcs.  Certain regex  
features such as \Y can generate large numbers of parallel constraint arcs,  
and if we needed to reorder the results of that, we created unreasonable  
numbers of intermediate states.  To improve matters, keep a list of  
already-created intermediate states associated with the state currently  
being considered by the outer loop; we can re-use such states to place all  
the new arcs leading to the same destination or source.  
  
I also took the trouble to redefine push() and pull() to have a less risky  
API: they no longer delete any state or arc that the caller might possibly  
have a pointer to, except for the specifically-passed constraint arc.  
This reduces the risk of re-introducing the same type of error seen in  
the failed patch for CVE-2007-4772.  
  
Back-patch to all supported branches.  

commit   : e9cf3dc30a4ed82f2c284240841678db15491669    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2015 14:58:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Oct 2015 14:58:10 -0400