PostgreSQL 9.5.0 commit log

Stamp 9.5.0.

  
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    

Click here for diff

  
  

Docs: provide a concrete discussion and example for RLS race conditions.

  
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    

Click here for diff

  
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.  
  

Adjust behavior of row_security GUC to match the docs.

  
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    

Click here for diff

  
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.  
  

Fix typo in comment.

  
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    

Click here for diff

  
Masahiko Sawada  
  

Translation updates

  
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    

Click here for diff

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

Fix regrole and regnamespace output functions to do quoting, too.

  
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    

Click here for diff

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

Fix regrole and regnamespace types to honor quoting like other reg* types.

  
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    

Click here for diff

  
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  
  

Fix bogus lock release in RemovePolicyById and RemoveRoleFromObjectPolicy.

  
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    

Click here for diff

  
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.  
  

Do some copy-editing on the docs for row-level security.

  
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    

Click here for diff

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

Guard against null arguments in binary_upgrade_create_empty_extension().

  
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    

Click here for diff

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

Do some copy-editing on the docs for replication origins.

  
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    

Click here for diff

  
Minor grammar and markup improvements.  
  

Do a final round of copy-editing on the 9.5 release notes.

  
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    

Click here for diff

  
  

Fix treatment of *lpNumberOfBytesRecvd == 0: that’s a completion condition.

  
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    

Click here for diff

  
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.  
  

Teach pg_dump to quote reloption values safely.

  
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    

Click here for diff

  
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.  
  

Fix overly-strict assertions in spgtextproc.c.

  
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    

Click here for diff

  
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.  
  

Adjust back-branch release note description of commits a2a718b22 et al.

  
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    

Click here for diff

  
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    

Click here for diff

  
Backpatch certain files through 9.1  
  

Teach flatten_reloptions() to quote option values safely.

  
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    

Click here for diff

  
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  
  

Add some more defenses against silly estimates to gincostestimate().

  
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    

Click here for diff

  
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.  
  

Split out pg_operator.h function declarations to new file pg_operator_fn.h.

  
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    

Click here for diff

  
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.  
  

Add a comment noting that FDWs don’t have to implement EXCEPT or LIMIT TO.

  
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    

Click here for diff

  
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.  
  

Put back one copyObject() in rewriteTargetView().

  
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    

Click here for diff

  
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.  
  

Rename (new|old)estCommitTs to (new|old)estCommitTsXid

  
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    

Click here for diff

  
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.  
  

Document brin_summarize_new_pages

  
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    

Click here for diff

  
Pointer out by Jeff Janes  
  

Document the exponentiation operator as associating left to right.

  
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    

Click here for diff

  
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.  
  

doc: pg_committs -> pg_commit_ts

  
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    

Click here for diff

  
Reported by: Alain Laporte (#13836)  
  

Update documentation about pseudo-types.

  
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    

Click here for diff

  
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.  
  

Fix translation domain in pg_basebackup

  
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    

Click here for diff

  
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.  
  

Add forgotten CHECK_FOR_INTERRUPT calls in pgcrypto’s crypt()

  
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    

Click here for diff

  
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.  
  

Fix brin_summarize_new_values() to check index type and ownership.

  
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    

Click here for diff

  
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  
  

Remove unnecessary row ordering dependency in pg_rewind test suite.

  
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    

Click here for diff

  
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.  
  

Docs: fix erroneously-given function name.

  
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    

Click here for diff

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

Fix factual and grammatical errors in comments for struct _tableInfo.

  
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    

Click here for diff

  
Amit Langote, further adjusted by me  
  

Improve handling of password reuse in src/bin/scripts programs.

  
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    

Click here for diff

  
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  
  

In pg_dump, remember connection passwords no matter how we got them.

  
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    

Click here for diff

  
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  
  

Comment improvements for abbreviated keys.

  
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    

Click here for diff

  
Peter Geoghegan and Robert Haas  
  

Make viewquery a copy in rewriteTargetView()

  
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    

Click here for diff

  
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.  
  

Remove silly completion for “DELETE FROM tabname …”.

  
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    

Click here for diff

  
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.  
  

psql: Review of new help output strings

  
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    

Click here for diff

  
  

Add missing COSTS OFF to EXPLAIN commands in rowsecurity.sql.

  
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    

Click here for diff

  
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.  
  

Fix tab completion for ALTER … TABLESPACE … OWNED BY.

  
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    

Click here for diff

  
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  
  

pgbench: Change terminology from “threshold” to “parameter”.

  
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    

Click here for diff

  
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.  
  

Fix copy-and-paste error in logical decoding callback.

  
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    

Click here for diff

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

Remove unreferenced function declarations.

  
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    

Click here for diff

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

Fix improper initialization order for readline.

  
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    

Click here for diff

  
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.  
  

Rework internals of changing a type’s ownership

  
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    

Click here for diff

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

Cope with Readline’s failure to track SIGWINCH events outside of input.

  
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    

Click here for diff

  
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  
  

Stamp 9.5rc1.

  
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    

Click here for diff

  
  

Document use of Subject Alternative Names in SSL server certificates.

  
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    

Click here for diff

  
Commit acd08d764 did not bother with updating the documentation.  
  

Update 9.5 release notes through today.

  
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    

Click here for diff

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

Improve CREATE POLICY documentation

  
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    

Click here for diff

  
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.  
  

Collect the global OR of hasRowSecurity flags for plancache

  
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    

Click here for diff

  
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.  
  

Add missing cleanup logic in pg_rewind/t/005_same_timeline.pl test.

  
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    

Click here for diff

  
Per Michael Paquier  
  

pg_rewind: Don’t error if the two clusters are already on the same timeline

  
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    

Click here for diff

  
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  
  

Add missing CHECK_FOR_INTERRUPTS in lseg_inside_poly

  
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    

Click here for diff

  
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.  
  

Remove xmlparse(document “) test

  
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    

Click here for diff

  
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.  
  

Fix out-of-memory error handling in ParameterDescription message processing.

  
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    

Click here for diff

  
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.  
  

Fix bug in SetOffsetVacuumLimit() triggered by find_multixact_start() failure.

  
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    

Click here for diff

  
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  
  

Correct statement to actually be the intended assert statement.

  
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    

Click here for diff

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

Docs: document that psql’s “\i -” means read from stdin.

  
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    

Click here for diff

  
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.  
  

Consistently set all fields in pg_stat_replication to null instead of 0

  
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    

Click here for diff

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

Properly initialize write, flush and replay locations in walsender slots

  
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    

Click here for diff

  
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.  
  

Doc: update external URLs for PostGIS project.

  
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    

Click here for diff

  
Paul Ramsey  
  

Fix ALTER TABLE … SET TABLESPACE for unlogged relations.

  
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    

Click here for diff

  
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  
  

Add an expected-file to match behavior of latest libxml2.

  
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    

Click here for diff

  
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.  
  

For REASSIGN OWNED for foreign user mappings

  
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    

Click here for diff

  
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.  
  

Install our “missing” script where PGXS builds can find it.

  
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    

Click here for diff

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

Handle policies during DROP OWNED BY

  
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    

Click here for diff

  
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.  
  

Get rid of the planner’s LateralJoinInfo data structure.

  
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    

Click here for diff

  
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.  
  

Handle dependencies properly in ALTER POLICY

  
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    

Click here for diff

  
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.  
  

Still more fixes for planner’s handling of LATERAL references.

  
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    

Click here for diff

  
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.  
  

Fix commit timestamp initialization

  
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    

Click here for diff

  
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.  
  

Improve some messages

  
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    

Click here for diff

  
  

Improve ALTER POLICY tab completion.

  
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    

Click here for diff

  
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  
  

Fix typo.

  
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    

Click here for diff

  
Etsuro Fujita  
  

Fix ON CONFLICT UPDATE bug breaking AFTER UPDATE triggers.

  
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    

Click here for diff

  
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  
  

Fix bug leading to restoring unlogged relations from empty files.

  
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    

Click here for diff

  
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-  
  

Accept flex > 2.5.x on Windows, too.

  
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    

Click here for diff

  
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    

Click here for diff

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

Remove redundant sentence.

  
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    

Click here for diff

  
Peter Geoghegan  
  

Make failure to open psql’s –log-file fatal.

  
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    

Click here for diff

  
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  
  

Avoid odd portability problem in TestLib.pm’s slurp_file function.

  
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    

Click here for diff

  
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.  
  

Allow foreign and custom joins to handle EvalPlanQual rechecks.

  
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    

Click here for diff

  
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    

Click here for diff

  
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.  
  

Update xindex.sgml for recent additions to GIST opclass API.

  
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    

Click here for diff

  
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  
  

Create TestLib.pm’s tempdir underneath tmp_check/, not out in the open.

  
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    

Click here for diff

  
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  
  

Instruct Coverity using an assertion.

  
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    

Click here for diff

  
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  
  

Further improve documentation of the role-dropping process.

  
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    

Click here for diff

  
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.  
  

Further tweak commit_timestamp behavior

  
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    

Click here for diff

  
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.  
  

Clean up some psql issues around handling of the query output file.

  
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    

Click here for diff

  
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.  
  

psql: Improve spelling

  
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    

Click here for diff

  
  

doc: Fix markup and improve placeholder names

  
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    

Click here for diff

  
  

Fix behavior of printTable() and friends with externally-invoked pager.

  
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    

Click here for diff

  
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.  
  

Make gincostestimate() cope with hypothetical GIN indexes.

  
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    

Click here for diff

  
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.  
  

Further tweaking of print_aligned_vertical().

  
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    

Click here for diff

  
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.  
  

Use “g” not “f” format in ecpg’s PGTYPESnumeric_from_double().

  
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    

Click here for diff

  
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.  
  

Further adjustment to psql’s print_aligned_vertical() function.

  
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    

Click here for diff

  
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.  
  

Rework wrap-width calculation in psql’s print_aligned_vertical() function.

  
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    

Click here for diff

  
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.  
  

Avoid caching expression state trees for domain constraints across queries.

  
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    

Click here for diff

  
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.  
  

Fix failure to consider failure cases in GetComboCommandId().

  
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    

Click here for diff

  
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.  
  

Be more paranoid about null return values from libpq status functions.

  
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    

Click here for diff

  
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.  
  

pg_upgrade: fix CopyFile() on Windows to fail on file existence

  
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    

Click here for diff

  
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  
  

doc: Some improvements on CREATE POLICY and ALTER POLICY documentation

  
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    

Click here for diff

  
  

Clarify pg_rewind connection requirements.

  
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    

Click here for diff

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

doc: Add more documentation about wal_retrieve_retry_interval

  
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    

Click here for diff

  
from Michael Paquier  
  

Adopt the GNU convention for handling tar-archive members exceeding 8GB.

  
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    

Click here for diff

  
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.  
  

Fix handling of inherited check constraints in ALTER COLUMN TYPE (again).

  
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    

Click here for diff

  
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.  
  

Dodge a macro-name conflict with Perl.

  
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    

Click here for diff

  
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.  
  

doc: Clarify some things on pg_receivexlog reference page

  
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    

Click here for diff

  
  

Fix thinko: errmsg -> ereport.

  
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    

Click here for diff

  
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.  
  

fix a perl typo

  
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    

Click here for diff

  
  

Update docs for vcregress.pl bincheck changes

  
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    

Click here for diff

  
  

Improve vcregress.pl’s handling of tap tests for client programs

  
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    

Click here for diff

  
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.  
  

Fix incomplete set_foreignscan_references handling for fdw_recheck_quals

  
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    

Click here for diff

  
KaiGai Kohei  
  

Improve ON CONFLICT documentation.

  
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    

Click here for diff

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

Remove function names from some elog() calls in heapam.c.

  
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    

Click here for diff

  
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  
  

Accept flex > 2.5.x in configure.

  
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    

Click here for diff

  
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.  
  

Fix possible internal overflow in numeric division.

  
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    

Click here for diff

  
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  
  

Back-patch fixes to make TAP tests work on Windows.

  
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    

Click here for diff

  
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.  
  

Message style fix

  
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    

Click here for diff

  
from Euler Taveira  
  

Improve message

  
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    

Click here for diff

  
  

Message improvements

  
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    

Click here for diff

  
  

doc: Fix commas and improve spacing

  
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    

Click here for diff

  
  

Speed up ruleutils’ name de-duplication code, and fix overlength-name case.

  
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    

Click here for diff

  
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.  
  

Fix ruleutils.c’s dumping of whole-row Vars in ROW() and VALUES() contexts.

  
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    

Click here for diff

  
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.  
  

pg_upgrade: properly detect file copy failure on Windows

  
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    

Click here for diff

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

Correct sepgsql docs with regard to RLS

  
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    

Click here for diff

  
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  
  

vacuumdb: don’t prompt for passwords over and over

  
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    

Click here for diff

  
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.  
  

Fix unwanted flushing of libpq’s input buffer when socket EOF is seen.

  
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    

Click here for diff

  
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.  
  

Do a round of copy-editing on the 9.5 release notes.

  
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    

Click here for diff

  
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    

Click here for diff

  
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.  
  

Docs: fix misleading example.

  
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    

Click here for diff

  
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.  
  

Improve our workaround for ‘TeX capacity exceeded’ in building PDF files.

  
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    

Click here for diff

  
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.  
  

Stamp 9.5beta2.

  
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    

Click here for diff

  
  

Translation updates

  
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    

Click here for diff

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

Add paragraph about ON CONFLICT interaction with partitioning.

  
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    

Click here for diff

  
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  
  

Set replication origin when decoding commit records.

  
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    

Click here for diff

  
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  
  

Fix 9.5 version of previous commit to match its log message.

  
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    

Click here for diff

  
  

Don’t connect() to a wildcard address in test_postmaster_connection().

  
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    

Click here for diff

  
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.  
  

Update 9.5 release notes through today.

  
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    

Click here for diff

  
  

Rename PQsslAttributes() to PQsslAttributeNames(), and const-ify fully.

  
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    

Click here for diff

  
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  
  

Fix enforcement of restrictions inside regexp lookaround constraints.

  
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    

Click here for diff

  
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.  
  

Set include_realm=1 default in parse_hba_line

  
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    

Click here for diff

  
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  
  

Fix erroneous hash calculations in gin_extract_jsonb_path().

  
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    

Click here for diff

  
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.  
  

Pass extra data to bgworkers, and use this to fix parallel contexts.

  
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    

Click here for diff

  
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.  
  

Improve comments about abbreviation abort.

  
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    

Click here for diff

  
Peter Geoghegan  
  

Remove obsolete advice about doubling backslashes in regex escapes.

  
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    

Click here for diff

  
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.  
  

Code + docs review for unicode linestyle patch.

  
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    

Click here for diff

  
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  
  

shm_mq: Third attempt at fixing nowait behavior in shm_mq_receive.

  
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    

Click here for diff

  
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.  
  

Add RMV to list of commands taking AE lock.

  
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    

Click here for diff

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

Fix serialization anomalies due to race conditions on INSERT.

  
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    

Click here for diff

  
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  
  

doc: security_barrier option is a Boolean, not a string.

  
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    

Click here for diff

  
Mistake introduced by commit 5bd91e3a835b5d5499fee5f49fc7c0c776fe63dd.  
  
Hari Babu  
  

Fix typo in bgworker.c

  
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    

Click here for diff

  
  

Docs: add example clarifying use of nested JSON containment.

  
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    

Click here for diff

  
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  
  

Message style improvements

  
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    

Click here for diff

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

Add missing serial comma, for consistency.

  
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    

Click here for diff

  
Amit Langote, per Etsuro Fujita  
  

Fix incorrect message in ATWrongRelkindError.

  
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    

Click here for diff

  
Mistake introduced by commit 3bf3ab8c563699138be02f9dc305b7b77a724307.  
  
Etsuro Fujita  
  

Fix secondary expected output for commit_ts test

  
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    

Click here for diff

  
Per red wall in buildfarm  
  

Document BRIN’s inclusion opclass framework

  
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    

Click here for diff

  
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  
  

Fix BRIN free space computations

  
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    

Click here for diff

  
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.  
  

Cleanup commit timestamp module activaction, again

  
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    

Click here for diff

  
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  
  

Measure string lengths only once

  
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    

Click here for diff

  
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  
  

shm_mq: Repair breakage from previous commit.

  
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    

Click here for diff

  
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.  
  

Add two missing cases to ATWrongRelkindError.

  
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    

Click here for diff

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

shm_mq: Fix failure to notice a dead counterparty when nowait is used.

  
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    

Click here for diff

  
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.  
  

doc: Add advice on updating checkpoint_segments to max_wal_size

  
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    

Click here for diff

  
with suggestion from Michael Paquier  
  

Fix incorrect translation of minus-infinity datetimes for json/jsonb.

  
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    

Click here for diff

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

doc: Move documentation of max_wal_size to better position

  
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    

Click here for diff

  
  

Fix incorrect comment in plannodes.h

  
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    

Click here for diff

  
Etsuro Fujita  
  

Put back ssl_renegotiation_limit parameter, but only allow 0.

  
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    

Click here for diff

  
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.  
  

Fix back-patch of commit 8e3b4d9d40244c037bbc6e182ea3fabb9347d482.

  
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    

Click here for diff

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

Eschew “RESET statement_timeout” in tests.

  
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    

Click here for diff

  
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.  
  

Fix incorrect handling of lookahead constraints in pg_regprefix().

  
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    

Click here for diff

  
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.  
  

Fix order of arguments in ecpg generated typedef command.

  
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    

Click here for diff

  
  

Miscellaneous cleanup of regular-expression compiler.

  
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    

Click here for diff

  
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.  
  

Improve memory-usage accounting in regular-expression compiler.

  
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    

Click here for diff

  
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.  
  

Improve performance of pullback/pushfwd in regular-expression compiler.

  
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    

Click here for diff

  
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.  
  

Improve performance of fixempties() pass in regular-expression compiler.

  
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    

Click here for diff

  
The previous coding took something like O(N^4) time to fully process a  
chain of N EMPTY arcs.  We can't really do much better than O(N^2) because  
we have to insert about that many arcs, but we can do lots better than  
what's there now.  The win comes partly from using mergeins() to amortize  
de-duplication of arcs across multiple source states, and partly from  
exploiting knowledge of the ordering of arcs for each state to avoid  
looking at arcs we don't need to consider during the scan.  We do have  
to be a bit careful of the possible reordering of arcs introduced by  
the sort-merge coding of the previous commit, but that's not hard to  
deal with.  
  
Back-patch to all supported branches.  
  

Fix O(N^2) performance problems in regular-expression compiler.

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

Click here for diff

  
Change the singly-linked in-arc and out-arc lists to be doubly-linked,  
so that arc deletion is constant time rather than having worst-case time  
proportional to the number of other arcs on the connected states.  
  
Modify the bulk arc transfer operations copyins(), copyouts(), moveins(),  
moveouts() so that they use a sort-and-merge algorithm whenever there's  
more than a small number of arcs to be copied or moved.  The previous  
method is O(N^2) in the number of arcs involved, because it performs  
duplicate checking independently for each copied arc.  The new method may  
change the ordering of existing arcs for the destination state, but nothing  
really cares about that.  
  
Provide another bulk arc copying method mergeins(), which is unused as  
of this commit but is needed for the next one.  It basically is like  
copyins(), but the source arcs might not all come from the same state.  
  
Replace the O(N^2) bubble-sort algorithm used in carcsort() with a qsort()  
call.  
  
These changes greatly improve the performance of regex compilation for  
large or complex regexes, at the cost of extra space for arc storage during  
compilation.  The original tradeoff was probably fine when it was made, but  
now we care more about speed and less about memory consumption.  
  
Back-patch to all supported branches.  
  

Fix regular-expression compiler to handle loops of constraint arcs.

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

Click here for diff

  
It's possible to construct regular expressions that contain loops of  
constraint arcs (that is, ^ $ AHEAD BEHIND or LACON arcs).  There's no use  
in fully traversing such a loop at execution, since you'd just end up in  
the same NFA state without having consumed any input.  Worse, such a loop  
leads to infinite looping in the pullback/pushfwd stage of compilation,  
because we keep pushing or pulling the same constraints around the loop  
in a vain attempt to move them to the pre or post state.  Such looping was  
previously recognized in CVE-2007-4772; but the fix only handled the case  
of trivial single-state loops (that is, a constraint arc leading back to  
its source state) ... and not only that, it was incorrect even for that  
case, because it broke the admittedly-not-very-clearly-stated API contract  
of the pull() and push() subroutines.  The first two regression test cases  
added by this commit exhibit patterns that result in assertion failures  
because of that (though there seem to be no ill effects in non-assert  
builds).  The other new test cases exhibit multi-state constraint loops;  
in an unpatched build they will run until the NFA state-count limit is  
exceeded.  
  
To fix, remove the code added for CVE-2007-4772, and instead create a  
general-purpose constraint-loop-breaking phase of regex compilation that  
executes before we do pullback/pushfwd.  Since we never need to traverse  
a constraint loop fully, we can just break the loop at any chosen spot,  
if we add clone states that can replicate any sequence of arc transitions  
that would've traversed just part of the loop.  
  
Also add some commentary clarifying why we have to have all these  
machinations in the first place.  
  
This class of problems has been known for some time --- we had a report  
from Marc Mamin about two years ago, for example, and there are related  
complaints in the Tcl bug tracker.  I had discussed a fix of this kind  
off-list with Henry Spencer, but didn't get around to doing something  
about it until the issue was rediscovered by Greg Stark recently.  
  
Back-patch to all supported branches.  
  

Remove cautions about using volatile from spin.h.

  
commit   : 22884414cbac345c9143738634123f76e61ca343    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 16 Oct 2015 14:06:22 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 16 Oct 2015 14:06:22 -0400    

Click here for diff

  
Commit 0709b7ee72e4bc71ad07b7120acd117265ab51d0 obsoleted this comment  
but neglected to update it.  
  
Thomas Munro  
  

Fix a problem with parallel workers being unable to restore role.

  
commit   : 73d71cde5751e06d372431178e740835284eb132    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 16 Oct 2015 11:37:19 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 16 Oct 2015 11:37:19 -0400    

Click here for diff

  
check_role() tries to verify that the user has permission to become the  
requested role, but this is inappropriate in a parallel worker, which  
needs to exactly recreate the master's authorization settings.  So skip  
the check in that case.  
  
This fixes a bug in commit 924bcf4f16d54c55310b28f77686608684734f42.  
  

Invalidate caches after cranking up a parallel worker transaction.

  
commit   : 14129d1c9e2d3afa064651012a55c9c84aa6821a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 16 Oct 2015 11:31:23 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 16 Oct 2015 11:31:23 -0400    

Click here for diff

  
Starting a parallel worker transaction changes our notion of which XIDs  
are in-progress or committed, and our notion of the current command  
counter ID.  Therefore, our view of these caches prior to starting  
this transaction may no longer valid.  Defend against that by clearing  
them.  
  
This fixes a bug in commit 924bcf4f16d54c55310b28f77686608684734f42.  
  

Tighten up application of parallel mode checks.

  
commit   : d43e3adc7572d34988967475900dcd4f9e0a7b89    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 16 Oct 2015 09:59:57 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 16 Oct 2015 09:59:57 -0400    

Click here for diff

  
Commit 924bcf4f16d54c55310b28f77686608684734f42 failed to enforce  
parallel mode checks during the commit of a parallel worker, because  
we exited parallel mode prior to ending the transaction so that we  
could pop the active snapshot.  Re-establish parallel mode during  
parallel worker commit.  Without this, it's far too easy for unsafe  
actions during the pre-commit sequence to crash the server instead of  
hitting the error checks as intended.  
  
Just to be extra paranoid, adjust a couple of the sanity checks in  
xact.c to check not only IsInParallelMode() but also  
IsParallelWorker().  
  

Transfer current command counter ID to parallel workers.

  
commit   : c451eaf8f628440ad93e933da8f08f7f4545c376    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 16 Oct 2015 09:53:34 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 16 Oct 2015 09:53:34 -0400    

Click here for diff

  
Commit 924bcf4f16d54c55310b28f77686608684734f42 correctly forbade  
parallel workers to modify the command counter while in parallel mode,  
but it inexplicably neglected to actually transfer the current command  
counter from leader to workers.  This can result in the workers seeing  
a different set of tuples from the leader, which is bad.  Repair.  
  

Don’t send protocol messages to a shm_mq that no longer exists.

  
commit   : 26981d292758c6ee9185332e4abc990ff19c81a2    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 16 Oct 2015 09:42:33 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 16 Oct 2015 09:42:33 -0400    

Click here for diff

  
Commit 2bd9e412f92bc6a68f3e8bcb18e04955cc35001d introduced a mechanism  
for relaying protocol messages from a background worker to another  
backend via a shm_mq.  However, there was no provision for shutting  
down the communication channel.  Therefore, a protocol message sent  
late in the shutdown sequence, such as a DEBUG message resulting from  
cranking up log_min_messages, could crash the server.  To fix, install  
an on_dsm_detach callback that disables sending messages to the shm_mq  
when the associated DSM is detached.  
  

Fix NULL handling in datum_to_jsonb().

  
commit   : a93b3782e3358cbb1ad8d65386a2e1478b805649    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Oct 2015 13:46:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Oct 2015 13:46:09 -0400    

Click here for diff

  
The function failed to adhere to its specification that the "tcategory"  
argument should not be examined when the input value is NULL.  This  
resulted in a crash in some cases.  Per bug #13680 from Boyko Yordanov.  
  
In passing, re-pgindent some recent changes in jsonb.c, and fix a rather  
ungrammatical comment.  
  
Diagnosis and patch by Michael Paquier, cosmetic changes by me  
  

Allow FDWs to push down quals without breaking EvalPlanQual rechecks.

  
commit   : 5043193b78919a1bd144563aadc2f7f726549913    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 15 Oct 2015 13:00:40 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 15 Oct 2015 13:00:40 -0400    

Click here for diff

  
This fixes a long-standing bug which was discovered while investigating  
the interaction between the new join pushdown code and the EvalPlanQual  
machinery: if a ForeignScan appears on the inner side of a paramaterized  
nestloop, an EPQ recheck would re-return the original tuple even if  
it no longer satisfied the pushed-down quals due to changed parameter  
values.  
  
This fix adds a new member to ForeignScan and ForeignScanState and a  
new argument to make_foreignscan, and requires changes to FDWs which  
push down quals to populate that new argument with a list of quals they  
have chosen to push down.  Therefore, I'm only back-patching to 9.5,  
even though the bug is not new in 9.5.  
  
Etsuro Fujita, reviewed by me and by Kyotaro Horiguchi.  
  

Fix bogus comments

  
commit   : 54e07be2dfd314a64dc2ce03a6a7f59cac1c8a13    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 15 Oct 2015 12:20:15 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 15 Oct 2015 12:20:15 -0300    

Click here for diff

  
Author: Amit Langote  
  

– email subject limit —————————————– – gitweb summary limit ————————– pg_upgrade: reorder controldata checks to match program output

  
commit   : 41179e7ab328a12870fed942768a89dbe8742bf1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 13 Oct 2015 18:25:32 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 13 Oct 2015 18:25:32 -0400    

Click here for diff

  
Also improve comment for how float8_pass_by_value is used.  
  
Backpatch through 9.5  
  

Improve INSERT .. ON CONFLICT error message.

  
commit   : bf8a361e101d830a6db105982a8527325c2e85fc    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 13 Oct 2015 15:33:07 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 13 Oct 2015 15:33:07 -0400    

Click here for diff

  
Peter Geoghegan, reviewed by me.  
  

On Windows, ensure shared memory handle gets closed if not being used.

  
commit   : 39ac293940ec022f36510ba72470f23799e21dde    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Oct 2015 11:21:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Oct 2015 11:21:33 -0400    

Click here for diff

  
Postmaster child processes that aren't supposed to be attached to shared  
memory were not bothering to close the shared memory mapping handle they  
inherit from the postmaster process.  That's mostly harmless, since the  
handle vanishes anyway when the child process exits -- but the syslogger  
process, if used, doesn't get killed and restarted during recovery from a  
backend crash.  That meant that Windows doesn't see the shared memory  
mapping as becoming free, so it doesn't delete it and the postmaster is  
unable to create a new one, resulting in failure to recover from crashes  
whenever logging_collector is turned on.  
  
Per report from Dmitry Vasilyev.  It's a bit astonishing that we'd not  
figured this out long ago, since it's been broken from the very beginnings  
of out native Windows support; probably some previously-unexplained trouble  
reports trace to this.  
  
A secondary problem is that on Cygwin (perhaps only in older versions?),  
exec() may not detach from the shared memory segment after all, in which  
case these child processes did remain attached to shared memory, posing  
the risk of an unexpected shared memory clobber if they went off the rails  
somehow.  That may be a long-gone bug, but we can deal with it now if it's  
still live, by detaching within the infrastructure introduced here to deal  
with closing the handle.  
  
Back-patch to all supported branches.  
  
Tom Lane and Amit Kapila  
  

Sigh, need “use Config” as well.

  
commit   : c6ab511c224f8775c0d392f8811c0a0a34758b3a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Oct 2015 19:49:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Oct 2015 19:49:22 -0400    

Click here for diff

  
This time with some manual testing behind it ...  
  

Cause TestLib.pm to define $windows_os in all branches.

  
commit   : 34557f5448e04366e7b64a402c0dd33decb6c346    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Oct 2015 19:35:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Oct 2015 19:35:38 -0400    

Click here for diff

  
Back-port of a part of commit 690ed2b76ab91eb79ea04ee2bfbdc8a2693f2a37 that  
I'd depended on without realizing that it was only added recently.  Since  
it seems entirely likely that other such tests will need to be back-patched  
in future, providing the flag seems like a better answer than just putting  
a test in-line.  
  
Per buildfarm.  
  

Fix “pg_ctl start -w” to test child process status directly.

  
commit   : a151a5c38510793830a63d74201e2d3561829170    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Oct 2015 18:30:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Oct 2015 18:30:36 -0400    

Click here for diff

  
pg_ctl start with -w previously relied on a heuristic that the postmaster  
would surely always manage to create postmaster.pid within five seconds.  
Unfortunately, that fails much more often than we would like on some of the  
slower, more heavily loaded buildfarm members.  
  
We have known for quite some time that we could remove the need for that  
heuristic on Unix by using fork/exec instead of system() to launch the  
postmaster.  This allows us to know the exact PID of the postmaster, which  
allows near-certain verification that the postmaster.pid file is the one  
we want and not a leftover, and it also lets us use waitpid() to detect  
reliably whether the child postmaster has exited or not.  
  
What was blocking this change was not wanting to rewrite the Windows  
version of start_postmaster() to avoid use of CMD.EXE.  That's doable  
in theory but would require fooling about with stdout/stderr redirection,  
and getting the handling of quote-containing postmaster switches to  
stay the same might be rather ticklish.  However, we realized that  
we don't have to do that to fix the problem, because we can test  
whether the shell process has exited as a proxy for whether the  
postmaster is still alive.  That doesn't allow an exact check of the  
PID in postmaster.pid, but we're no worse off than before in that  
respect; and we do get to get rid of the heuristic about how long the  
postmaster might take to create postmaster.pid.  
  
On Unix, this change means that a second "pg_ctl start -w" immediately  
after another such command will now reliably fail, whereas previously  
it would succeed if done within two seconds of the earlier command.  
Since that's a saner behavior anyway, it's fine.  On Windows, the case can  
still succeed within the same time window, since pg_ctl can't tell that the  
earlier postmaster's postmaster.pid isn't the pidfile it is looking for.  
To ensure stable test results on Windows, we can insert a short sleep into  
the test script for pg_ctl, ensuring that the existing pidfile looks stale.  
This hack can be removed if we ever do rewrite start_postmaster(), but that  
no longer seems like a high-priority thing to do.  
  
Back-patch to all supported versions, both because the current behavior  
is buggy and because we must do that if we want the buildfarm failures  
to go away.  
  
Tom Lane and Michael Paquier  
  

Use JsonbIteratorToken consistently in automatic variable declarations.

  
commit   : f75c4fc1dc93d60246df324bf595912d557bcba6    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 11 Oct 2015 23:53:35 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 11 Oct 2015 23:53:35 -0400    

Click here for diff

  
Many functions stored JsonbIteratorToken values in variables of other  
integer types.  Also, standardize order relative to other declarations.  
Expect compilers to generate the same code before and after this change.  
  

Fix whitespace

  
commit   : 7109c606d00f972359052bb8c8879a1ecfc1850f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 11 Oct 2015 21:44:27 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 11 Oct 2015 21:44:27 -0400    

Click here for diff

  
  

Make prove_installcheck remove the old log directory, if any.

  
commit   : 2539b9b0831c5642fd21284ce50003f08a313037    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 11 Oct 2015 20:36:07 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 11 Oct 2015 20:36:07 -0400    

Click here for diff

  
prove_check already has been doing this.  Back-patch to 9.4, like the  
commit that introduced this logging.  
  

Handle append_rel_list in expand_security_qual

  
commit   : a26609e470601421b44424d6cc2683c4acabd086    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 9 Oct 2015 10:49:10 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 9 Oct 2015 10:49:10 -0400    

Click here for diff

  
During expand_security_quals, we take the security barrier quals on an  
RTE and create a subquery which evaluates the quals.  During this, we  
have to replace any variables in the outer query which refer to the  
original RTE with references to the columns from the subquery.  
  
We need to also perform that replacement for any Vars in the  
append_rel_list.  
  
Only backpatching to 9.5 as we only go through this process in 9.4 for  
auto-updatable security barrier views, which UNION ALL queries aren't.  
  
Discovered by Haribabu Kommi  
  
Patch by Dean Rasheed  
  

Fix uninitialized-variable bug.

  
commit   : e50431aa22e3b894ac107affd358052c20a899f7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Oct 2015 09:12:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Oct 2015 09:12:03 -0500    

Click here for diff

  
For some reason, neither of the compilers I usually use noticed the  
uninitialized-variable problem I introduced in commit 7e2a18a9161fee7e.  
That's hardly a good enough excuse though.  Committing with brown paper bag  
on head.  
  
In addition to putting the operations in the right order, move the  
declaration of "now" inside the loop; there's no need for it to be  
outside, and that does wake up older gcc enough to notice any similar  
future problem.  
  
Back-patch to 9.4; earlier versions lack the time-to-SIGKILL stanza  
so there's no bug.  
  

Fix typo in docs.

  
commit   : 36d4a50a886dacdb9e4a6716aca984edd3add83b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 8 Oct 2015 13:21:03 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 8 Oct 2015 13:21:03 -0400    

Click here for diff

  
Pallavi Sontakke  
  

Factor out encoding specific tests for json

  
commit   : 48a78d80c83f7cd341e9761b5404562db6031c7e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 7 Oct 2015 17:41:45 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 7 Oct 2015 17:41:45 -0400    

Click here for diff

  
This lets us remove the large alternative results files for the main  
json and jsonb tests, which makes modifying those tests simpler for  
committers and patch submitters.  
  
Backpatch to 9.4 for jsonb and 9.3 for json.  
  

Improve documentation of the role-dropping process.

  
commit   : fc95734a14e588a847793ce4a734d9bf7fe50d14    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Oct 2015 16:12:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Oct 2015 16:12:05 -0400    

Click here for diff

  
In general one may have to run both REASSIGN OWNED and DROP OWNED to get  
rid of all the dependencies of a role to be dropped.  This was alluded to  
in the REASSIGN OWNED man page, but not really spelled out in full; and in  
any case the procedure ought to be documented in a more prominent place  
than that.  Add a section to the "Database Roles" chapter explaining this,  
and do a bit of wordsmithing in the relevant commands' man pages.  
  

docs: add JSONB containment example of a key and empty object

  
commit   : c86555fc80bbbf276de42f43761991212b713575    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Oct 2015 10:30:54 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Oct 2015 10:30:54 -0400    

Click here for diff

  
Backpatch through 9.5  
  

docs: Map operator @> to the proper SGML escape for ‘>’

  
commit   : 9445a1cd3cc6dfae3644e2fe95da77046b507491    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Oct 2015 09:42:26 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Oct 2015 09:42:26 -0400    

Click here for diff

  
Backpatch through 9.5  
  

docs: clarify JSONB operator descriptions

  
commit   : 2169e878c4a542e41a7d66cbb40d9c6bfde23f57    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Oct 2015 09:06:49 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Oct 2015 09:06:49 -0400    

Click here for diff

  
No catalog bump as the catalog changes are for SQL operator comments.  
  
Backpatch through 9.5  
  

Perform an immediate shutdown if the postmaster.pid file is removed.

  
commit   : 02580df6c3ac288f2ed5e38ed42532512993d468    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Oct 2015 17:15:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Oct 2015 17:15:27 -0400    

Click here for diff

  
The postmaster now checks every minute or so (worst case, at most two  
minutes) that postmaster.pid is still there and still contains its own PID.  
If not, it performs an immediate shutdown, as though it had received  
SIGQUIT.  
  
The original goal behind this change was to ensure that failed buildfarm  
runs would get fully cleaned up, even if the test scripts had left a  
postmaster running, which is not an infrequent occurrence.  When the  
buildfarm script removes a test postmaster's $PGDATA directory, its next  
check on postmaster.pid will fail and cause it to exit.  Previously, manual  
intervention was often needed to get rid of such orphaned postmasters,  
since they'd block new test postmasters from obtaining the expected socket  
address.  
  
However, by checking postmaster.pid and not something else, we can provide  
additional robustness: manual removal of postmaster.pid is a frequent DBA  
mistake, and now we can at least limit the damage that will ensue if a new  
postmaster is started while the old one is still alive.  
  
Back-patch to all supported branches, since we won't get the desired  
improvement in buildfarm reliability otherwise.  
  

Stamp 9.5beta1.

  
commit   : b96df2c61710b39d24e98767cfe17b920b9319a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2015 15:09:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2015 15:09:44 -0400    

Click here for diff

  
  

docs: update guidelines on when to use GIN and GiST indexes

  
commit   : 7d88b3d154444fe102ef6a006f1234025e91c7fa    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Oct 2015 13:38:36 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Oct 2015 13:38:36 -0400    

Click here for diff

  
Report by Tomas Vondra  
  
Backpatch through 9.5  
  

Docs: explain contrib/pg_stat_statements’ handling of GC failure.

  
commit   : d62359144da19297b13b2abf6c7d5d9220cfdf28    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2015 12:44:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2015 12:44:12 -0400    

Click here for diff

  
Failure to perform garbage collection now has a user-visible effect, so  
explain that and explain that reducing pgss_max is the way to prevent it.  
Per gripe from Andrew Dunstan.  
  

Fix insufficiently-portable regression test case.

  
commit   : c0f058e4d2c8dab6f6290dc85d2ad440691d562d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2015 12:19:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2015 12:19:14 -0400    

Click here for diff

  
Some of the buildfarm members are evidently miserly enough of stack space  
to pass the originally-committed form of this test.  Increase the  
requirement 10X to hopefully ensure that it fails as-expected everywhere.  
  
Security: CVE-2015-5289  
  

Translation updates

  
commit   : 149a8cdd7a299ce25eea9157baa636c3f00f2c5f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 5 Oct 2015 10:59:53 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 5 Oct 2015 10:59:53 -0400    

Click here for diff

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

Last-minute updates for release notes.

  
commit   : 808f1bdb3d9f662c4a46a43c6cf14a6ce33b4df5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2015 10:57:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Oct 2015 10:57:15 -0400    

Click here for diff

  
Add entries for security and not-quite-security issues.  
  
Security: CVE-2015-5288, CVE-2015-5289  
  

Remove outdated comment about relation level autovacuum freeze limits.

  
commit   : 56805a428cb95394eee7c853cfcb96c066e81256    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Oct 2015 16:09:13 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Oct 2015 16:09:13 +0200    

Click here for diff

  
The documentation for the autovacuum_multixact_freeze_max_age and  
autovacuum_freeze_max_age relation level parameters contained:  
"Note that while you can set autovacuum_multixact_freeze_max_age very  
small, or even zero, this is usually unwise since it will force frequent  
vacuuming."  
which hasn't been true since these options were made relation options,  
instead of residing in the pg_autovacuum table (834a6da4f7).  
  
Remove the outdated sentence. Even the lowered limits from 2596d70 are  
high enough that this doesn't warrant calling out the risk in the CREATE  
TABLE docs.  
  
Per discussion with Tom Lane and Alvaro Herrera  
  
Discussion: 26377.1443105453@sss.pgh.pa.us  
Backpatch: 9.0- (in parts)  
  

Add regression tests for INSERT/UPDATE+RETURNING

  
commit   : f9bb9c0a8a736efb567a676ad678d05a8dc35780    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 5 Oct 2015 10:14:51 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 5 Oct 2015 10:14:51 -0400    

Click here for diff

  
This adds regressions tests which are specific to INSERT+RETURNING and  
UPDATE+RETURNING to ensure that the SELECT policies are added as  
WithCheckOptions (and should therefore throw an error when the policy is  
violated).  
  
Per suggestion from Andres.  
  
Back-patch to 9.5 as the prior commit was.  
  

Prevent stack overflow in query-type functions.

  
commit   : 7bed97d486bda5761ba7e7982e4133aeded6b852    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 5 Oct 2015 10:06:30 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 5 Oct 2015 10:06:30 -0400    

Click here for diff

  
The tsquery, ltxtquery and query_int data types have a common ancestor.  
Having acquired check_stack_depth() calls independently, each was  
missing at least one call.  Back-patch to 9.0 (all supported versions).  
  

Prevent stack overflow in container-type functions.

  
commit   : acf0da1e6476fd3217781065c7e7654873376568    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 5 Oct 2015 10:06:29 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 5 Oct 2015 10:06:29 -0400    

Click here for diff

  
A range type can name another range type as its subtype, and a record  
type can bear a column of another record type.  Consequently, functions  
like range_cmp() and record_recv() are recursive.  Functions at risk  
include operator family members and referents of pg_type regproc  
columns.  Treat as recursive any such function that looks up and calls  
the same-purpose function for a record column type or the range subtype.  
Back-patch to 9.0 (all supported versions).  
  
An array type's element type is never itself an array type, so array  
functions are unaffected.  Recursion depth proportional to array  
dimensionality, found in array_dim_to_jsonb(), is fine thanks to MAXDIM.  
  

  
commit   : 98f30d2e55d530ff47b2756b395a2048200a5ea4    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 5 Oct 2015 10:06:29 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 5 Oct 2015 10:06:29 -0400    

Click here for diff

  
Sufficiently-deep recursion heretofore elicited a SIGSEGV.  If an  
application constructs PostgreSQL json or jsonb values from arbitrary  
user input, application users could have exploited this to terminate all  
active database connections.  That applies to 9.3, where the json parser  
adopted recursive descent, and later versions.  Only row_to_json() and  
array_to_json() were at risk in 9.2, both in a non-security capacity.  
Back-patch to 9.2, where the json type was introduced.  
  
Oskari Saarenmaa, reviewed by Michael Paquier.  
  
Security: CVE-2015-5289  
  

pgcrypto: Detect and report too-short crypt() salts.

  
commit   : 4d6752277e792386e54b036aee8f64ee4fa84cf1    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 5 Oct 2015 10:06:29 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 5 Oct 2015 10:06:29 -0400    

Click here for diff

  
Certain short salts crashed the backend or disclosed a few bytes of  
backend memory.  For existing salt-induced error conditions, emit a  
message saying as much.  Back-patch to 9.0 (all supported versions).  
  
Josh Kupershmidt  
  
Security: CVE-2015-5288  
  

Apply SELECT policies in INSERT/UPDATE+RETURNING

  
commit   : bd9014768035dd70f8cc33c215a8b929c2e13a35    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 5 Oct 2015 07:55:11 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 5 Oct 2015 07:55:11 -0400    

Click here for diff

  
Similar to 7d8db3e, given that INSERT+RETURNING requires SELECT rights  
on the table, apply the SELECT policies as WCOs to the tuples being  
inserted.  Apply the same logic to UPDATE+RETURNING.  
  
Back-patch to 9.5 where RLS was added.  
  

Do not write out WCOs in Query

  
commit   : 31fb4df69d1364c79cfab0a2bd4470d0c48e942e    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 5 Oct 2015 07:38:56 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 5 Oct 2015 07:38:56 -0400    

Click here for diff

  
The WithCheckOptions list in Query are only populated during rewrite and  
do not need to be written out or read in as part of a Query structure.  
  
Further, move WithCheckOptions to the bottom and add comments to clarify  
that it is only populated during rewrite.  
  
Back-patch to 9.5 with a catversion bump, as we are still in alpha.  
  

Re-Align *_freeze_max_age reloption limits with corresponding GUC limits.

  
commit   : 0577821b57253d0ae43ffdddc8f94f07866830ae    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Oct 2015 11:53:43 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 5 Oct 2015 11:53:43 +0200    

Click here for diff

  
In 020235a5754 I lowered the autovacuum_*freeze_max_age minimums to  
allow for easier testing of wraparounds. I did not touch the  
corresponding per-table limits. While those don't matter for the purpose  
of wraparound, it seems more consistent to lower them as well.  
  
It's noteworthy that the previous reloption lower limit for  
autovacuum_multixact_freeze_max_age was too high by one magnitude, even  
before 020235a5754.  
  
Discussion: 26377.1443105453@sss.pgh.pa.us  
Backpatch: back to 9.0 (in parts), like the prior patch  
  

ALTER TABLE .. FORCE ROW LEVEL SECURITY

  
commit   : 90f334d2ca1a8bae2d0cd8a0898fb8ef90257565    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sun, 4 Oct 2015 21:05:18 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sun, 4 Oct 2015 21:05:18 -0400    

Click here for diff

  
To allow users to force RLS to always be applied, even for table owners,  
add ALTER TABLE .. FORCE ROW LEVEL SECURITY.  
  
row_security=off overrides FORCE ROW LEVEL SECURITY, to ensure pg_dump  
output is complete (by default).  
  
Also add SECURITY_NOFORCE_RLS context to avoid data corruption when  
ALTER TABLE .. FORCE ROW SECURITY is being used. The  
SECURITY_NOFORCE_RLS security context is used only during referential  
integrity checks and is only considered in check_enable_rls() after we  
have already checked that the current user is the owner of the relation  
(which should always be the case during referential integrity checks).  
  
Back-patch to 9.5 where RLS was added.  
  

Release notes for 9.5beta1, 9.4.5, 9.3.10, 9.2.14, 9.1.19, 9.0.23.

  
commit   : e78dc6b829219cacaccc59957b5375585e919099    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Oct 2015 19:38:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Oct 2015 19:38:00 -0400    

Click here for diff

  
  

Improve contrib/pg_stat_statements’ handling of garbage collection failure.

  
commit   : 39a716d93300eeb28b959a0b248009a10fa49d3c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Oct 2015 17:58:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Oct 2015 17:58:30 -0400    

Click here for diff

  
If we can't read the query texts file (whether because out-of-memory, or  
for some other reason), give up and reset the file to empty, discarding all  
stored query texts, though not the statistics per se.  We used to leave  
things alone and hope for better luck next time, but the problem is that  
the file is only going to get bigger and even harder to slurp into memory.  
Better to do something that will get us out of trouble.  
  
Likewise reset the file to empty for any other failure within gc_qtexts().  
The previous behavior after a write error was to discard query texts but  
not do anything to truncate the file, which is just weird.  
  
Also, increase the maximum supported file size from MaxAllocSize to  
MaxAllocHugeSize; this makes it more likely we'll be able to do a garbage  
collection successfully.  
  
Also, fix recalculation of mean_query_len within entry_dealloc() to match  
the calculation in gc_qtexts().  The previous coding overlooked the  
possibility of dropped texts (query_len == -1) and would underestimate the  
mean of the remaining entries in such cases, thus possibly causing excess  
garbage collection cycles.  
  
In passing, add some errdetail to the log entry that complains about  
insufficient memory to read the query texts file, which after all was  
Jim Nasby's original complaint.  
  
Back-patch to 9.4 where the current handling of query texts was  
introduced.  
  
Peter Geoghegan, rather editorialized upon by me  
  

Further twiddling of nodeHash.c hashtable sizing calculation.

  
commit   : e5c94c7bbcf091617f0720a3ccbe898cd8beff17    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Oct 2015 15:55:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Oct 2015 15:55:07 -0400    

Click here for diff

  
On reflection, the submitted patch didn't really work to prevent the  
request size from exceeding MaxAllocSize, because of the fact that we'd  
happily round nbuckets up to the next power of 2 after we'd limited it to  
max_pointers.  The simplest way to enforce the limit correctly is to  
round max_pointers down to a power of 2 when it isn't one already.  
  
(Note that the constraint to INT_MAX / 2, if it were doing anything useful  
at all, is properly applied after that.)  
  

Fix some issues in new hashtable size calculations in nodeHash.c.

  
commit   : ca5b42d85486f814b3b510e436157f443fd73683    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Oct 2015 14:06:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Oct 2015 14:06:40 -0400    

Click here for diff

  
Limit the size of the hashtable pointer array to not more than  
MaxAllocSize, per reports from Kouhei Kaigai and others of "invalid memory  
alloc request size" failures.  There was discussion of allowing the array  
to get larger than that by using the "huge" palloc API, but so far no proof  
that that is actually a good idea, and at this point in the 9.5 cycle major  
changes from old behavior don't seem like the way to go.  
  
Fix a rather serious secondary bug in the new code, which was that it  
didn't ensure nbuckets remained a power of 2 when recomputing it for the  
multiple-batch case.  
  
Clean up sloppy division of labor between ExecHashIncreaseNumBuckets and  
its sole call site.  
  

Disallow invalid path elements in jsonb_set

  
commit   : 544ccf644288132f805260c4eb9fd12029c5cf8c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 4 Oct 2015 13:28:16 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 4 Oct 2015 13:28:16 -0400    

Click here for diff

  
Null path elements and, where the object is an array, invalid integer  
elements now cause an error.  
  
Incorrect behaviour noted by Thom Brown, patch from Dmitry Dolgov.  
  
Backpatch to 9.5 where jsonb_set was introduced  
  

Group cluster_name and update_process_title settings together

  
commit   : e45f8f882055d5f864815aa29ffcd2b5e3c2013b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 4 Oct 2015 11:14:28 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 4 Oct 2015 11:14:28 -0400    

Click here for diff

  
  

Document that row_security is a boolean GUC.

  
commit   : 4365d9c18fc1ebb14de92595aa0340c5b8301547    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 3 Oct 2015 20:20:22 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 3 Oct 2015 20:20:22 -0400    

Click here for diff

  
Oversight in commit 537bd178c73b1d25938347b17e9e3e62898fc231.  
Back-patch to 9.5, like that commit.  
  

Make BYPASSRLS behave like superuser RLS bypass.

  
commit   : 01ba7894f3f72ea57d1cfdc4f40f6231bc6cd9cd    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 3 Oct 2015 20:19:57 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 3 Oct 2015 20:19:57 -0400    

Click here for diff

  
Specifically, make its effect independent from the row_security GUC, and  
make it affect permission checks pertinent to views the BYPASSRLS role  
owns.  The row_security GUC thereby ceases to change successful-query  
behavior; it can only make a query fail with an error.  Back-patch to  
9.5, where BYPASSRLS was introduced.  
  

Improve errhint() about replication slot naming restrictions.

  
commit   : cfddb5df5a84923160b23890d6086bcbcd1fd655    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 3 Oct 2015 15:29:08 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 3 Oct 2015 15:29:08 +0200    

Click here for diff

  
The existing hint talked about "may only contain letters", but the  
actual requirement is more strict: only lower case letters are allowed.  
  
Reported-By: Rushabh Lathia  
Author: Rushabh Lathia  
Discussion: AGPqQf2x50qcwbYOBKzb4x75sO_V3g81ZsA8+Ji9iN5t_khFhQ@mail.gmail.com  
Backpatch: 9.4-, where replication slots were added  
  

  
commit   : 7285d66494a4c588ccf743a81f93b85b6995214f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 3 Oct 2015 15:12:10 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 3 Oct 2015 15:12:10 +0200    

Click here for diff

  
Four related issues:  
  
1) attnos/varnos/resnos for EXCLUDED were out of sync when a column  
   after one dropped in the underlying relation was referenced.  
2) References to whole-row variables (i.e. EXCLUDED.*) lead to errors.  
3) It was possible to reference system columns in the EXCLUDED pseudo  
   relations, even though they would not have valid contents.  
4) References to EXCLUDED were rewritten by the RLS machinery, as  
   EXCLUDED was treated as if it were the underlying relation.  
  
To fix the first two issues, generate the excluded targetlist with  
dropped columns in mind and add an entry for whole row  
variables. Instead of unconditionally adding a wholerow entry we could  
pull up the expression if needed, but doing it unconditionally seems  
simpler. The wholerow entry is only really needed for ruleutils/EXPLAIN  
support anyway.  
  
The remaining two issues are addressed by changing the EXCLUDED RTE to  
have relkind = composite. That fits with EXCLUDED not actually being a  
real relation, and allows to treat it differently in the relevant  
places. scanRTEForColumn now skips looking up system columns when the  
RTE has a composite relkind; fireRIRrules() already had a corresponding  
check, thereby preventing RLS expansion on EXCLUDED.  
  
Also add tests for these issues, and improve a few comments around  
excluded handling in setrefs.c.  
  
Reported-By: Peter Geoghegan, Geoff Winkless  
Author: Andres Freund, Amit Langote, Peter Geoghegan  
Discussion: CAEzk6fdzJ3xYQZGbcuYM2rBd2BuDkUksmK=mY9UYYDugg_GgZg@mail.gmail.com,  
   CAM3SWZS+CauzbiCEcg-GdE6K6ycHE_Bz6Ksszy8AoixcMHOmsA@mail.gmail.com  
Backpatch: 9.5, where ON CONFLICT was introduced  
  

doc: Update URLs of external projects

  
commit   : 0777a887c24197d1d9d611ecc4b85a2d74b616b2    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 2 Oct 2015 21:50:59 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 2 Oct 2015 21:50:59 -0400    

Click here for diff

  
  

doc: Make some index terms and terminology more consistent

  
commit   : 5f904924bc270fd2d8dcc29f8267515e79a07baf    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 2 Oct 2015 21:22:44 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 2 Oct 2015 21:22:44 -0400    

Click here for diff

  
  

Update time zone data files to tzdata release 2015g.

  
commit   : 19b06cc669fe128ad6181a97a00bcc26889ad0da    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 19:15:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 19:15:39 -0400    

Click here for diff

  
DST law changes in Cayman Islands, Fiji, Moldova, Morocco, Norfolk Island,  
North Korea, Turkey, Uruguay.  New zone America/Fort_Nelson for Canadian  
Northern Rockies.  
  

Clarify FDW documentation about ON CONFLICT.

  
commit   : 63e86ecacd505f2e1c125ff2361f47754f3e18c0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 2 Oct 2015 16:55:47 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 2 Oct 2015 16:55:47 -0400    

Click here for diff

  
Etsuro Fujita, reviewed by Peter Geoghegan  
  

Add recursion depth protection to LIKE matching.

  
commit   : bdc5d95b60bc1f17962a6b6184924b3672bd2f60    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 15:00:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 15:00:52 -0400    

Click here for diff

  
Since MatchText() recurses, it could in principle be driven to stack  
overflow, although quite a long pattern would be needed.  
  

Add recursion depth protections to regular expression matching.

  
commit   : 20c627707c44deaed92c5d67b350f27e06e24228    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 14:51:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 14:51:58 -0400    

Click here for diff

  
Some of the functions in regex compilation and execution recurse, and  
therefore could in principle be driven to stack overflow.  The Tcl crew  
has seen this happen in practice in duptraverse(), though their fix was  
to put in a hard-wired limit on the number of recursive levels, which is  
not too appetizing --- fortunately, we have enough infrastructure to check  
the actually available stack.  Greg Stark has also seen it in other places  
while fuzz testing on a machine with limited stack space.  Let's put guards  
in to prevent crashes in all these places.  
  
Since the regex code would leak memory if we simply threw elog(ERROR),  
we have to introduce an API that checks for stack depth without throwing  
such an error.  Fortunately that's not difficult.  
  

Fix potential infinite loop in regular expression execution.

  
commit   : 51f235931dd25d704cb2f257eaa97ee2cd13c3e6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 14:26:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 14:26:36 -0400    

Click here for diff

  
In cfindloop(), if the initial call to shortest() reports that a  
zero-length match is possible at the current search start point, but then  
it is unable to construct any actual match to that, it'll just loop around  
with the same start point, and thus make no progress.  We need to force the  
start point to be advanced.  This is safe because the loop over "begin"  
points has already tried and failed to match starting at "close", so there  
is surely no need to try that again.  
  
This bug was introduced in commit e2bd904955e2221eddf01110b1f25002de2aaa83,  
wherein we allowed continued searching after we'd run out of match  
possibilities, but evidently failed to think hard enough about exactly  
where we needed to search next.  
  
Because of the way this code works, such a match failure is only possible  
in the presence of backrefs --- otherwise, shortest()'s judgment that a  
match is possible should always be correct.  That probably explains how  
come the bug has escaped detection for several years.  
  
The actual fix is a one-liner, but I took the trouble to add/improve some  
comments related to the loop logic.  
  
After fixing that, the submitted test case "()*\1" didn't loop anymore.  
But it reported failure, though it seems like it ought to match a  
zero-length string; both Tcl and Perl think it does.  That seems to be from  
overenthusiastic optimization on my part when I rewrote the iteration match  
logic in commit 173e29aa5deefd9e71c183583ba37805c8102a72: we can't just  
"declare victory" for a zero-length match without bothering to set match  
data for capturing parens inside the iterator node.  
  
Per fuzz testing by Greg Stark.  The first part of this is a bug in all  
supported branches, and the second part is a bug since 9.2 where the  
iteration rewrite happened.  
  

Add some more query-cancel checks to regular expression matching.

  
commit   : bb704a781ada30b34b377937e8e39c2dae532cec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 13:45:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 13:45:39 -0400    

Click here for diff

  
Commit 9662143f0c35d64d7042fbeaf879df8f0b54be32 added infrastructure to  
allow regular-expression operations to be terminated early in the event  
of SIGINT etc.  However, fuzz testing by Greg Stark disclosed that there  
are still cases where regex compilation could run for a long time without  
noticing a cancel request.  Specifically, the fixempties() phase never  
adds new states, only new arcs, so it doesn't hit the cancel check I'd put  
in newstate().  Add one to newarc() as well to cover that.  
  
Some experimentation of my own found that regex execution could also run  
for a long time despite a pending cancel.  We'd put a high-level cancel  
check into cdissect(), but there was none inside the core text-matching  
routines longest() and shortest().  Ordinarily those inner loops are very  
very fast ... but in the presence of lookahead constraints, not so much.  
As a compromise, stick a cancel check into the stateset cache-miss  
function, which is enough to guarantee a cancel check at least once per  
lookahead constraint test.  
  
Making this work required more attention to error handling throughout the  
regex executor.  Henry Spencer had apparently originally intended longest()  
and shortest() to be incapable of incurring errors while running, so  
neither they nor their subroutines had well-defined error reporting  
behaviors.  However, that was already broken by the lookahead constraint  
feature, since lacon() can surely suffer an out-of-memory failure ---  
which, in the code as it stood, might never be reported to the user at all,  
but just silently be treated as a non-match of the lookahead constraint.  
Normalize all that by inserting explicit error tests as needed.  I took the  
opportunity to add some more comments to the code, too.  
  
Back-patch to all supported branches, like the previous patch.  
  

Docs: add disclaimer about hazards of using regexps from untrusted sources.

  
commit   : c56b2aa6efd1c0d090a9747a8220bf5110e9f9fd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 13:30:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 13:30:42 -0400    

Click here for diff

  
It's not terribly hard to devise regular expressions that take large  
amounts of time and/or memory to process.  Recent testing by Greg Stark has  
also shown that machines with small stack limits can be driven to stack  
overflow by suitably crafted regexps.  While we intend to fix these things  
as much as possible, it's probably impossible to eliminate slow-execution  
cases altogether.  In any case we don't want to treat such things as  
security issues.  The history of that code should already discourage  
prudent DBAs from allowing execution of regexp patterns coming from  
possibly-hostile sources, but it seems like a good idea to warn about the  
hazard explicitly.  
  
Currently, similar_escape() allows access to enough of the underlying  
regexp behavior that the warning has to apply to SIMILAR TO as well.  
We might be able to make it safer if we tightened things up to allow only  
SQL-mandated capabilities in SIMILAR TO; but that would be a subtly  
non-backwards-compatible change, so it requires discussion and probably  
could not be back-patched.  
  
Per discussion among pgsql-security list.  
  

Docs: add another example of creating a range type.

  
commit   : 1dc6f557e7020269436cbf8a66e68bc6e66def0c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 12:20:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 12:20:01 -0400    

Click here for diff

  
The "floatrange" example is a bit too simple because float8mi can be  
used without any additional type conversion.  Add an example that does  
have to account for that, and do some minor other wordsmithing.  
  

Don’t disable commit_ts in standby if enabled locally

  
commit   : 65dc1fc99a257a98961bfb964a1a95b2f521cd74    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 2 Oct 2015 12:49:01 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 2 Oct 2015 12:49:01 -0300    

Click here for diff

  
Bug noticed by Fujii Masao  
  

pg_rewind: Improve some messages

  
commit   : 0f51a848ab98325e497a227155648facd9d0cf9b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 1 Oct 2015 21:42:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 1 Oct 2015 21:42:00 -0400    

Click here for diff

  
The output of a typical pg_rewind run contained a mix of capitalized and  
not-capitalized and punctuated and not-punctuated phrases for no  
apparent reason.  Make that consistent.  Also fix some problems in other  
messages.  
  

Fix message punctuation according to style guide

  
commit   : 867bc6849f141e17cd4d3b416f48cc46839f2d76    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 1 Oct 2015 21:39:56 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 1 Oct 2015 21:39:56 -0400    

Click here for diff

  
  

Fix pg_dump to handle inherited NOT VALID check constraints correctly.

  
commit   : 5ea47e8f2a7d524eb491b1ffffbc98a012745409    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Oct 2015 16:19:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Oct 2015 16:19:49 -0400    

Click here for diff

  
This case seems to have been overlooked when unvalidated check constraints  
were introduced, in 9.2.  The code would attempt to dump such constraints  
over again for each child table, even though adding them to the parent  
table is sufficient.  
  
In 9.2 and 9.3, also fix contrib/pg_upgrade/Makefile so that the "make  
clean" target fully cleans up after a failed test.  This evidently got  
dealt with at some point in 9.4, but it wasn't back-patched.  I ran into  
it while testing this fix ...  
  
Per bug #13656 from Ingmar Brouns.  
  

Fix commit_ts for standby

  
commit   : a742ef86c228d8a0e9d174c651cfc4f96ac77e61    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 1 Oct 2015 15:06:55 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 1 Oct 2015 15:06:55 -0300    

Click here for diff

  
Module initialization was still not completely correct after commit  
6b61955135e9, per crash report from Takashi Ohnishi.  To fix, instead of  
trying to monkey around with the value of the GUC setting directly, add  
a separate boolean flag that enables the feature on a standby, but only  
for the startup (recovery) process, when it sees that its master server  
has the feature enabled.  
Discussion: http://www.postgresql.org/message-id/ca44c6c7f9314868bdc521aea4f77cbf@MP-MSGSS-MBX004.msg.nttdata.co.jp  
  
Also change the deactivation routine to delete all segment files rather  
than leaving the last one around.  (This doesn't need separate  
WAL-logging, because on recovery we execute the same deactivation  
routine anyway.)  
  
In passing, clean up the code structure somewhat, particularly so that  
xlog.c doesn't know so much about when to activate/deactivate the  
feature.  
  
Thanks to Fujii Masao for testing and Petr Jelínek for off-list discussion.  
  
Back-patch to 9.5, where commit_ts was introduced.  
  

Fix documentation error in commit 8703059c6b55c427100e00a09f66534b6ccbfaa1.

  
commit   : d312cc37e4e4081149d3874974d9d7618ca574af    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Oct 2015 10:31:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Oct 2015 10:31:22 -0400    

Click here for diff

  
Etsuro Fujita spotted a thinko in the README commentary.  
  

Fix mention of htup.h in storage.sgml

  
commit   : c9a8d05465b5ed662235966554cb70d61d00707c    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 1 Oct 2015 23:00:52 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 1 Oct 2015 23:00:52 +0900    

Click here for diff

  
Previously it was documented that the details on HeapTupleHeaderData  
struct could be found in htup.h. This is not correct because it's now  
defined in htup_details.h.  
  
Back-patch to 9.3 where the definition of HeapTupleHeaderData struct  
was moved from htup.h to htup_details.h.  
  
Michael Paquier  
  

Improve LISTEN startup time when there are many unread notifications.

  
commit   : 8c8a834b14712de5252858aebbd4c5900c105c78    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Sep 2015 23:32:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Sep 2015 23:32:23 -0400    

Click here for diff

  
If some existing listener is far behind, incoming new listener sessions  
would start from that session's read pointer and then need to advance over  
many already-committed notification messages, which they have no interest  
in.  This was expensive in itself and also thrashed the pg_notify SLRU  
buffers a lot more than necessary.  We can improve matters considerably  
in typical scenarios, without much added cost, by starting from the  
furthest-ahead read pointer, not the furthest-behind one.  We do have to  
consider only sessions in our own database when doing this, which requires  
an extra field in the data structure, but that's a pretty small cost.  
  
Back-patch to 9.0 where the current LISTEN/NOTIFY logic was introduced.  
  
Matt Newell, slightly adjusted by me  
  

Don’t dump core when destroying an unused ParallelContext.

  
commit   : 91d97f03ca2a9ed56b322b69dde0392db835f722    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 30 Sep 2015 18:36:31 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 30 Sep 2015 18:36:31 -0400    

Click here for diff

  
If a transaction or subtransaction creates a ParallelContext but ends  
without calling InitializeParallelDSM, the previous code would  
seg fault.  Fix that.  
  

Include policies based on ACLs needed

  
commit   : 75096c458aa8e27160112cc20a18fec3a111e4b0    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Wed, 30 Sep 2015 07:39:24 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Wed, 30 Sep 2015 07:39:24 -0400    

Click here for diff

  
When considering which policies should be included, rather than look at  
individual bits of the query (eg: if a RETURNING clause exists, or if a  
WHERE clause exists which is referencing the table, or if it's a  
FOR SHARE/UPDATE query), consider any case where we've determined  
the user needs SELECT rights on the relation while doing an UPDATE or  
DELETE to be a case where we apply SELECT policies, and any case where  
we've deteremind that the user needs UPDATE rights on the relation while  
doing a SELECT to be a case where we apply UPDATE policies.  
  
This simplifies the logic and addresses concerns that a user could use  
UPDATE or DELETE with a WHERE clauses to determine if rows exist, or  
they could use SELECT .. FOR UPDATE to lock rows which they are not  
actually allowed to modify through UPDATE policies.  
  
Use list_append_unique() to avoid adding the same quals multiple times,  
as, on balance, the cost of checking when adding the quals will almost  
always be cheaper than keeping them and doing busywork for each tuple  
during execution.  
  
Back-patch to 9.5 where RLS was added.  
  

Fix incorrect tps number calculation in “excluding connections establishing”.

  
commit   : 3c4c5acc40720a178e06da6258ce20d3c6e025ab    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Wed, 30 Sep 2015 10:36:23 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Wed, 30 Sep 2015 10:36:23 +0900    

Click here for diff

  
The tolerance (larger than actual tps number) increases as the number  
of threads decreases.  The bug has been there since the thread support  
was introduced in 9.0. Because back patching introduces incompatible  
behavior changes regarding the tps number, the fix is committed to  
master and 9.5 stable branches only.  
  
Problem spotted by me and fix proposed by Fabien COELHO. Note that his  
original patch included more than fixes (a code re-factoring) which is  
not related to the problem and I omitted the part.  
  

Code review for transaction commit timestamps

  
commit   : d8c7bb21ea2a3122cac96b2996d3122f25c160c3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 29 Sep 2015 14:40:56 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 29 Sep 2015 14:40:56 -0300    

Click here for diff

  
There are three main changes here:  
  
1. No longer cause a start failure in a standby if the feature is  
disabled in postgresql.conf but enabled in the master.  This reverts one  
part of commit 4f3924d9cd43; what we keep is the ability of the standby  
to activate/deactivate the module (which includes creating and removing  
segments as appropriate) during replay of such actions in the master.  
  
2. Replay WAL records affecting commitTS even if the feature is  
disabled.  This means the standby will always have the same state as the  
master after replay.  
  
3. Have COMMIT PREPARE record the transaction commit time as well.  We  
were previously only applying it in the normal transaction commit path.  
  
Author: Petr Jelínek  
Discussion: http://www.postgresql.org/message-id/CAHGQGwHereDzzzmfxEBYcVQu3oZv6vZcgu1TPeERWbDc+gQ06g@mail.gmail.com  
Discussion: http://www.postgresql.org/message-id/CAHGQGwFuzfO4JscM9LCAmCDCxp_MfLvN4QdB+xWsS-FijbjTYQ@mail.gmail.com  
  
Additionally, I cleaned up nearby code related to replication origins,  
which I found a bit hard to follow, and fixed a couple of typos.  
  
Backpatch to 9.5, where this code was introduced.  
  
Per bug reports from Fujii Masao and subsequent discussion.  
  

Fix plperl to handle non-ASCII error message texts correctly.

  
commit   : a16b9b19389d1832286f4d8f259dab0d5be88856    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Sep 2015 10:52:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Sep 2015 10:52:22 -0400    

Click here for diff

  
We were passing error message texts to croak() verbatim, which turns out  
not to work if the text contains non-ASCII characters; Perl mangles their  
encoding, as reported in bug #13638 from Michal Leinweber.  To fix, convert  
the text into a UTF8-encoded SV first.  
  
It's hard to test this without risking failures in different database  
encodings; but we can follow the lead of plpython, which is already  
assuming that no-break space (U+00A0) has an equivalent in all encodings  
we care about running the regression tests in (cf commit 2dfa15de5).  
  
Back-patch to 9.1.  The code is quite different in 9.0, and anyway it seems  
too risky to put something like this into 9.0's final minor release.  
  
Alex Hunsaker, with suggestions from Tim Bunce and Tom Lane  
  

Comment update for join pushdown.

  
commit   : 9a6fbc2ac709aa8152e6d5d44a107d2d7c67b6f4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 29 Sep 2015 07:42:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 29 Sep 2015 07:42:30 -0400    

Click here for diff

  
Etsuro Fujita  
  

Fix compiler warning for non-TIOCGWINSZ case

  
commit   : 60fcee9e5e77dc748a9787fae34328917683b95e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 28 Sep 2015 18:42:30 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 28 Sep 2015 18:42:30 -0400    

Click here for diff

  
Backpatch to 9.5 where the error was introduced.  
  

Fix compiler warning about unused function in non-readline case.

  
commit   : c4e6d506c6b028d6ccdac4e2a23b3484fba6c39e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 28 Sep 2015 18:29:20 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 28 Sep 2015 18:29:20 -0400    

Click here for diff

  
Backpatch to all live branches to keep the code in sync.  
  

Fix “sesssion” typo

  
commit   : aea76d128ad85f38aa0f4255fb9d46d95b835755    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 28 Sep 2015 19:13:42 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 28 Sep 2015 19:13:42 -0300    

Click here for diff

  
It was introduced alongside replication origins, by commit  
5aa2350426c, so backpatch to 9.5.  
  
Pointed out by Fujii Masao  
  

Fix poor errno handling in libpq’s version of our custom OpenSSL BIO.

  
commit   : b67c9c1939f10e94186d2736039ff623dbb2ce3f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Sep 2015 18:02:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Sep 2015 18:02:38 -0400    

Click here for diff

  
Thom Brown reported that SSL connections didn't seem to work on Windows in  
9.5.  Asif Naeem figured out that the cause was my_sock_read() looking at  
"errno" when it needs to look at "SOCK_ERRNO".  This mistake was introduced  
in commit 680513ab79c7e12e402a2aad7921b95a25a4bcc8, which cloned the  
backend's custom SSL BIO code into libpq, and didn't translate the errno  
handling properly.  Moreover, it introduced unnecessary errno save/restore  
logic, which was particularly confusing because it was incomplete; and it  
failed to check for all three of EINTR, EAGAIN, and EWOULDBLOCK in  
my_sock_write.  (That might not be necessary; but since we're copying  
well-tested backend code that does do that, it seems prudent to copy it  
faithfully.)  
  

Ensure a few policies remain for pg_upgrade

  
commit   : ce585027ebc26554d77cde9d8f2721a8cca55381    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 28 Sep 2015 15:48:36 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 28 Sep 2015 15:48:36 -0400    

Click here for diff

  
To make sure that pg_dump/pg_restore function properly with RLS  
policies, arrange to have a few of them left around at the end of the  
regression tests.  
  
Back-patch to 9.5 where RLS was added.  
  

Fix ON CONFLICT DO UPDATE for tables with oids.

  
commit   : 90586ef127c593002897ee0bcafdf2adb6a18c7d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 28 Sep 2015 19:12:48 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 28 Sep 2015 19:12:48 +0200    

Click here for diff

  
When taking the UPDATE path in an INSERT .. ON CONFLICT .. UPDATE tables  
with oids were not supported. The tuple generated by the update target  
list was projected without space for an oid - a simple oversight.  
  
Reported-By: Peter Geoghegan  
Author: Andres Freund  
Backpatch: 9.5, where ON CONFLICT was introduced  
  

Don’t try to create a temp install without abs_top_builddir.

  
commit   : 80e2694b284cd9395b1ee8ef476f5f720ee50566    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 28 Sep 2015 10:47:05 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 28 Sep 2015 10:47:05 -0400    

Click here for diff

  
Otherwise, we effectively act as if abs_top_builddir were the root  
directory, which is quite dangerous if the user happens to have  
permissions to do things there.  This can crop up in PGXS builds,  
for example.  
  
Report by Sandro Santilli, patch by me, review by Noah Misch.  
  

pg_dump: Fix some messages

  
commit   : 27af56b59515a676e733a143e0ebaf9e0c921be6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 27 Sep 2015 20:29:40 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 27 Sep 2015 20:29:40 -0400    

Click here for diff

  
Make quoting style match existing style.  Improve plural support.  
  

reindexdb: Fix mistake in help output

  
commit   : 90d037772ec161436590699c5c6b057d1a0170d6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 27 Sep 2015 11:22:16 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 27 Sep 2015 11:22:16 -0400    

Click here for diff

  
  

pg_ctl: Improve help formatting and order

  
commit   : 63ab1a398166daafcea2aaebbf0c48cb78b5be32    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 26 Sep 2015 21:09:52 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 26 Sep 2015 21:09:52 -0400    

Click here for diff

  
  

doc: Tweak “cube” index entry

  
commit   : 0160c1d23910a71def6166c6fd3d4586216b7305    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 26 Sep 2015 21:00:59 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 26 Sep 2015 21:00:59 -0400    

Click here for diff

  
With the arrival of the CUBE key word/feature, the index entries for the  
cube extension and the CUBE feature were collapsed into one.  Tweak the  
entry for the cube extension so they are separate entries.  
  

Remove legacy multixact truncation support.

  
commit   : 6e8af37643099310e5d47a12152872e325b930f0    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 26 Sep 2015 19:04:25 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 26 Sep 2015 19:04:25 +0200    

Click here for diff

  
In 9.5 and master there is no need to support legacy truncation. This is  
just committed separately to make it easier to backpatch the WAL logged  
multixact truncation to 9.3 and 9.4 if we later decide to do so.  
  
I bumped master's magic from 0xD086 to 0xD088 and 9.5's from 0xD085 to  
0xD087 to avoid 9.5 reusing a value that has been in use on master while  
keeping the numbers increasing between major versions.  
  
Discussion: 20150621192409.GA4797@alap3.anarazel.de  
Backpatch: 9.5  
  

Rework the way multixact truncations work.

  
commit   : bd7c348d83a4576163b635010e49dbcac7126f01    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 26 Sep 2015 19:04:25 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 26 Sep 2015 19:04:25 +0200    

Click here for diff

  
The fact that multixact truncations are not WAL logged has caused a fair  
share of problems. Amongst others it requires to do computations during  
recovery while the database is not in a consistent state, delaying  
truncations till checkpoints, and handling members being truncated, but  
offset not.  
  
We tried to put bandaids on lots of these issues over the last years,  
but it seems time to change course. Thus this patch introduces WAL  
logging for multixact truncations.  
  
This allows:  
1) to perform the truncation directly during VACUUM, instead of delaying it  
   to the checkpoint.  
2) to avoid looking at the offsets SLRU for truncation during recovery,  
   we can just use the master's values.  
3) simplify a fair amount of logic to keep in memory limits straight,  
   this has gotten much easier  
  
During the course of fixing this a bunch of additional bugs had to be  
fixed:  
1) Data was not purged from memory the member's SLRU before deleting  
   segments. This happened to be hard or impossible to hit due to the  
   interlock between checkpoints and truncation.  
2) find_multixact_start() relied on SimpleLruDoesPhysicalPageExist - but  
   that doesn't work for offsets that haven't yet been flushed to  
   disk. Add code to flush the SLRUs to fix. Not pretty, but it feels  
   slightly safer to only make decisions based on actual on-disk state.  
3) find_multixact_start() could be called concurrently with a truncation  
   and thus fail. Via SetOffsetVacuumLimit() that could lead to a round  
   of emergency vacuuming. The problem remains in  
   pg_get_multixact_members(), but that's quite harmless.  
  
For now this is going to only get applied to 9.5+, leaving the issues in  
the older branches in place. It is quite possible that we need to  
backpatch at a later point though.  
  
For the case this gets backpatched we need to handle that an updated  
standby may be replaying WAL from a not-yet upgraded primary. We have to  
recognize that situation and use "old style" truncation (i.e. looking at  
the SLRUs) during WAL replay. In contrast to before, this now happens in  
the startup process, when replaying a checkpoint record, instead of the  
checkpointer. Doing truncation in the restartpoint is incorrect, they  
can happen much later than the original checkpoint, thereby leading to  
wraparound.  To avoid "multixact_redo: unknown op code 48" errors  
standbys would have to be upgraded before primaries.  
  
A later patch will bump the WAL page magic, and remove the legacy  
truncation codepaths. Legacy truncation support is just included to make  
a possible future backpatch easier.  
  
Discussion: 20150621192409.GA4797@alap3.anarazel.de  
Reviewed-By: Robert Haas, Alvaro Herrera, Thomas Munro  
Backpatch: 9.5 for now  
  

Second try at fixing O(N^2) problem in foreign key references.

  
commit   : c9645f75785c607a31ba4acebf87d0ad38446aeb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Sep 2015 13:16:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Sep 2015 13:16:30 -0400    

Click here for diff

  
This replaces ill-fated commit 5ddc72887a012f6a8b85707ef27d85c274faf53d,  
which was reverted because it broke active uses of FK cache entries.  In  
this patch, we still do nothing more to invalidatable cache entries than  
mark them as needing revalidation, so we won't break active uses.  To keep  
down the overhead of InvalidateConstraintCacheCallBack(), keep a list of  
just the currently-valid cache entries.  (The entries are large enough that  
some added space for list links doesn't seem like a big problem.)  This  
would still be O(N^2) when there are many valid entries, though, so when  
the list gets too long, just force the "sinval reset" behavior to remove  
everything from the list.  I set the threshold at 1000 entries, somewhat  
arbitrarily.  Possibly that could be fine-tuned later.  Another item for  
future study is whether it's worth adding reference counting so that we  
could safely remove invalidated entries.  As-is, problem cases are likely  
to end up with large and mostly invalid FK caches.  
  
Like the previous attempt, backpatch to 9.3.  
  
Jan Wieck and Tom Lane  
  

Further fix for psql’s code for locale-aware formatting of numeric output.

  
commit   : 5eb7024379ec0701ce2fae242ae90d7d56ee72bb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Sep 2015 12:20:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Sep 2015 12:20:45 -0400    

Click here for diff

  
(Third time's the charm, I hope.)  
  
Additional testing disclosed that this code could mangle already-localized  
output from the "money" datatype.  We can't very easily skip applying it  
to "money" values, because the logic is tied to column right-justification  
and people expect "money" output to be right-justified.  Short of  
decoupling that, we can fix it in what should be a safe enough way by  
testing to make sure the string doesn't contain any characters that would  
not be expected in plain numeric output.  
  

Further fix for psql’s code for locale-aware formatting of numeric output.

  
commit   : da4af91cefaabe493577f1d6d17ee78f2e66389c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Sep 2015 00:00:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Sep 2015 00:00:33 -0400    

Click here for diff

  
On closer inspection, those seemingly redundant atoi() calls were not so  
much inefficient as just plain wrong: the author of this code either had  
not read, or had not understood, the POSIX specification for localeconv().  
The grouping field is *not* a textual digit string but separate integers  
encoded as chars.  
  
We'll follow the existing code as well as the backend's cash.c in only  
honoring the first group width, but let's at least honor it correctly.  
  
This doesn't actually result in any behavioral change in any of the  
locales I have installed on my Linux box, which may explain why nobody's  
complained; grouping width 3 is close enough to universal that it's barely  
worth considering other cases.  Still, wrong is wrong, so back-patch.  
  

Fix psql’s code for locale-aware formatting of numeric output.

  
commit   : f1ee153dcf1a3bd64889f56bee6a863f54e97d99    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Sep 2015 23:01:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Sep 2015 23:01:04 -0400    

Click here for diff

  
This code did the wrong thing entirely for numbers with an exponent  
but no decimal point (e.g., '1e6'), as reported by Jeff Janes in  
bug #13636.  More generally, it made lots of unverified assumptions  
about what the input string could possibly look like.  Rearrange so  
that it only fools with leading digits that it's directly verified  
are there, and an immediately adjacent decimal point.  While at it,  
get rid of some useless inefficiencies, like converting the grouping  
count string to integer over and over (and over).  
  
This has been broken for a long time, so back-patch to all supported  
branches.  
  

Allow planner to use expression-index stats for function calls in WHERE.

  
commit   : 45d256c2792e20c52235470e62a70c9c80a96274    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Sep 2015 18:35:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Sep 2015 18:35:46 -0400    

Click here for diff

  
Previously, a function call appearing at the top level of WHERE had a  
hard-wired selectivity estimate of 0.3333333, a kludge conveniently dated  
in the source code itself to July 1992.  The expectation at the time was  
that somebody would soon implement estimator support functions analogous  
to those for operators; but no such code has appeared, nor does it seem  
likely to in the near future.  We do have an alternative solution though,  
at least for immutable functions on single relations: creating an  
expression index on the function call will allow ANALYZE to gather stats  
about the function's selectivity.  But the code in clause_selectivity()  
failed to make use of such data even if it exists.  
  
Refactor so that that will happen.  I chose to make it try this technique  
for any clause type for which clause_selectivity() doesn't have a special  
case, not just functions.  To avoid adding unnecessary overhead in the  
common case where we don't learn anything new, make selfuncs.c provide an  
API that hooks directly to examine_variable() and then var_eq_const(),  
rather than the previous coding which laboriously constructed an OpExpr  
only so that it could be expensively deconstructed again.  
  
I preserved the behavior that the default estimate for a function call  
is 0.3333333.  (For any other expression node type, it's 0.5, as before.)  
I had originally thought to make the default be 0.5 across the board, but  
changing a default estimate that's survived for twenty-three years seems  
like something not to do without a lot more testing than I care to put  
into it right now.  
  
Per a complaint from Jehan-Guillaume de Rorthais.  Back-patch into 9.5,  
but not further, at least for the moment.  
  

Improve handling of collations in contrib/postgres_fdw.

  
commit   : 59d765b6554093701329be935b52d82d9af01401    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Sep 2015 12:47:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Sep 2015 12:47:30 -0400    

Click here for diff

  
If we have a local Var of say varchar type with default collation, and  
we apply a RelabelType to convert that to text with default collation, we  
don't want to consider that as creating an FDW_COLLATE_UNSAFE situation.  
It should be okay to compare that to a remote Var, so long as the remote  
Var determines the comparison collation.  (When we actually ship such an  
expression to the remote side, the local Var would become a Param with  
default collation, meaning the remote Var would in fact control the  
comparison collation, because non-default implicit collation overrides  
default implicit collation in parse_collate.c.)  To fix, be more precise  
about what FDW_COLLATE_NONE means: it applies either to a noncollatable  
data type or to a collatable type with default collation, if that collation  
can't be traced to a remote Var.  (When it can, FDW_COLLATE_SAFE is  
appropriate.)  We were essentially using that interpretation already at  
the Var/Const/Param level, but we weren't bubbling it up properly.  
  
An alternative fix would be to introduce a separate FDW_COLLATE_DEFAULT  
value to describe the second situation, but that would add more code  
without changing the actual behavior, so it didn't seem worthwhile.  
  
Also, since we're clarifying the rule to be that we care about whether  
operator/function input collations match, there seems no need to fail  
immediately upon seeing a Const/Param/non-foreign-Var with nondefault  
collation.  We only have to reject if it appears in a collation-sensitive  
context (for example, "var IS NOT NULL" is perfectly safe from a collation  
standpoint, whatever collation the var has).  So just set the state to  
UNSAFE rather than failing immediately.  
  
Per report from Jeevan Chalke.  This essentially corrects some sloppy  
thinking in commit ed3ddf918b59545583a4b374566bc1148e75f593, so back-patch  
to 9.3 where that logic appeared.  
  

Make pg_controldata report newest XID with valid commit timestamp

  
commit   : eac3b3365e6220ce03bc05914c8e7f5430341373    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 24 Sep 2015 23:31:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 24 Sep 2015 23:31:17 +0900    

Click here for diff

  
Previously pg_controldata didn't report newestCommitTs and this was  
an oversight in commit 73c986a.  
  
Also this patch changes pg_resetxlog so that it uses the same sentences  
as pg_controldata does, regarding oldestCommitTs and newestCommitTs,  
for the sake of consistency.  
  
Back-patch to 9.5 where track_commit_timestamp was added.  
  
Euler Taveira  
  

Lower *_freeze_max_age minimum values.

  
commit   : ef4fccd2b6a60bdf89a4300741028218e36461aa    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 24 Sep 2015 14:53:33 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 24 Sep 2015 14:53:33 +0200    

Click here for diff

  
The old minimum values are rather large, making it time consuming to  
test related behaviour. Additionally the current limits, especially for  
multixacts, can be problematic in space-constrained systems. 10000000  
multixacts can contain a lot of members.  
  
Since there's no good reason for the current limits, lower them a good  
bit. Setting them to 0 would be a bad idea, triggering endless vacuums,  
so still retain a limit.  
  
While at it fix autovacuum_multixact_freeze_max_age to refer to  
multixact.c instead of varsup.c.  
  
Reviewed-By: Robert Haas  
Discussion: CA+TgmoYmQPHcrc3GSs7vwvrbTkbcGD9Gik=OztbDGGrovkkEzQ@mail.gmail.com  
Backpatch: back to 9.0 (in parts)  
  

Make ANALYZE compute basic statistics even for types with no “=” operator.

  
commit   : cfb2024ae40e3bbf7a7390bbb053504b757705c2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Sep 2015 18:26:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Sep 2015 18:26:49 -0400    

Click here for diff

  
Previously, ANALYZE simply ignored columns of datatypes that have neither  
a btree nor hash opclass (which means they have no recognized equality  
operator).  Without a notion of equality, we can't identify most-common  
values nor estimate the number of distinct values.  But we can still  
count nulls and compute the average physical column width, and those  
stats might be of value.  Moreover there are some tools out there that  
don't work so well if rows are missing from pg_statistic.  So let's  
add suitable logic for this case.  
  
While this is arguably a bug fix, it also has the potential to change  
query plans, and the gain seems not worth taking a risk of that in  
stable branches.  So back-patch into 9.5 but not further.  
  
Oleksandr Shulgin, rewritten a bit by me.  
  

Docs: fix typo in to_char() example.

  
commit   : fe6d2ab473fdbe4b9408d8da3e97a5091171c743    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Sep 2015 10:40:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Sep 2015 10:40:25 -0400    

Click here for diff

  
Per bug #13631 from KOIZUMI Satoru.  
  

test_decoding: Protect against rare spurious test failures.

  
commit   : 55728ea501de5a153e4dc55c21fb4b6f4d0f44c4    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 22 Sep 2015 15:33:30 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 22 Sep 2015 15:33:30 +0200    

Click here for diff

  
A bunch of tests missed specifying that empty transactions shouldn't be  
displayed. That causes problems when e.g. autovacuum runs in an  
unfortunate moment. The tests in question only run for a very short  
time, making this quite unlikely.  
  
Reported-By: Buildfarm member axolotl  
Backpatch: 9.4, where logical decoding was introduced  
  

Correct value of LW_SHARED_MASK.

  
commit   : 62e503b0c29bbb9e0ac7ebce6990bf3c7c3c9a89    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 22 Sep 2015 11:05:48 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 22 Sep 2015 11:05:48 +0200    

Click here for diff

  
The previous wrong value lead to wrong LOCK_DEBUG output, never showing  
any shared lock holders.  
  
Reported-By: Alexander Korotkov  
Discussion: CAPpHfdsPmWqz9FB0AnxJrwp1=KLF0n=-iB+QvR0Q8GSmpFVdUQ@mail.gmail.com  
Backpatch: 9.5, where the bug was introduced.  
  

doc: Tweak synopsis indentation for consistency

  
commit   : 265728e1b60858f9db8a3e7fb538477a28fc74a3    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Sep 2015 23:31:43 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Sep 2015 23:31:43 -0400    

Click here for diff

  
  

Fix whitespace

  
commit   : a8bb248141c14911b5748bad6130e7de0cbba92e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Sep 2015 13:39:34 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Sep 2015 13:39:34 -0400    

Click here for diff

  
  

Fix possible internal overflow in numeric multiplication.

  
commit   : 3dfffac701cf95e3d9b86f12a3875f9b1b531231    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Sep 2015 12:11:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Sep 2015 12:11:32 -0400    

Click here for diff

  
mul_var() postpones propagating carries until it risks overflow in its  
internal digit array.  However, the logic failed to account for the  
possibility of overflow in the carry propagation step, allowing wrong  
results to be generated in corner cases.  We must slightly reduce the  
when-to-propagate-carries threshold to avoid that.  
  
Discovered and fixed by Dean Rasheed, with small adjustments by me.  
  
This has been wrong since commit d72f6c75038d8d37e64a29a04b911f728044d83b,  
so back-patch to all supported branches.  
  

Remove the SECURITY_ROW_LEVEL_DISABLED security context bit.

  
commit   : bbdb9dfbc3c722b4c811c5cbfa03ce79b7b74824    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 20 Sep 2015 20:47:17 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 20 Sep 2015 20:47:17 -0400    

Click here for diff

  
This commit's parent made superfluous the bit's sole usage.  Referential  
integrity checks have long run as the subject table's owner, and that  
now implies RLS bypass.  Safe use of the bit was tricky, requiring  
strict control over the SQL expressions evaluating therein.  Back-patch  
to 9.5, where the bit was introduced.  
  
Based on a patch by Stephen Frost.  
  

Remove the row_security=force GUC value.

  
commit   : 6dae6edcd88cf3be06acf247c10de925bc065274    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 20 Sep 2015 20:45:41 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 20 Sep 2015 20:45:41 -0400    

Click here for diff

  
Every query of a single ENABLE ROW SECURITY table has two meanings, with  
the row_security GUC selecting between them.  With row_security=force  
available, every function author would have been advised to either set  
the GUC locally or test both meanings.  Non-compliance would have  
threatened reliability and, for SECURITY DEFINER functions, security.  
Authors already face an obligation to account for search_path, and we  
should not mimic that example.  With this change, only BYPASSRLS roles  
need exercise the aforementioned care.  Back-patch to 9.5, where the  
row_security GUC was introduced.  
  
Since this narrows the domain of pg_db_role_setting.setconfig and  
pg_proc.proconfig, one might bump catversion.  A row_security=force  
setting in one of those columns will elicit a clear message, so don't.  
  

Restrict file mode creation mask during tmpfile().

  
commit   : 1be9d65e17abc6215a6faae9bc3f714dd3d040b6    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 20 Sep 2015 20:42:27 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 20 Sep 2015 20:42:27 -0400    

Click here for diff

  
Per Coverity.  Back-patch to 9.0 (all supported versions).  
  
Michael Paquier, reviewed (in earlier versions) by Heikki Linnakangas.  
  

Be more wary about partially-valid LOCALLOCK data in RemoveLocalLock().

  
commit   : 3d3bc2905f2ed6a4858501031c086383be7bcf6a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 Sep 2015 16:48:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 20 Sep 2015 16:48:44 -0400    

Click here for diff

  
RemoveLocalLock() must consider the possibility that LockAcquireExtended()  
failed to palloc the initial space for a locallock's lockOwners array.  
I had evidently meant to cope with this hazard when the code was originally  
written (commit 1785acebf2ed14fd66955e2d9a55d77a025f418d), but missed that  
the pfree needed to be protected with an if-test.  Just to make sure things  
are left in a clean state, reset numLockOwners as well.  
  
Per low-memory testing by Andreas Seltenreich.  Back-patch to all supported  
branches.  
  

Let compiler handle size calculation of bool types.

  
commit   : b46f5ebd9c8f6ec37e27c56749266fc2e362902b    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Thu, 17 Sep 2015 15:41:04 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Thu, 17 Sep 2015 15:41:04 +0200    

Click here for diff

  
Back in the day this did not work, but modern compilers should handle it themselves.  
  

Simplify GETTEXT_FILES list

  
commit   : 866a034c3f9f2b6c3ef23df0f1d9e2e4b7533a3a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 18 Sep 2015 22:40:41 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 18 Sep 2015 22:40:41 -0400    

Click here for diff

  
  

Add missing serial comma

  
commit   : bd313ba8a91a19659bf92014df96f7e58bfdd2fe    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 18 Sep 2015 22:40:10 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 18 Sep 2015 22:40:10 -0400    

Click here for diff

  
  

Cache argument type information in json(b) aggregate functions.

  
commit   : 1e1ae6e0b0c11e6044c0dacd61cb17c8d8bc87f1    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 18 Sep 2015 14:39:39 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 18 Sep 2015 14:39:39 -0400    

Click here for diff

  
These functions have been looking up type info for every row they  
process. Instead of doing that we only look them up the first time  
through and stash the information in the aggregate state object.  
  
Affects json_agg, json_object_agg, jsonb_agg and jsonb_object_agg.  
  
There is plenty more work to do in making these more efficient,  
especially the jsonb functions, but this is a virtually cost free  
improvement that can be done right away.  
  
Backpatch to 9.5 where the jsonb variants were introduced.  
  

Fix low-probability memory leak in regex execution.

  
commit   : a39331fa573fc2bd6f93322ff190da26ddc477b5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Sep 2015 13:55:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Sep 2015 13:55:17 -0400    

Click here for diff

  
After an internal failure in shortest() or longest() while pinning down the  
exact location of a match, find() forgot to free the DFA structure before  
returning.  This is pretty unlikely to occur, since we just successfully  
ran the "search" variant of the DFA; but it could happen, and it would  
result in a session-lifespan memory leak since this code uses malloc()  
directly.  Problem seems to have been aboriginal in Spencer's library,  
so back-patch all the way.  
  
In passing, correct a thinko in a comment I added awhile back about the  
meaning of the "ntree" field.  
  
I happened across these issues while comparing our code to Tcl's version  
of the library.  
  

Order some new options on man pages more sensibly, minor improvements

  
commit   : e8e2999470bd8148e8caf2c86a24b7a6fd4085f1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 17 Sep 2015 20:56:58 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 17 Sep 2015 20:56:58 -0400    

Click here for diff

  
  

Honour TEMP_CONFIG when testing pg_upgrade

  
commit   : 104184d9562365432479691b917ebab45e55e214    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 17 Sep 2015 11:57:00 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 17 Sep 2015 11:57:00 -0400    

Click here for diff

  
This setting contains extra configuration for the temp instance, as used  
in pg_regress' --temp-config flag.  
  
Backpatch to 9.2 where test.sh was introduced.  
  

Fix documentation of regular expression character-entry escapes.

  
commit   : d97bdb082690980a78ca6e2bbe0c6d863caef32f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Sep 2015 14:50:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Sep 2015 14:50:12 -0400    

Click here for diff

  
The docs claimed that \uhhhh would be interpreted as a Unicode value  
regardless of the database encoding, but it's never been implemented  
that way: \uhhhh and \xhhhh actually mean exactly the same thing, namely  
the character that pg_mb2wchar translates to 0xhhhh.  Moreover we were  
falsely dismissive of the usefulness of Unicode code points above FFFF.  
Fix that.  
  
It's been like this for ages, so back-patch to all supported branches.  
  

Don’t use “#” as an abbreviation for “number” in PL/Tcl error messages.

  
commit   : 3047a9b9ef0db126c7f40acde51f78a1bbaa6dd6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Sep 2015 12:08:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Sep 2015 12:08:57 -0400    

Click here for diff

  
Also, rewrite one error message to make it follow our message style  
guidelines better.  
  
Euler Taveira and Tom Lane  
  

Remove no-longer-used T_PrivGrantee node tag.

  
commit   : 5b7aef85139f9f103b5a369261c538769da64c90    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Sep 2015 10:48:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Sep 2015 10:48:11 -0400    

Click here for diff

  
Oversight in commit 31eae6028eca4365e7165f5f33fee1ed0486aee0, which  
replaced PrivGrantee nodes with RoleSpec nodes.  Spotted by Yugo Nagata.  
  

Review program help output for wording and formatting

  
commit   : ea00ff5f1058d2ede0b3ddda47b8713f11a6832a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 16 Sep 2015 00:37:39 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 16 Sep 2015 00:37:39 -0400    

Click here for diff

  
  

Enforce ALL/SELECT policies in RETURNING for RLS

  
commit   : 68b5201128c2d0c8a3a0051ff7c2534b037e1eab    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 15 Sep 2015 15:49:40 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 15 Sep 2015 15:49:40 -0400    

Click here for diff

  
For the UPDATE/DELETE RETURNING case, filter the records which are not  
visible to the user through ALL or SELECT policies from those considered  
for the UPDATE or DELETE.  This is similar to how the GRANT system  
works, which prevents RETURNING unless the caller has SELECT rights on  
the relation.  
  
Per discussion with Robert, Dean, Tom, and Kevin.  
  
Back-patch to 9.5 where RLS was introduced.  
  

RLS refactoring

  
commit   : 23a4b897f731e1a2be7fe989a34016d7a6287148    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 15 Sep 2015 15:49:40 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 15 Sep 2015 15:49:40 -0400    

Click here for diff

  
This refactors rewrite/rowsecurity.c to simplify the handling of the  
default deny case (reducing the number of places where we check for and  
add the default deny policy from three to one) by splitting up the  
retrival of the policies from the application of them.  
  
This also allowed us to do away with the policy_id field.  A policy_name  
field was added for WithCheckOption policies and is used in error  
reporting, when available.  
  
Patch by Dean Rasheed, with various mostly cosmetic changes by me.  
  
Back-patch to 9.5 where RLS was introduced to avoid unnecessary  
differences, since we're still in alpha, per discussion with Robert.  
  

Revert “Fix an O(N^2) problem in foreign key references”.

  
commit   : ed301d6dbe32eaad4f226903d430336e5a0d72aa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Sep 2015 11:08:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 15 Sep 2015 11:08:56 -0400    

Click here for diff

  
Commit 5ddc72887a012f6a8b85707ef27d85c274faf53d does not actually work  
because it will happily blow away ri_constraint_cache entries that are  
in active use in outer call levels.  In any case, it's a very ugly,  
brute-force solution to the problem of limiting the cache size.  
Revert until it can be redesigned.  
  

Add POLICY to COMMENT documentation

  
commit   : 225f539bd00ad58bac41d8d30bd0bd112f8c6a29    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 15 Sep 2015 10:56:29 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 15 Sep 2015 10:56:29 -0400    

Click here for diff

  
COMMENT supports POLICY but the documentation hadn't caught up with  
that fact.  
  
Patch by Charles Clavadetscher  
  
Back-patch to 9.5 where POLICY was added.  
  

  
commit   : fb98859ea0cac3f85041ca052bfdd0b1c8814932    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 15 Sep 2015 23:21:51 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 15 Sep 2015 23:21:51 +0900    

Click here for diff

  
This patch changes the log message which is logged when the server  
successfully renames backup_label file to *.old but fails to rename  
tablespace_map file during the shutdown. Previously the WARNING  
message "online backup mode was not canceled" was logged in that case.  
However this message is confusing because the backup mode is treated  
as canceled whenever backup_label is successfully renamed. So this  
commit makes the server log the message "online backup mode canceled"  
in that case.  
  
Also this commit changes errdetail messages so that they follow the  
error message style guide.  
  
Back-patch to 9.5 where tablespace_map file is introduced.  
  
Original patch by Amit Kapila, heavily modified by me.  
  

Fix the fastpath rule for jsonb_concat with an empty operand.

  
commit   : f243072a9ca3d135745441ab016996a00d183bd2    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 13 Sep 2015 17:06:45 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 13 Sep 2015 17:06:45 -0400    

Click here for diff

  
To prevent perverse results, we now only return the other operand if  
it's not scalar, and if both operands are of the same kind (array or  
object).  
  
Original bug complaint and patch from Oskari Saarenmaa, extended by me  
to cover the cases of different kinds of jsonb.  
  
Backpatch to 9.5 where jsonb_concat was introduced.  
  

  
commit   : 63c0f5b20b7012633bbd85cea039e9d44c054953    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 12 Sep 2015 23:49:11 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 12 Sep 2015 23:49:11 -0400    

Click here for diff

  
The web pages of Andy Dong at Berkeley don't exist anymore, and he is no  
longer there.  
  

Fix typo in create_policy.sgml

  
commit   : dc3573b5d310eb42f478892870a0889a50693530    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sat, 12 Sep 2015 17:17:03 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sat, 12 Sep 2015 17:17:03 -0400    

Click here for diff

  
WTIH -> WITH  
  
Pointed out by Dmitriy Olshevskiy  
  
Backpatch to 9.5 where create_policy.sgml was added.  
  

Update SQL features list

  
commit   : d96c80c1d6f513f0588a19af8a00f4df9eba7837    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 12 Sep 2015 00:07:56 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 12 Sep 2015 00:07:56 -0400    

Click here for diff

  
  

pg_dump, pg_upgrade: allow postgres/template1 tablespace moves

  
commit   : 3243fce882d4a4dc294e331289e873f9246d7c68    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 Sep 2015 15:51:11 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 Sep 2015 15:51:11 -0400    

Click here for diff

  
Modify pg_dump to restore postgres/template1 databases to non-default  
tablespaces by switching out of the database to be moved, then switching  
back.  
  
Also, to fix potentially cases where the old/new tablespaces might not  
match, fix pg_upgrade to process new/old tablespaces separately in all  
cases.  
  
Report by Marti Raudsepp  
  
Patch by Marti Raudsepp, me  
  
Backpatch through 9.0  
  

Add missing ReleaseBuffer call in BRIN revmap code

  
commit   : 25b3ddd1de54563b631484f6d56bd56bef906102    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Sep 2015 15:29:46 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 11 Sep 2015 15:29:46 -0300    

Click here for diff

  
I think this particular branch is actually dead, but the analysis to  
prove that is not trivial, so instead take the weasel way.  
  
Reported by Jinyu Zhang  
Backpatch to 9.5, where BRIN was introduced.  
  

Fix an O(N^2) problem in foreign key references.

  
commit   : 974f910b64511ace9d00a9458577fe439b63ec01    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 11 Sep 2015 13:20:17 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 11 Sep 2015 13:20:17 -0500    

Click here for diff

  
Commit 45ba424f improved foreign key lookups during bulk updates  
when the FK value does not change.  When restoring a schema dump  
from a database with many (say 100,000) foreign keys, this cache  
would grow very big and every ALTER TABLE command was causing an  
InvalidateConstraintCacheCallBack(), which uses a sequential hash  
table scan.  This could cause a severe performance regression in  
restoring a schema dump (including during pg_upgrade).  
  
The patch uses a heuristic method of detecting when the hash table  
should be destroyed and recreated.  
InvalidateConstraintCacheCallBack() adds the current size of the  
hash table to a counter.  When that sum reaches 1,000,000, the hash  
table is flushed.  This fixes the regression without noticeable  
harm to the bulk update use case.  
  
Jan Wieck  
Backpatch to 9.3 where the performance regression was introduced.  
  

Correct description of PageHeaderData layout in documentation

  
commit   : 5b0317b5af58eb6ba42614104644589a0be7c569    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 11 Sep 2015 13:02:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 11 Sep 2015 13:02:15 +0900    

Click here for diff

  
Back-patch to 9.3 where PageHeaderData layout was changed.  
  
Michael Paquier  
  

doc: Spell checking

  
commit   : 683bfbdb99b4168652a7b536b0ccc7217de8ba36    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 10 Sep 2015 21:22:21 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 10 Sep 2015 21:22:21 -0400    

Click here for diff

  
  

Fix setrefs.c comment properly.

  
commit   : edebc04dbd564fd738df1f1ca4f2c05c5cad123d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2015 10:23:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2015 10:23:56 -0400    

Click here for diff

  
The "typo" alleged in commit 1e460d4bd was actually a comment that was  
correct when written, but I missed updating it in commit b5282aa89.  
Use a slightly less specific (and hopefully more future-proof) description  
of what is collected.  Back-patch to 9.2 where that commit appeared, and  
revert the comment to its then-entirely-correct state before that.  
  

Fix typo in setrefs.c

  
commit   : 9adaccab2a9e44cf53d2d5c2d3b780ac10e10a5f    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Thu, 10 Sep 2015 09:22:11 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Thu, 10 Sep 2015 09:22:11 -0400    

Click here for diff

  
We're adding OIDs, not TIDs, to invalItems.  
  
Pointed out by Etsuro Fujita.  
  
Back-patch to all supported branches.  
  

Fix minor bug in regexp makesearch() function.

  
commit   : d76113dda77417d176e299b167e95db0266986d5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Sep 2015 20:14:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 9 Sep 2015 20:14:58 -0400    

Click here for diff

  
The list-wrangling here was done wrong, allowing the same state to get  
put into the list twice.  The following loop then would clone it twice.  
The second clone would wind up with no inarcs, so that there was no  
observable misbehavior AFAICT, but a useless state in the finished NFA  
isn't an especially good thing.  
  

Remove files signaling a standby promotion request at postmaster startup

  
commit   : 65f37b3e9b0aea59cc98a2e23f45bb8fb6a56395    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 9 Sep 2015 22:51:44 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 9 Sep 2015 22:51:44 +0900    

Click here for diff

  
This commit makes postmaster forcibly remove the files signaling  
a standby promotion request. Otherwise, the existence of those files  
can trigger a promotion too early, whether a user wants that or not.  
  
This removal of files is usually unnecessary because they can exist  
only during a few moments during a standby promotion. However  
there is a race condition: if pg_ctl promote is executed and creates  
the files during a promotion, the files can stay around even after  
the server is brought up to new master. Then, if new standby starts  
by using the backup taken from that master, the files can exist  
at the server startup and should be removed in order to avoid  
an unexpected promotion.  
  
Back-patch to 9.1 where promote signal file was introduced.  
  
Problem reported by Feike Steenbergen.  
Original patch by Michael Paquier, modified by me.  
  
Discussion: 20150528100705.4686.91426@wrigleys.postgresql.org  
  

Lock all relations referred to in updatable views

  
commit   : 9801bae217e9d3f72e2d1f3dd780bf0bf9365dae    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 8 Sep 2015 17:02:53 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 8 Sep 2015 17:02:53 -0400    

Click here for diff

  
Even views considered "simple" enough to be automatically updatable may  
have mulitple relations involved (eg: in a where clause).  We need to  
make sure and lock those relations when rewriting the query.  
  
Back-patch to 9.3 where updatable views were added.  
  
Pointed out by Andres, patch thanks to Dean Rasheed.  
  

Add gin_fuzzy_search_limit to postgresql.conf.sample.

  
commit   : 97b7b9560f3dbe1c48dfb4630f50444eb7e8adc8    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 9 Sep 2015 02:25:50 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 9 Sep 2015 02:25:50 +0900    

Click here for diff

  
This was forgotten in 8a3631f (commit that originally added the parameter)  
and 0ca9907 (commit that added the documentation later that year).  
  
Back-patch to all supported versions.  
  

Fix error message wording in previous sslinfo commit

  
commit   : bbbe5a9d8a35f0f7a983488d35dd86006229ea0c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 8 Sep 2015 11:10:20 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 8 Sep 2015 11:10:20 -0300    

Click here for diff

  
  

In the pg_rewind test suite, receive WAL fully before promoting.

  
commit   : 58feb1a94a5ea0ae3395b1818ba76ab68485a7a4    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 7 Sep 2015 19:01:00 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 7 Sep 2015 19:01:00 -0400    

Click here for diff

  
If a transaction never reaches the standby, later tests find unexpected  
cluster state.  A "tail-copy: query result matches" test failure has  
been the usual symptom.  Among the buildfarm members having run this  
test suite, most have exhibited that symptom at least once.  Back-patch  
to 9.5, where pg_rewind was introduced.  
  
Michael Paquier, reported by Christoph Berg.  
  

Add more sanity checks in contrib/sslinfo

  
commit   : 73d2d2e6a1721f94e4d01d7502bf99452008170e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 7 Sep 2015 19:18:29 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 7 Sep 2015 19:18:29 -0300    

Click here for diff

  
We were missing a few return checks on OpenSSL calls.  Should be pretty  
harmless, since we haven't seen any user reports about problems, and  
this is not a high-traffic module anyway; still, a bug is a bug, so  
backpatch this all the way back to 9.0.  
  
Author: Michael Paquier, while reviewing another sslinfo patch  
  

Change type of DOW/DOY to UNITS

  
commit   : a1242402854178eded9bd4f2b8cd8ef46d1e9864    
  
author   : Greg Stark <stark@mit.edu>    
date     : Mon, 7 Sep 2015 13:35:09 +0100    
  
committer: Greg Stark <stark@mit.edu>    
date     : Mon, 7 Sep 2015 13:35:09 +0100    

Click here for diff

  
  

Make GIN’s cleanup pending list process interruptable

  
commit   : d592a8745fd0320fd5e691b59bf5a95d9834a286    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 7 Sep 2015 17:17:15 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 7 Sep 2015 17:17:15 +0300    

Click here for diff

  
Cleanup process could be called by ordinary insert/update and could take a lot  
of time. Add vacuum_delay_point() to make this process interruptable. Under  
vacuum this call will also throttle a vacuum process to decrease system load,  
called from insert/update it will not throttle, and that reduces a latency.  
  
Backpatch for all supported branches.  
  
Jeff Janes <jeff.janes@gmail.com>  
  

Update site address of Snowball project

  
commit   : 552723a3bf6d3caefafaa0afe9afcde31ccdb481    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 7 Sep 2015 15:21:34 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 7 Sep 2015 15:21:34 +0300    

Click here for diff

  
  

Move DTK_ISODOW DTK_DOW and DTK_DOY to be type UNITS rather than RESERV. RESERV is meant for tokens like “now” and having them in that category throws errors like these when used as an input date:

  
commit   : c11100d0fa46b5a0c3c796b8d538060ce7d14ac9    
  
author   : Greg Stark <stark@mit.edu>    
date     : Sun, 6 Sep 2015 02:04:37 +0100    
  
committer: Greg Stark <stark@mit.edu>    
date     : Sun, 6 Sep 2015 02:04:37 +0100    

Click here for diff

  
stark=# SELECT 'doy'::timestamptz;  
ERROR:  unexpected dtype 33 while parsing timestamptz "doy"  
LINE 1: SELECT 'doy'::timestamptz;  
               ^  
stark=# SELECT 'dow'::timestamptz;  
ERROR:  unexpected dtype 32 while parsing timestamptz "dow"  
LINE 1: SELECT 'dow'::timestamptz;  
               ^  
  
Found by LLVM's Libfuzzer  
  

  
commit   : 5692b4acb26fea7c834c9ad0712cce2ec251d512    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Sep 2015 16:15:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Sep 2015 16:15:38 -0400    

Click here for diff

  
This has been broken since 9.3 (commit 82b1b213cad3a69c to be exact),  
which suggests that nobody is any longer using a Windows build system that  
doesn't provide a symlink emulation.  Still, it's wrong on its own terms,  
so repair.  
  
YUriy Zhuravlev  
  

Fix misc typos.

  
commit   : 25600c42e078e0d10eedf2794a0c7d02178232e0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 5 Sep 2015 11:35:49 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 5 Sep 2015 11:35:49 +0300    

Click here for diff

  
Oskari Saarenmaa. Backpatch to stable branches where applicable.  
  

Fix brin index summarizing while vacuuming.

  
commit   : b1cbc8529d076b71c9c2f8403139f7235072a357    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sat, 5 Sep 2015 09:19:25 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sat, 5 Sep 2015 09:19:25 +0900    

Click here for diff

  
If the number of heap blocks is not multiples of pages per range, the  
summarizing produces wrong summary information for the last brin index  
tuple while vacuuming.  
  
Problem reported by Tatsuo Ishii and fixed by Amit Langote.  
  
Discussion at "[HACKERS] BRIN INDEX value (message id :20150903.174935.1946402199422994347.t-ishii@sraoss.co.jp)  
Backpatched to 9.5 in which brin index was added.  
  

Fix subtransaction cleanup after an outer-subtransaction portal fails.

  
commit   : a2538da89f664671d1790cb8dbb4b94849ed923c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2015 13:36:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2015 13:36:49 -0400    

Click here for diff

  
Formerly, we treated only portals created in the current subtransaction as  
having failed during subtransaction abort.  However, if the error occurred  
while running a portal created in an outer subtransaction (ie, a cursor  
declared before the last savepoint), that has to be considered broken too.  
  
To allow reliable detection of which ones those are, add a bookkeeping  
field to struct Portal that tracks the innermost subtransaction in which  
each portal has actually been executed.  (Without this, we'd end up  
failing portals containing functions that had called the subtransaction,  
thereby breaking plpgsql exception blocks completely.)  
  
In addition, when we fail an outer-subtransaction Portal, transfer its  
resources into the subtransaction's resource owner, so that they're  
released early in cleanup of the subxact.  This fixes a problem reported by  
Jim Nasby in which a function executed in an outer-subtransaction cursor  
could cause an Assert failure or crash by referencing a relation created  
within the inner subtransaction.  
  
The proximate cause of the Assert failure is that AtEOSubXact_RelationCache  
assumed it could blow away a relcache entry without first checking that the  
entry had zero refcount.  That was a bad idea on its own terms, so add such  
a check there, and to the similar coding in AtEOXact_RelationCache.  This  
provides an independent safety measure in case there are still ways to  
provoke the situation despite the Portal-level changes.  
  
This has been broken since subtransactions were invented, so back-patch  
to all supported branches.  
  
Tom Lane and Michael Paquier  
  

Document that max_worker_processes must be high enough in standby.

  
commit   : cb9cc382b41de4fab2d718f0f8de3441c85aa7f7    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Sep 2015 22:30:16 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 3 Sep 2015 22:30:16 +0900    

Click here for diff

  
The setting values of some parameters including max_worker_processes  
must be equal to or higher than the values on the master. However,  
previously max_worker_processes was not listed as such parameter  
in the document. So this commit adds it to that list.  
  
Back-patch to 9.4 where max_worker_processes was added.  
  

Disable fsync throughout TAP test suites.

  
commit   : 8d60549d6d39fbc1501f11a31f007c36975891e8    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 3 Sep 2015 00:29:11 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 3 Sep 2015 00:29:11 -0400    

Click here for diff

  
Most suites already did so via start_test_server(), but the pg_rewind,  
pg_ctl and pg_controldata suites ran a postmaster or initdb with fsync  
enabled.  This halves the pg_rewind suite's runtime on buildfarm member  
tern.  It makes tern and that machine's other buildfarm members less  
vulnerable to noise failures from postmaster startup overrunning the 60s  
pg_ctl timeout.  Back-patch to 9.5, where pg_rewind was introduced.  
  

Document that PL/Python now returns floats using repr() not str().

  
commit   : e2e78acccaa94e7d64dc2bc0b124cfcf23520918    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Sep 2015 19:25:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Sep 2015 19:25:58 -0400    

Click here for diff

  
Commit 1ce7a57ca neglected to update the user-facing documentation,  
which described the old behavior precisely.  
  

pg_upgrade docs: clarify rsync and move verification step

  
commit   : 813e08123bd9eb7d7eb7bc6eac43b74f5a9a1ef8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 1 Sep 2015 16:42:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 1 Sep 2015 16:42:43 -0400    

Click here for diff

  
These are adjustments based on someone using the new standby upgrade  
steps.  
  
Report by Andy Colson  
  
Backpatch through 9.5  
  

Allow notifications to bgworkers without database connections.

  
commit   : b8a439b650c4791575720dec847be61467a710a4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 1 Sep 2015 15:30:19 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 1 Sep 2015 15:30:19 -0400    

Click here for diff

  
Previously, if one background worker registered another background  
worker and set bgw_notify_pid while for the second background worker,  
it would not receive notifications from the postmaster unless, at the  
time the "parent" was registered, BGWORKER_BACKEND_DATABASE_CONNECTION  
was set.  
  
To fix, instead instead of including only those background workers that  
requested database connections in the postmater's BackendList, include  
them all.  There doesn't seem to be any reason not do this, and indeed  
it removes a significant amount of duplicated code.  The other option  
is to make PostmasterMarkPIDForWorkerNotify look at BackgroundWorkerList  
in addition to BackendList, but that adds more code duplication instead  
of getting rid of it.  
  
Patch by me.  Review and testing by Ashutosh Bapat.  
  

Use in pg_upgrade’s procedure

  
commit   : c1564b3928e527c799bd41c2c80c4d6851bb5e15    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 1 Sep 2015 14:58:28 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 1 Sep 2015 14:58:28 -0300    

Click here for diff

  
For clarity, so that the substeps are not numbered identically to the  
outer procedure's steps.  
  
Per report from Andy Colson in  
http://www.postgresql.org/message-id/55D789B5.7040308@squeakycode.net  
  

docs: remove outdated note about unique indexes

  
commit   : 06502185d8352258560b7fad82571d159dff8658    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2015 17:05:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2015 17:05:22 -0400    

Click here for diff

  
Patch by Josh Kupershmidt  
  
Backpatch through 9.5  
  

psql: print longtable as a possible \pset option

  
commit   : bda58e98d535762b46a9d6315f4e49d9c93e81d8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2015 12:24:16 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 31 Aug 2015 12:24:16 -0400    

Click here for diff

  
For some reason this message was not updated when the longtable option  
was added.  
  
Backpatch through 9.3  
  

Small grammar fix

  
commit   : bafeb010b2500b31d303f4c2879cec54481dafdd    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 31 Aug 2015 14:07:17 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 31 Aug 2015 14:07:17 +0200    

Click here for diff

  
Josh Kupershmidt  
  

Fix sepgsql regression tests.

  
commit   : 1c419abffba7a105948495f498780f1cf9ab7fc4    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sun, 30 Aug 2015 11:09:19 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sun, 30 Aug 2015 11:09:19 -0700    

Click here for diff

  
The regression tests for sepgsql were broken by changes in the  
base distro as-shipped policies. Specifically, definition of  
unconfined_t in the system default policy was changed to bypass  
multi-category rules, which the regression test depended on.  
Fix that by defining a custom privileged domain  
(sepgsql_regtest_superuser_t) and using it instead of system's  
unconfined_t domain. The new sepgsql_regtest_superuser_t domain  
performs almost like the current unconfined_t, but restricted by  
multi-category policy as the traditional unconfined_t was.  
  
The custom policy module is a self defined domain, and so should not  
be affected by related future system policy changes. However, it still  
uses the unconfined_u:unconfined_r pair for selinux-user and role.  
Those definitions have not been changed for several years and seem  
less risky to rely on than the unconfined_t domain. Additionally, if  
we define custom user/role, they would need to be manually defined  
at the operating system level, adding more complexity to an already  
non-standard and complex regression test.  
  
Back-patch to 9.3. The regression tests will need more work before  
working correctly on 9.2. Starting with 9.2, sepgsql has had dependencies  
on libselinux versions that are only available on newer distros with  
the changed set of policies (e.g. RHEL 7.x). On 9.1 sepgsql works  
fine with the older distros with original policy set (e.g. RHEL 6.x),  
and on which the existing regression tests work fine. We might want  
eventually change 9.1 sepgsql regression tests to be more independent  
from the underlying OS policies, however more work will be needed to  
make that happen and it is not clear that it is worth the effort.  
  
Kohei KaiGai with review by Adam Brightwell and me, commentary by  
Stephen, Alvaro, Tom, Robert, and others.  
  

Fix s_lock.h PPC assembly code to be compatible with native AIX assembler.

  
commit   : ffbc387bfc57b47ec7f120582cfff54f6434f3d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Aug 2015 16:09:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 29 Aug 2015 16:09:25 -0400    

Click here for diff

  
On recent AIX it's necessary to configure gcc to use the native assembler  
(because the GNU assembler hasn't been updated to handle AIX 6+).  This  
caused PG builds to fail with assembler syntax errors, because we'd try  
to compile s_lock.h's gcc asm fragment for PPC, and that assembly code  
relied on GNU-style local labels.  We can't substitute normal labels  
because it would fail in any file containing more than one inlined use of  
tas().  Fortunately, that code is stable enough, and the PPC ISA is simple  
enough, that it doesn't seem like too much of a maintenance burden to just  
hand-code the branch offsets, removing the need for any labels.  
  
Note that the AIX assembler only accepts "$" for the location counter  
pseudo-symbol.  The usual GNU convention is "."; but it appears that all  
versions of gas for PPC also accept "$", so in theory this patch will not  
break any other PPC platforms.  
  
This has been reported by a few people, but Steve Underwood gets the credit  
for being the first to pursue the problem far enough to understand why it  
was failing.  Thanks also to Noah Misch for additional testing.  
  

Ensure locks are acquired on RLS-added relations

  
commit   : d03f3314b35cc4ac2be832cf63ae67a69ee4d93c    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 28 Aug 2015 11:39:43 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 28 Aug 2015 11:39:43 -0400    

Click here for diff

  
During fireRIRrules(), get_row_security_policies can add to  
securityQuals and withCheckOptions.  Make sure to lock any relations  
added at that point and before firing RIR rules on those expressions.  
  
Back-patch to 9.5 where RLS was added.  
  

Simplify Perl chmod calls

  
commit   : aed688eb730f0e46bc7950589d7577db6bb2d724    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 25 Aug 2015 09:58:49 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 25 Aug 2015 09:58:49 -0400    

Click here for diff

  
The Perl chmod function already takes multiple file arguments, so we  
don't need a separate looping function.  
  

  
commit   : 440fc48cac7f450bb71d1f06f0d1326c63e3e42f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 27 Aug 2015 13:43:10 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 27 Aug 2015 13:43:10 -0400    

Click here for diff

  
This makes the parameter names match the documented prototype names.  
  
Report by Erwin Brandstetter  
  
Backpatch through 9.0  
  

release notes: abbreviated key speedup only for varchar/text

  
commit   : ce56a649cf0b9aba41d68481895b3da0a82981d4    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 26 Aug 2015 14:46:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 26 Aug 2015 14:46:48 -0400    

Click here for diff

  
Report by Peter Geoghegan  
  
Backpatch through 9.5  
  

release notes: backpatch removal of xpath item to 9.5 tree

  
commit   : aa9630cce04d3512e1ca5131013a0a669b39fcac    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 26 Aug 2015 14:40:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 26 Aug 2015 14:40:53 -0400    

Click here for diff

  
Backpatch a93545e13f832d457e00420d44ccce1f88f899d4 to the 9.5 tree  
  
Backpatch to 9.5 only  
  

9.5 release notes: mention lack of char() sort improvements

  
commit   : 63c6522dae38e3cf6d1af795db441686e716b331    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 26 Aug 2015 10:33:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 26 Aug 2015 10:33:02 -0400    

Click here for diff

  
Report by Peter Geoghegan  
  
Backpatch through 9.5  
  

Reestablish alignment of pg_controldata output.

  
commit   : bff62dfb873be1f2469402c6e22cfb93b639f9cd    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Tue, 25 Aug 2015 18:46:02 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Tue, 25 Aug 2015 18:46:02 -0700    

Click here for diff

  
Until 9.4, pg_controldata output was all aligned. At some point  
during 9.5 development, a new item was added, namely  
"Current track_commit_timestamp setting:" which is two characters  
too long to be aligned with the rest of the output. Fix this by  
removing the noise word "Current" and adding the requisite number  
of padding spaces. Since the six preceding items are also similar  
in nature, remove "Current" and pad those as well in order to  
maintain overall consistency. Backpatch to 9.5 where new offending  
item was added.  
  

Docs: be explicit about datatype matching for lead/lag functions.

  
commit   : 7c0c4d07e777957a5fad54e81b4f42f420031060    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Aug 2015 19:11:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Aug 2015 19:11:17 -0400    

Click here for diff

  
The default argument, if given, has to be of exactly the same datatype  
as the first argument; but this was not stated in so many words, and  
the error message you get about it might not lead your thought in the  
right direction.  Per bug #13587 from Robert McGehee.  
  
A quick scan says that these are the only two built-in functions with two  
anyelement arguments and no other polymorphic arguments.  There are plenty  
of cases of, eg, anyarray and anyelement, but those seem less likely to  
confuse.  For instance this doesn't seem terribly hard to figure out:  
"function array_remove(integer[], numeric) does not exist".  So I've  
contented myself with fixing these two cases.  
  

Fix potential platform dependence in gist regression test.

  
commit   : b8c91352a2e168e1c24cc33862a0d95f13fd0957    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Aug 2015 11:43:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Aug 2015 11:43:37 -0400    

Click here for diff

  
The results of the KNN-search test cases were indeterminate, as they asked  
the system to sort pairs of points that are exactly equidistant from the  
query reference point.  It's a bit surprising that we've seen no  
platform-specific failures from this in the buildfarm.  Perhaps IEEE-float  
math is well enough standardized that no such failures will ever occur on  
supported platforms ... but since this entire regression test has yet to be  
shipped in any non-alpha release, that seems like an unduly optimistic  
assumption.  Tweak the queries so that the correct output is uniquely  
defined.  
  
(The other queries in this test are also underdetermined; but it looks like  
they are regurgitating index rows in insertion order, so for the moment  
assume that that behavior is stable enough.)  
  
Per Greg Stark's experiments with VAX.  Back-patch to 9.5 where this test  
script was introduced.  
  

Avoid use of float arithmetic in bipartite_match.c.

  
commit   : 4022f94c350f96fc5feff0503d3e2f2f6f9086cc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Aug 2015 13:02:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 23 Aug 2015 13:02:13 -0400    

Click here for diff

  
Since the distances used in this algorithm are small integers (not more  
than the size of the U set, in fact), there is no good reason to use float  
arithmetic for them.  Use short ints instead: they're smaller, faster, and  
require no special portability assumptions.  
  
Per testing by Greg Stark, which disclosed that the code got into an  
infinite loop on VAX for lack of IEEE-style float infinities.  We don't  
really care all that much whether Postgres can run on a VAX anymore,  
but there seems sufficient reason to change this code anyway.  
  
In passing, make a few other small adjustments to make the code match  
usual Postgres coding style a bit better.  
  

Fix typo in C comment.

  
commit   : 57823244ad087a2dc807a6e60fefce26f81bd5dc    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 23 Aug 2015 10:41:08 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 23 Aug 2015 10:41:08 -0500    

Click here for diff

  
Merlin Moncure  
Backpatch to 9.5, where the misspelling was introduced  
  

Improve whitespace

  
commit   : 27347c4841ca880af61f1b767f24c6e248686c99    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 22 Aug 2015 21:41:29 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 22 Aug 2015 21:41:29 -0400    

Click here for diff

  
  

Improve spelling

  
commit   : 63b04a37626ab5982c14438e408e35d88328ad87    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 22 Aug 2015 21:41:13 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 22 Aug 2015 21:41:13 -0400    

Click here for diff

  
  

Avoid O(N^2) behavior when enlarging SPI tuple table in spi_printtup().

  
commit   : 68a14ca74be03ab189b83c2bbf0b68c5d1daba44    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Aug 2015 20:32:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Aug 2015 20:32:11 -0400    

Click here for diff

  
For no obvious reason, spi_printtup() was coded to enlarge the tuple  
pointer table by just 256 slots at a time, rather than doubling the size at  
each reallocation, as is our usual habit.  For very large SPI results, this  
makes for O(N^2) time spent in repalloc(), which of course soon comes to  
dominate the runtime.  Use the standard doubling approach instead.  
  
This is a longstanding performance bug, so back-patch to all active  
branches.  
  
Neil Conway  
  

Clean up roles from roleattributes test

  
commit   : 93fcb4ae3e4b20e8562f0a8cab3a3a486ad84e76    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 21 Aug 2015 15:51:29 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 21 Aug 2015 15:51:29 -0400    

Click here for diff

  
Having the roles remain after the test ends up causing repeated 'make  
installcheck' runs to fail and may be risky from a security perspective  
also, so remove them at the end of the test.  
  

Do not allow *timestamp to be passed as NULL

  
commit   : d6968e625770d021c8db15094ea732b40be2c5aa    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 21 Aug 2015 14:36:54 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 21 Aug 2015 14:36:54 -0300    

Click here for diff

  
The code had bugs that would cause crashes if NULL was passed as that  
argument (originally intended to mean not to bother returning its  
value), and after inspection it turns out that nothing seems interested  
in the case that *ts is NULL anyway.  Therefore, remove the partial  
checks intended to support that case.  
  
Author: Michael Paquier  
though I didn't include a proposed Assert.  
  
Backpatch to 9.5.  
  

Fix plpython crash when returning string representation of a RECORD result.

  
commit   : 19446280fce0b9aebef40c6b5390cf1170c5c770    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Aug 2015 12:21:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Aug 2015 12:21:37 -0400    

Click here for diff

  
PLyString_ToComposite() blithely overwrote proc->result.out.d, even though  
for a composite result type the other union variant proc->result.out.r is  
the one that should be valid.  This could result in a crash if out.r had  
in fact been filled in (proc->result.is_rowtype == 1) and then somebody  
later attempted to use that data; as per bug #13579 from Paweł Michalak.  
  
Just to add insult to injury, it didn't work for RECORD results anyway,  
because record_in() would refuse the case.  
  
Fix by doing the I/O function lookup in a local PLyTypeInfo variable,  
as we were doing already in PLyObject_ToComposite().  This is not a great  
technique because any fn_extra data allocated by the input function will  
be leaked permanently (thanks to using TopMemoryContext as fn_mcxt).  
But that's a pre-existing issue that is much less serious than a crash,  
so leave it to be fixed separately.  
  
This bug would be a potential security issue, except that plpython is  
only available to superusers and the crash requires coding the function  
in a way that didn't work before today's patches.  
  
Add regression test cases covering all the supported methods of converting  
composite results.  
  
Back-patch to 9.1 where the faulty coding was introduced.  
  

Allow record_in() and record_recv() to work for transient record types.

  
commit   : 20bef3fe2ed180c64a5140b8ebeba439afd1bb95    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Aug 2015 11:19:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 21 Aug 2015 11:19:33 -0400    

Click here for diff

  
If we have the typmod that identifies a registered record type, there's no  
reason that record_in() should refuse to perform input conversion for it.  
Now, in direct SQL usage, record_in() will always be passed typmod = -1  
with type OID RECORDOID, because no typmodin exists for type RECORD, so the  
case can't arise.  However, some InputFunctionCall users such as PLs may be  
able to supply the right typmod, so we should allow this to support them.  
  
Note: the previous coding and comment here predate commit 59c016aa9f490b53.  
There has been no case since 8.1 in which the passed type OID wouldn't be  
valid; and if it weren't, this error message wouldn't be apropos anyway.  
Better to let lookup_rowtype_tupdesc complain about it.  
  
Back-patch to 9.1, as this is necessary for my upcoming plpython fix.  
I'm committing it separately just to make it a bit more visible in the  
commit history.  
  

Rename ‘cmd’ to ‘cmd_name’ in CreatePolicyStmt

  
commit   : 49f9a2831b8c5c8941eec9baa5d44b471971704e    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 21 Aug 2015 08:22:29 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 21 Aug 2015 08:22:29 -0400    

Click here for diff

  
To avoid confusion, rename CreatePolicyStmt's 'cmd' to 'cmd_name',  
parse_policy_command's 'cmd' to 'polcmd', and AlterPolicy's 'cmd_datum'  
to 'polcmd_datum', per discussion with Noah and as a follow-up to his  
correction of copynodes/equalnodes handling of the CreatePolicyStmt  
'cmd' field.  
  
Back-patch to 9.5 where the CreatePolicyStmt was introduced, as we  
are still only in alpha.  
  

In AlterRole, make bypassrls an int

  
commit   : 0070fd8d3c1c8a733c041bfcedd41e38cee0a963    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 21 Aug 2015 08:22:29 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 21 Aug 2015 08:22:29 -0400    

Click here for diff

  
When reworking bypassrls in AlterRole to operate the same way the other  
attribute handling is done, I missed that the variable was incorrectly a  
bool rather than an int.  This meant that on platforms with an unsigned  
char, we could end up with incorrect behavior during ALTER ROLE.  
  
Pointed out by Andres thanks to tests he did changing our bool to be the  
one from stdbool.h which showed this and a number of other issues.  
  
Add regression tests to test CREATE/ALTER role for the various role  
attributes.  Arrange to leave roles behind for testing pg_dumpall, but  
none which have the LOGIN attribute.  
  
Back-patch to 9.5 where the AlterRole bug exists.  
  

doc: Whitespace and formatting fixes

  
commit   : 338a8622560f45062958dd290abed66c6004e0ef    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 20 Aug 2015 22:34:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 20 Aug 2015 22:34:35 -0400    

Click here for diff

  
  

Update config.guess and config.sub

  
commit   : f17e2471734c73da8079451c17a2212884979168    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 19 Aug 2015 11:45:52 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 19 Aug 2015 11:45:52 -0400    

Click here for diff

  
  

Fix bug in calculations of hash join buckets.

  
commit   : 24bf2ee22233244eb9e2c71de754b1c71258d004    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 19 Aug 2015 08:31:13 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 19 Aug 2015 08:31:13 -0500    

Click here for diff

  
Commit 8cce08f168481c5fc5be4e7e29b968e314f1b41e used a left-shift  
on a literal of 1 that could (in large allocations) be shifted by  
31 or more bits.  This was assigned to a local variable that was  
already declared to be a long to protect against overruns of int,  
but the literal in this shift needs to be declared long to allow it  
to work correctly in some compilers.  
  
Backpatch to 9.5, where the bug was introduced.  
  
Report and patch by KaiGai Kohei, slighly modified based on  
discussion.  
  

Fix a few bogus statement type names in plpgsql error messages.

  
commit   : 4c3754ffe0f5f85cdecd01d7c1ab55df94559302    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Aug 2015 19:22:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Aug 2015 19:22:37 -0400    

Click here for diff

  
plpgsql's error location context messages ("PL/pgSQL function fn-name line  
line-no at stmt-type") would misreport a CONTINUE statement as being an  
EXIT, and misreport a MOVE statement as being a FETCH.  These are clear  
bugs that have been there a long time, so back-patch to all supported  
branches.  
  
In addition, in 9.5 and HEAD, change the description of EXECUTE from  
"EXECUTE statement" to just plain EXECUTE; there seems no good reason why  
this statement type should be described differently from others that have  
a well-defined head keyword.  And distinguish GET STACKED DIAGNOSTICS from  
plain GET DIAGNOSTICS.  These are a bit more of a judgment call, and also  
affect existing regression-test outputs, so I did not back-patch into  
stable branches.  
  
Pavel Stehule and Tom Lane  
  

psql: Make EXECUTE PROCEDURE tab completion a bit narrower.

  
commit   : f25087d26aa9c63ce90cd8e87131b6dbe943ba86    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 18 Aug 2015 12:49:04 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 18 Aug 2015 12:49:04 -0400    

Click here for diff

  
If the user has typed GRANT EXECUTE, the correct completion is "ON",  
not "PROCEDURE".  
  
Daniel Verite  
  

Improve configure test for the sse4.2 crc instruction.

  
commit   : 2c5c11ae9e0c5f4605fb9cdd2e8bd94fe0a06d95    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 17 Aug 2015 11:15:46 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 17 Aug 2015 11:15:46 +0200    

Click here for diff

  
With optimizations enabled at least one compiler, clang 3.7, optimized  
away the crc intrinsics knowing that the result went on unused and has  
no side effects. That can trigger errors in code generation when the  
intrinsic is used, as we chose to use the intrinsics without any  
additional compiler flag. Return the computed value to prevent that.  
  
With some more pedantic warning flags (-Wold-style-definition) the  
configure test failed to recognize the existence of _mm_crc32_u*  
intrinsics due to an independent warning in the test because the test  
turned on -Werror, but that's not actually needed here.  
  
Discussion: 20150814092039.GH4955@awork2.anarazel.de  
Backpatch: 9.5, where the use of crc intrinsics was integrated.  
  

Add docs about postgres_fdw’s setting of search_path and other GUCs.

  
commit   : 9a18a2bfb9f93e4a1aa405e752608746e04619f2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Aug 2015 14:31:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Aug 2015 14:31:04 -0400    

Click here for diff

  
This behavior wasn't documented, but it should be because it's user-visible  
in triggers and other functions executed on the remote server.  
Per question from Adam Fuchs.  
  
Back-patch to 9.3 where postgres_fdw was added.  
  

Improve documentation about MVCC-unsafe utility commands.

  
commit   : 656363d83970195e875c5c2153ef097e112b859f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Aug 2015 13:30:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Aug 2015 13:30:16 -0400    

Click here for diff

  
The table-rewriting forms of ALTER TABLE are MVCC-unsafe, in much the same  
way as TRUNCATE, because they replace all rows of the table with newly-made  
rows with a new xmin.  (Ideally, concurrent transactions with old snapshots  
would continue to see the old table contents, but the data is not there  
anymore --- and if it were there, it would be inconsistent with the table's  
updated rowtype, so there would be serious implementation problems to fix.)  
This was nowhere documented though, and the problem was only documented for  
TRUNCATE in a note in the TRUNCATE reference page.  Create a new "Caveats"  
section in the MVCC chapter that can be home to this and other limitations  
on serializable consistency.  
  
In passing, fix a mistaken statement that VACUUM and CLUSTER would reclaim  
space occupied by a dropped column.  They don't reconstruct existing tuples  
so they couldn't do that.  
  
Back-patch to all supported branches.  
  

Repair unsafe use of shared typecast-lookup table in plpgsql DO blocks.

  
commit   : 1f6a7eba466d0cb31cd2f374603799935fcb9df8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Aug 2015 12:00:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Aug 2015 12:00:36 -0400    

Click here for diff

  
DO blocks use private simple_eval_estates to avoid intra-transaction memory  
leakage, cf commit c7b849a89.  I had forgotten about that while writing  
commit 0fc94a5ba, but it means that expression execution trees created  
within a DO block disappear immediately on exiting the DO block, and hence  
can't safely be linked into plpgsql's session-wide cast hash table.  
To fix, give a DO block a private cast hash table to go with its private  
simple_eval_estate.  This is less efficient than one could wish, since  
DO blocks can no longer share any cast lookup work with other plpgsql  
execution, but it shouldn't be too bad; in any case it's no worse than  
what happened in DO blocks before commit 0fc94a5ba.  
  
Per bug #13571 from Feike Steenbergen.  Preliminary analysis by  
Oleksandr Shulgin.  
  

Correct type of waitMode variable in ExecInsertIndexTuples().

  
commit   : 6942663d1bde1e6d6e6da38710d3e6aade900e63    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 15 Aug 2015 17:02:47 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 15 Aug 2015 17:02:47 +0200    

Click here for diff

  
It was a bool, even though it should be CEOUC_WAIT_MODE. That's unlikely  
to have a negative effect with the current definition of bool (char),  
but it's definitely wrong.  
  
Discussion: 20150812084351.GD8470@awork2.anarazel.de  
Backpatch: 9.5, where ON CONFLICT was merged  
  

vacuumdb: Don’t assign negative values to a boolean.

  
commit   : 32951f9aa9acfd4b6318f6daf39c3d1c10a264ba    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 12 Aug 2015 16:49:36 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 12 Aug 2015 16:49:36 +0200    

Click here for diff

  
Since a17923204736 (vacuumdb: enable parallel mode) -1 has been assigned  
to a boolean. That can, justifiedly, trigger compiler warnings. There's  
also no need for ternary logic, result was only ever set to 0 or -1. So  
don't.  
  
Discussion: 20150812084351.GD8470@awork2.anarazel.de  
Backpatch: 9.5  
  

Don’t use ‘bool’ as a struct member name in help_config.c.

  
commit   : d19c1b0b24d53f41222bf808dc6b40404b2954a1    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 12 Aug 2015 16:02:20 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 12 Aug 2015 16:02:20 +0200    

Click here for diff

  
Doing so doesn't work if bool is a macro rather than a typedef.  
  
Although c.h spends some effort to support configurations where bool is  
a preexisting macro, help_config.c has existed this way since  
2003 (b700a6), and there have not been any reports of  
problems. Backpatch anyway since this is as riskless as it gets.  
  
Discussion: 20150812084351.GD8470@awork2.anarazel.de  
Backpatch: 9.0-master  
  

Use the correct type for TableInfo->relreplident.

  
commit   : feb473a57acb648f29e1520b07b146ba1dc4e22d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 12 Aug 2015 15:52:10 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 12 Aug 2015 15:52:10 +0200    

Click here for diff

  
Mistakenly relreplident was stored as a bool. That works today as c.h  
typedefs bool to a char, but isn't very future proof.  
  
Discussion: 20150812084351.GD8470@awork2.anarazel.de  
Backpatch: 9.4 where replica identity was introduced.  
  

Encoding PG_UHC is code page 949.

  
commit   : f19ad6fbe46afe5005fb0f38ebd436c7cfcbb9ec    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 14 Aug 2015 20:23:13 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 14 Aug 2015 20:23:13 -0400    

Click here for diff

  
This fixes presentation of non-ASCII messages to the Windows event log  
and console in rare cases involving Korean locale.  Processes like the  
postmaster and checkpointer, but not processes attached to databases,  
were affected.  Back-patch to 9.4, where MessageEncoding was introduced.  
The problem exists in all supported versions, but this change has no  
effect in the absence of the code recognizing PG_UHC MessageEncoding.  
  
Noticed while investigating bug #13427 from Dmitri Bourlatchkov.  
  

Restore old pgwin32_message_to_UTF16() behavior outside transactions.

  
commit   : 92516bf1954bd53914f0423bd2817487bd367596    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 14 Aug 2015 20:23:09 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 14 Aug 2015 20:23:09 -0400    

Click here for diff

  
Commit 49c817eab78c6f0ce8c3bf46766b73d6cf3190b7 replaced with a hard  
error the dubious pg_do_encoding_conversion() behavior when outside a  
transaction.  Reintroduce the historic soft failure locally within  
pgwin32_message_to_UTF16().  This fixes errors when writing messages in  
less-common encodings to the Windows event log or console.  Back-patch  
to 9.4, where the aforementioned commit first appeared.  
  
Per bug #13427 from Dmitri Bourlatchkov.  
  

Update key words table for 9.5

  
commit   : b435f191abbdd09bb97bc386ffe71d24d6934f57    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 14 Aug 2015 12:10:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 14 Aug 2015 12:10:35 -0400    

Click here for diff

  
  

MSVC: Exclude ‘brin’ contrib module

  
commit   : 7321841b7c7edc1fd9f6545638e890fdb963aea3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Aug 2015 19:28:54 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Aug 2015 19:28:54 -0300    

Click here for diff

  
The build script is not able to parse the Makefile, so remove it.  
  

Re-add BRIN isolation test

  
commit   : ae372e60b98990863058edc596df8a20207b08d0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Aug 2015 14:41:52 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Aug 2015 14:41:52 -0300    

Click here for diff

  
This time, instead of using a core isolation test, put it on its own  
test module; this way it can require the pageinspect module to be  
present before running.  
  
The module's Makefile is loosely modeled after test_decoding's, so that  
it's easy to add further tests for either pg_regress or isolationtester  
later.  
  
Backpatch to 9.5.  
  

Improve regression test case to avoid depending on system catalog stats.

  
commit   : 657cdb3a21b09a7f02497b8c2e9f46b7bfc59993    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Aug 2015 13:25:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Aug 2015 13:25:01 -0400    

Click here for diff

  
In commit 95f4e59c32866716 I added a regression test case that examined  
the plan of a query on system catalogs.  That isn't a terribly great idea  
because the catalogs tend to change from version to version, or even  
within a version if someone makes an unrelated regression-test change that  
populates the catalogs a bit differently.  Usually I try to make planner  
test cases rely on test tables that have not changed since Berkeley days,  
but I got sloppy in this case because the submitted crasher example queried  
the catalogs and I didn't spend enough time on rewriting it.  But it was a  
problem waiting to happen, as I was rudely reminded when I tried to port  
that patch into Salesforce's Postgres variant :-(.  So spend a little more  
effort and rewrite the query to not use any system catalogs.  I verified  
that this version still provokes the Assert if 95f4e59c32866716's code fix  
is reverted.  
  
I also removed the EXPLAIN output from the test, as it turns out that the  
assertion occurs while considering a plan that isn't the one ultimately  
selected anyway; so there's no value in risking any cross-platform  
variation in that printout.  
  
Back-patch to 9.2, like the previous patch.  
  

Use materialize SRF mode in brin_page_items

  
commit   : 1136971daef209a40eb495b4bd74ce50fbd0fe63    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Aug 2015 13:02:10 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Aug 2015 13:02:10 -0300    

Click here for diff

  
This function was using the single-value-per-call mechanism, but the  
code relied on a relcache entry that wasn't kept open across calls.  
This manifested as weird errors in buildfarm during the short time that  
the "brin-1" isolation test lived.  
  
Backpatch to 9.5, where it was introduced.  
  

Fix declaration of isarray variable.

  
commit   : edebddbb845575206d07145af2d718609b01f6ad    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Thu, 13 Aug 2015 13:22:29 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Thu, 13 Aug 2015 13:22:29 +0200    

Click here for diff

  
Found and fixed by Andres Freund.  
  

Fix unitialized variables

  
commit   : 652ca927ca4d9553691b9c6385111bea353070d8    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Aug 2015 00:12:07 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Aug 2015 00:12:07 -0300    

Click here for diff

  
As complained by clang, reported by Andres Freund.  Brown paper bag bug  
in ccc4c074994d.  
  
Add some comments, too.  
  
Backpatch to 9.5, like that one.  
  

  
commit   : ec94bc1473475128ef4e7b62636e66effd314102    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Aug 2015 21:18:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Aug 2015 21:18:45 -0400    

Click here for diff

  
One of the changes I made in commit 8703059c6b55c427 turns out not to have  
been such a good idea: we still need the exception in join_is_legal() that  
allows a join if both inputs already overlap the RHS of the special join  
we're checking.  Otherwise we can miss valid plans, and might indeed fail  
to find a plan at all, as in recent report from Andreas Seltenreich.  
  
That code was added way back in commit c17117649b9ae23d, but I failed to  
include a regression test case then; my bad.  Put it back with a better  
explanation, and a test this time.  The logic does end up a bit different  
than before though: I now believe it's appropriate to make this check  
first, thereby allowing such a case whether or not we'd consider the  
previous SJ(s) to commute with this one.  (Presumably, we already decided  
they did; but it was confusing to have this consideration in the middle  
of the code that was handling the other case.)  
  
Back-patch to all active branches, like the previous patch.  
  

Close some holes in BRIN page assignment

  
commit   : fc0a6402306db3cc93a5f760acabab687998be1d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 Aug 2015 14:20:38 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 12 Aug 2015 14:20:38 -0300    

Click here for diff

  
In some corner cases, it is possible for the BRIN index relation to be  
extended by brin_getinsertbuffer but the new page not be used  
immediately for anything by its callers; when this happens, the page is  
initialized and the FSM is updated (by brin_getinsertbuffer) with the  
info about that page, but these actions are not WAL-logged.  A later  
index insert/update can use the page, but since the page is already  
initialized, the initialization itself is not WAL-logged then either.  
Replay of this sequence of events causes recovery to fail altogether.  
  
There is a related corner case within brin_getinsertbuffer itself, in  
which we extend the relation to put a new index tuple there, but later  
find out that we cannot do so, and do not return the buffer; the page  
obtained from extension is not even initialized.  The resulting page is  
lost forever.  
  
To fix, shuffle the code so that initialization is not the  
responsibility of brin_getinsertbuffer anymore, in normal cases;  
instead, the initialization is done by its callers (brin_doinsert and  
brin_doupdate) once they're certain that the page is going to be used.  
When either those functions determine that the new page cannot be used,  
before bailing out they initialize the page as an empty regular page,  
enter it in FSM and WAL-log all this.  This way, the page is usable for  
future index insertions, and WAL replay doesn't find trying to insert  
tuples in pages whose initialization didn't make it to the WAL.  The  
same strategy is used in brin_getinsertbuffer when it cannot return the  
new page.  
  
Additionally, add a new step to vacuuming so that all pages of the index  
are scanned; whenever an uninitialized page is found, it is initialized  
as empty and WAL-logged.  This closes the hole that the relation is  
extended but the system crashes before anything is WAL-logged about it.  
We also take this opportunity to update the FSM, in case it has gotten  
out of date.  
  
Thanks to Heikki Linnakangas for finding the problem that kicked some  
additional analysis of BRIN page assignment code.  
  
Backpatch to 9.5, where BRIN was introduced.  
  
Discussion: https://www.postgresql.org/message-id/20150723204810.GY5596@postgresql.org  
  

Handle PQresultErrorField(PG_DIAG_SQLSTATE) returning NULL in streamutil.c.

  
commit   : 2e6f6f3abe6fd249cc8a4d5eb194295ac3988b19    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 12 Aug 2015 17:09:35 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 12 Aug 2015 17:09:35 +0200    

Click here for diff

  
In ff27db5d I missed that PQresultErrorField() may return NULL if  
there's no sqlstate associated with an error.  
  
Spotted-By: Coverity  
Reported-By: Michael Paquier  
Discussion: CAB7nPqQ3o10SY6NVdU4pjq85GQTN5tbbkq2gnNUh2fBNU3rKyQ@mail.gmail.com  
Backpatch: 9.5, like ff27db5d  
  

Fix two off-by-one errors in bufmgr.c.

  
commit   : 43a8ed26c97e36d971b6018d1bc94ad5c52d169b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 12 Aug 2015 17:09:34 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 12 Aug 2015 17:09:34 +0200    

Click here for diff

  
In 4b4b680c I passed a buffer index number (starting from 0) instead of  
a proper Buffer id (which start from 1 for shared buffers) in two  
places.  
  
This wasn't noticed so far as one of those locations isn't compiled at  
all (PrintPinnedBufs) and the other one (InvalidBuffer) requires a  
unlikely, but possible, set of circumstances to trigger a symptom.  
  
To reduce the likelihood of such incidents a bit also convert existing  
open coded mappings from buffer descriptors to buffer ids with  
BufferDescriptorGetBuffer().  
  
Author: Qingqing Zhou  
Reported-By: Qingqing Zhou  
Discussion: CAJjS0u2ai9ooUisKtkV8cuVUtEkMTsbK8c7juNAjv8K11zeCQg@mail.gmail.com  
Backpatch: 9.5 where the private ref count infrastructure was introduced  
  

Fix some possible low-memory failures in regexp compilation.

  
commit   : c5bfcc18a09b3f56ae0fd434ff6c72bd185949c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Aug 2015 00:48:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Aug 2015 00:48:11 -0400    

Click here for diff

  
newnfa() failed to set the regex error state when malloc() fails.  
Several places in regcomp.c failed to check for an error after calling  
subre().  Each of these mistakes could lead to null-pointer-dereference  
crashes in memory-starved backends.  
  
Report and patch by Andreas Seltenreich.  Back-patch to all branches.  
  

  
commit   : 58d2e7fb70584598e026a39f515c5f3c5e589857    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 11 Aug 2015 12:32:49 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 11 Aug 2015 12:32:49 +0200    

Click here for diff

  
Fix a bunch of typos, and remove two superflous includes.  
  
Author: Gurjeet Singh  
Discussion: CABwTF4Wh_dBCzTU=49pFXR6coR4NW1ynb+vBqT+Po=7fuq5iCw@mail.gmail.com  
Backpatch: 9.4  
  

Fix privilege dumping from servers too old to have that type of privilege.

  
commit   : 1cd46851678b304b684f7ab68b4ae888828027f4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2015 20:10:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2015 20:10:15 -0400    

Click here for diff

  
pg_dump produced fairly silly GRANT/REVOKE commands when dumping types from  
pre-9.2 servers, and when dumping functions or procedural languages from  
pre-7.3 servers.  Those server versions lack the typacl, proacl, and/or  
lanacl columns respectively, and pg_dump substituted default values that  
were in fact incorrect.  We ended up revoking all the owner's own  
privileges for the object while granting all privileges to PUBLIC.  
Of course the owner would then have those privileges again via PUBLIC, so  
long as she did not try to revoke PUBLIC's privileges; which may explain  
the lack of field reports.  Nonetheless this is pretty silly behavior.  
  
The stakes were raised by my recent patch to make pg_dump dump shell types,  
because 9.2 and up pg_dump would proceed to emit bogus GRANT/REVOKE  
commands for a shell type if dumping from a pre-9.2 server; and the server  
will not accept GRANT/REVOKE commands for a shell type.  (Perhaps it  
should, but that's a topic for another day.)  So the resulting dump script  
wouldn't load without errors.  
  
The right thing to do is to act as though these objects have default  
privileges (null ACL entries), which causes pg_dump to print no  
GRANT/REVOKE commands at all for them.  That fixes the silly results  
and also dodges the problem with shell types.  
  
In passing, modify getProcLangs() to be less creatively different about  
how to handle missing columns when dumping from older server versions.  
Every other data-acquisition function in pg_dump does that by substituting  
appropriate default values in the version-specific SQL commands, and I see  
no reason why this one should march to its own drummer.  Its use of  
"SELECT *" was likewise not conformant with anyplace else, not to mention  
it's not considered good SQL style for production queries.  
  
Back-patch to all supported versions.  Although 9.0 and 9.1 pg_dump don't  
have the issue with typacl, they are more likely than newer versions to be  
used to dump from ancient servers, so we ought to fix the proacl/lanacl  
issues all the way back.  
  

Accept alternate spellings of __sparcv7 and __sparcv8.

  
commit   : f8e4e0e3f3fe261317c4fd751ea4b9379ac54e94    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2015 17:34:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2015 17:34:51 -0400    

Click here for diff

  
Apparently some versions of gcc prefer __sparc_v7__ and __sparc_v8__.  
Per report from Waldemar Brodkorb.  
  

  
commit   : fda25b22018095fa86bee5a31920344976eb7479    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2015 17:18:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2015 17:18:17 -0400    

Click here for diff

  
Commit 85e5e222b1dd02f135a8c3bf387d0d6d88e669bd turns out not to have taken  
care of all cases of the partially-evaluatable-PlaceHolderVar problem found  
by Andreas Seltenreich's fuzz testing.  I had set it up to check for risky  
PHVs only in the event that we were making a star-schema-based exception to  
the param_source_rels join ordering heuristic.  However, it turns out that  
the problem can occur even in joins that satisfy the param_source_rels  
heuristic, in which case allow_star_schema_join() isn't consulted.  
Refactor so that we check for risky PHVs whenever the proposed join has  
any remaining parameterization.  
  
Back-patch to 9.2, like the previous patch (except for the regression test  
case, which only works back to 9.3 because it uses LATERAL).  
  
Note that this discovery implies that problems of this sort could've  
occurred in 9.2 and up even before the star-schema patch; though I've not  
tried to prove that experimentally.  
  

Temporarily(?) remove BRIN isolation test.

  
commit   : 0ae43b6a631ce8507ef4bd68ce297853a8986fe8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2015 10:22:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2015 10:22:37 -0400    

Click here for diff

  
Commit 2834855cb added a not-very-carefully-thought-out isolation test  
to check a BRIN index bug fix.  The test depended on the availability  
of the pageinspect contrib module, which meant it did not work in  
several common testing scenarios such as "make check-world".  It's not  
clear whether we want a core test depending on a contrib module like  
that, but in any case, failing to deal with the possibility that the  
module isn't present in the installation-under-test is not acceptable.  
  
Remove that test pending some better solution.  
  

Fix copy & paste mistake in pg_get_replication_slots().

  
commit   : 2949987d37cf8d13ca0582610c17a4ddbc246193    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Aug 2015 13:28:19 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Aug 2015 13:28:19 +0200    

Click here for diff

  
XLogRecPtr was compared with InvalidTransactionId instead of  
InvalidXLogRecPtr. As both are defined to the same value this doesn't  
cause any actual problems, but it's still wrong.  
  
Backpatch: 9.4-master, bug was introduced in 9.4  
  

Don’t start to stream after pg_receivexlog –create-slot.

  
commit   : 86baf3c24dfb6f351d0a1653552d0973ad7c4e3d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Aug 2015 13:28:19 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 10 Aug 2015 13:28:19 +0200    

Click here for diff

  
Immediately starting to stream after --create-slot is inconvenient in a  
number of situations (e.g. when configuring a slot for use in  
recovery.conf) and it's easy to just call pg_receivexlog twice in the  
rest of the cases.  
  
Author: Michael Paquier  
Discussion: CAB7nPqQ9qEtuDiKY3OpNzHcz5iUA+DUX9FcN9K8GUkCZvG7+Ew@mail.gmail.com  
Backpatch: 9.5, where the option was introduced  
  

Remove gram.y’s precedence declaration for OVERLAPS.

  
commit   : 6e03d476c93458203c1c0307abaf9068d5793aeb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Aug 2015 19:01:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Aug 2015 19:01:04 -0400    

Click here for diff

  
The allowed syntax for OVERLAPS, viz "row OVERLAPS row", is sufficiently  
constrained that we don't actually need a precedence declaration for  
OVERLAPS; indeed removing this declaration does not change the generated  
gram.c file at all.  Let's remove it to avoid confusion about whether  
OVERLAPS has precedence or not.  If we ever generalize what we allow for  
OVERLAPS, we might need to put back a precedence declaration for it,  
but we might want some other level than what it has today --- and leaving  
the declaration there would just risk confusion about whether that would  
be an incompatible change.  
  
Likewise, remove OVERLAPS from the documentation's precedence table.  
  
Per discussion with Noah Misch.  Back-patch to 9.5 where we hacked up some  
nearby precedence decisions.  
  

Fix typo in LDAP example

  
commit   : 64ac985b5946de4bf7cae21383508477023e0688    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 9 Aug 2015 14:49:47 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 9 Aug 2015 14:49:47 +0200    

Click here for diff

  
Reported by William Meitzen  
  

Fix broken multibyte regression tests.

  
commit   : 479cb1e420c40d78b49535c0ceeaa5f65c7d6797    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 9 Aug 2015 10:55:41 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 9 Aug 2015 10:55:41 +0900    

Click here for diff

  
commit 9043Fe390f4f0b4586cfe59cbd22314b9c3e2957 broke multibyte  
regression tests because the commit removes the warning message when  
temporary hash indexes is created, which has been added by commit  
07af523870bcfe930134054febd3a6a114942e5b.  
  
Back patched to 9.5 stable tree.  
  

docs: fix typo in rules.sgml

  
commit   : 5e0cef8a667746d4abaec16f395b150f46493d80    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 8 Aug 2015 20:40:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 8 Aug 2015 20:40:53 -0400    

Click here for diff

  
Report by Dean Rasheed  
  
Patch by Dean Rasheed  
  
Backpatch through 9.5  
  

9.5 release notes: add increase buffer mapping partitions item

  
commit   : 966aa524edfe8bac837caf0e48ca00d08d8dd5df    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 8 Aug 2015 13:38:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 8 Aug 2015 13:38:31 -0400    

Click here for diff

  
Report by Robert Haas, Andres Freund  
  
Backpatch through 9.5  
  

Further adjustments to PlaceHolderVar removal.

  
commit   : 085338822a2364b5d3afbb13c635b00df43ade45    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Aug 2015 14:13:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Aug 2015 14:13:38 -0400    

Click here for diff

  
A new test case from Andreas Seltenreich showed that we were still a bit  
confused about removing PlaceHolderVars during join removal.  Specifically,  
remove_rel_from_query would remove a PHV that was used only underneath  
the removable join, even if the place where it's used was the join partner  
relation and not the join clause being deleted.  This would lead to a  
"too late to create a new PlaceHolderInfo" error later on.  We can defend  
against that by checking ph_eval_at to see if the PHV could possibly be  
getting used at some partner rel.  
  
Also improve some nearby LATERAL-related logic.  I decided that the check  
on ph_lateral needed to take precedence over the check on ph_needed, in  
case there's a lateral reference underneath the join being considered.  
(That may be impossible, but I'm not convinced of it, and it's easy enough  
to defend against the case.)  Also, I realized that remove_rel_from_query's  
logic for updating LateralJoinInfos is dead code, because we don't build  
those at all until after join removal.  
  
Back-patch to 9.3.  Previous versions didn't have the LATERAL issues, of  
course, and they also didn't attempt to remove PlaceHolderInfos during join  
removal.  (I'm starting to wonder if changing that was really such a great  
idea.)  
  

  
commit   : caf89b31aa79b472a451a5b13657db0da43decee    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 7 Aug 2015 09:04:07 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 7 Aug 2015 09:04:07 -0500    

Click here for diff

  
Spotted by Antonin Houska.  
  

Address points made in post-commit review of replication origins.

  
commit   : 37163e22bddb30a235c9748f49ad54d5e99db142    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 7 Aug 2015 15:08:51 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 7 Aug 2015 15:08:51 +0200    

Click here for diff

  
Amit reviewed the replication origins patch and made some good  
points. Address them. This fixes typos in error messages, docs and  
comments and adds a missing error check (although in a  
should-never-happen scenario).  
  
Discussion: CAA4eK1JqUBVeWWKwUmBPryFaje4190ug0y-OAUHWQ6tD83V4xg@mail.gmail.com  
Backpatch: 9.5, where replication origins were introduced.  
  

9.5 release notes: updates from Andres Freund and Jeff Janes

  
commit   : 892a18ebf0eb2d4182efbcfe12e2ddc142da3693    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 6 Aug 2015 22:33:15 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 6 Aug 2015 22:33:15 -0400    

Click here for diff

  
Report by Andres Freund and Jeff Janes  
  
Backpatch through 9.5  
  

Fix old oversight in join removal logic.

  
commit   : de0227d8aef18c1013b26ab193e48a5122435154    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Aug 2015 22:14:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Aug 2015 22:14:07 -0400    

Click here for diff

  
Commit 9e7e29c75ad441450f9b8287bd51c13521641e3b introduced an Assert that  
join removal didn't reduce the eval_at set of any PlaceHolderVar to empty.  
At first glance it looks like join_is_removable ensures that's true --- but  
actually, the loop in join_is_removable skips PlaceHolderVars that are not  
referenced above the join due to be removed.  So, if we don't want any  
empty eval_at sets, the right thing to do is to delete any now-unreferenced  
PlaceHolderVars from the data structure entirely.  
  
Per fuzz testing by Andreas Seltenreich.  Back-patch to 9.3 where the  
aforesaid Assert was added.  
  

9.5 release notes: mention ON CONFLICT DO NOTHING for FDWs

  
commit   : e663f7561683c8ba7663a8c2115e5a00f84f17c2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 6 Aug 2015 21:08:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 6 Aug 2015 21:08:08 -0400    

Click here for diff

  
Report by Peter Geoghegan  
  
Backpatch through 9.5  
  

Fix eclass_useful_for_merging to give valid results for appendrel children.

  
commit   : a8725c2bade5cb5c51b1203f8037614b49f0c3f7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Aug 2015 20:14:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Aug 2015 20:14:37 -0400    

Click here for diff

  
Formerly, this function would always return "true" for an appendrel child  
relation, because it would think that the appendrel parent was a potential  
join target for the child.  In principle that should only lead to some  
inefficiency in planning, but fuzz testing by Andreas Seltenreich disclosed  
that it could lead to "could not find pathkey item to sort" planner errors  
in odd corner cases.  Specifically, we would think that all columns of a  
child table's multicolumn index were interesting pathkeys, causing us to  
generate a MergeAppend path that sorts by all the columns.  However, if any  
of those columns weren't actually used above the level of the appendrel,  
they would not get added to that rel's targetlist, which would result in  
being unable to resolve the MergeAppend's sort keys against its targetlist  
during createplan.c.  
  
Backpatch to 9.3.  In older versions, columns of an appendrel get added  
to its targetlist even if they're not mentioned above the scan level,  
so that the failure doesn't occur.  It might be worth back-patching this  
fix to older versions anyway, but I'll refrain for the moment.  
  

9.5 release notes: mention change to CRC-32C

  
commit   : 054d33fd012c7b61518f2552b49e7c3653882605    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 6 Aug 2015 18:03:39 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 6 Aug 2015 18:03:39 -0400    

Click here for diff

  
Report by Andres Freund  
  
Backpatch through 9.5  
  

9.5 release notes: adjustments suggested by Andres Freund

  
commit   : 3e2a3727333441e3aa166639adbe735ab7b17712    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 6 Aug 2015 17:34:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 6 Aug 2015 17:34:38 -0400    

Click here for diff

  
Report by Andres Freund  
  
Backpatch through 9.5  
  

9.5 release notes: add non-LEAKPROOF view pushdown mention

  
commit   : 5437eba2eefb32895b912c92535012471701121c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 6 Aug 2015 16:07:27 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 6 Aug 2015 16:07:27 -0400    

Click here for diff

  
Report by Dean Rasheed  
  
Backpatch through 9.5  
  

Further fixes for degenerate outer join clauses.

  
commit   : df3b0f47b9766ff14f50c3e381d8c00a9c2b7a4f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Aug 2015 15:35:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Aug 2015 15:35:27 -0400    

Click here for diff

  
Further testing revealed that commit f69b4b9495269cc4 was still a few  
bricks shy of a load: minor tweaking of the previous test cases resulted  
in the same wrong-outer-join-order problem coming back.  After study  
I concluded that my previous changes in make_outerjoininfo() were just  
accidentally masking the problem, and should be reverted in favor of  
forcing syntactic join order whenever an upper outer join's predicate  
doesn't mention a lower outer join's LHS.  This still allows the  
chained-outer-joins style that is the normally optimizable case.  
  
I also tightened things up some more in join_is_legal().  It seems to me  
on review that what's really happening in the exception case where we  
ignore a mismatched special join is that we're allowing the proposed join  
to associate into the RHS of the outer join we're comparing it to.  As  
such, we should *always* insist that the proposed join be a left join,  
which eliminates a bunch of rather dubious argumentation.  The case where  
we weren't enforcing that was the one that was already known buggy anyway  
(it had a violatable Assert before the aforesaid commit) so it hardly  
deserves a lot of deference.  
  
Back-patch to all active branches, like the previous patch.  The added  
regression test case failed in all branches back to 9.1, and I think it's  
only an unrelated change in costing calculations that kept 9.0 from  
choosing a broken plan.  
  

Fix incorrect calculation in shm_mq_receive.

  
commit   : 6d9864d900e3651413a94e1f86a93f6a03f4dc42    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 6 Aug 2015 13:25:45 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 6 Aug 2015 13:25:45 -0400    

Click here for diff

  
If some, but not all, of the length word has already been read, and the  
next attempt to read sees exactly the number of bytes needed to complete  
the length word, or fewer, then we'll incorrectly read less than all of  
the available data.  
  
Antonin Houska  
  

Fix make installcheck for serializable transactions.

  
commit   : 680b82eea87291e7e14c03a647de654a65617f04    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Thu, 6 Aug 2015 10:35:14 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Thu, 6 Aug 2015 10:35:14 -0500    

Click here for diff

  
Commit e5550d5fec66aa74caad1f79b79826ec64898688 added some new  
tests for ALTER TABLE which involved table scans.  When  
default_transaction_isolation = 'serializable' these acquire  
relation-level SIReadLocks.  The test results didn't cope with  
that.  Add SIReadLock as the minimum lock level for purposes of  
these tests.  
  
This could also be fixed by excluding this type of lock from the  
my_locks view, but it would be a bug for SIReadLock to show up for  
a relation which was not otherwise locked, so do it this way to  
allow that sort of condition to cause a regression test failure.  
  
There is some question whether we could avoid taking SIReadLocks  
during these operations, but confirming the safety of that and  
figuring out how to avoid the locks is not trivial, and would be  
a separate patch.  
  
Backpatch to 9.4 where the new tests were added.  
  

Improve includes introduced in the replication origins patch.

  
commit   : 449b13313caf63c2db936cc46d8a25cfcd9a0d04    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 6 Aug 2015 12:38:35 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 6 Aug 2015 12:38:35 +0200    

Click here for diff

  
pg_resetxlog.h contained two superfluous includes, origin.h superfluously  
depended on logical.h, and pg_xlogdump's rmgrdesc.h only indirectly  
included origin.h.  
  
Backpatch: 9.5, where replication origins were introduced.  
  

Reconcile nodes/*funcs.c with recent work.

  
commit   : 4877281f3a1640577bedd1e92a83931469284368    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 5 Aug 2015 20:44:27 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 5 Aug 2015 20:44:27 -0400    

Click here for diff

  
A few of the discrepancies had semantic significance, but I did not  
track down the resulting user-visible bugs, if any.  Back-patch to 9.5,  
where all but one discrepancy appeared.  The _equalCreateEventTrigStmt()  
situation dates to 9.3 but does not affect semantics.  
  
catversion bump due to readfuncs.c field order changes.  
  

  
commit   : 2fcedad3cac54ec01034f3e225dd7915e59ff8ff    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 5 Aug 2015 20:43:07 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 5 Aug 2015 20:43:07 -0400    

Click here for diff

  
Commit 0ffc201a51395ca71fe429ef86c872850a5850ee included this object  
unconditionally.  Being unprepared for that, most external, single-file  
modules failed to build.  This better aligns the GNU make build system  
with the heuristic in the MSVC build's Project::AddDirResourceFile().  
In-tree, installed modules set PGFILEDESC, so they will see no change.  
Also, under PGXS, omit the nonfunctioning rule to build win32ver.rc.  
Back-patch to 9.5, where the aforementioned commit first appeared.  
  

Fix BRIN to use SnapshotAny during summarization

  
commit   : 94a8b45feb3019d2e6b04806415dd8bc85994706    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 Aug 2015 16:20:50 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 5 Aug 2015 16:20:50 -0300    

Click here for diff

  
For correctness of summarization results, it is critical that the  
snapshot used during the summarization scan is able to see all tuples  
that are live to all transactions -- including tuples inserted or  
deleted by in-progress transactions.  Otherwise, it would be possible  
for a transaction to insert a tuple, then idle for a long time while a  
concurrent transaction executes summarization of the range: this would  
result in the inserted value not being considered in the summary.  
Previously we were trying to use a MVCC snapshot in conjunction with  
adding a "placeholder" tuple in the index: the snapshot would see all  
committed tuples, and the placeholder tuple would catch insertions by  
any new inserters.  The hole is that prior insertions by transactions  
that are still in progress by the time the MVCC snapshot was taken were  
ignored.  
  
Kevin Grittner reported this as a bogus error message during vacuum with  
default transaction isolation mode set to repeatable read (because the  
error report mentioned a function name not being invoked during), but  
the problem is larger than that.  
  
To fix, tweak IndexBuildHeapRangeScan to have a new mode that behaves  
the way we need using SnapshotAny visibility rules.  This change  
simplifies the BRIN code a bit, mainly by removing large comments that  
were mistaken.  Instead, rely on the SnapshotAny semantics to provide  
what it needs.  (The business about a placeholder tuple needs to remain:  
that covers the case that a transaction inserts a a tuple in a page that  
summarization already scanned.)  
  
Discussion: https://www.postgresql.org/message-id/20150731175700.GX2441@postgresql.org  
  
In passing, remove a couple of unused declarations from brin.h and  
reword a comment to be proper English.  This part submitted by Kevin  
Grittner.  
  
Backpatch to 9.5, where BRIN was introduced.  
  

Make real sure we don’t reassociate joins into or out of SEMI/ANTI joins.

  
commit   : 06663971bba43ea967daf00fff0b70ee066c3a13    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Aug 2015 14:39:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Aug 2015 14:39:07 -0400    

Click here for diff

  
Per the discussion in optimizer/README, it's unsafe to reassociate anything  
into or out of the RHS of a SEMI or ANTI join.  An example from Piotr  
Stefaniak showed that join_is_legal() wasn't sufficiently enforcing this  
rule, so lock it down a little harder.  
  
I couldn't find a reasonably simple example of the optimizer trying to  
do this, so no new regression test.  (Piotr's example involved the random  
search in GEQO accidentally trying an invalid case and triggering a sanity  
check way downstream in clause selectivity estimation, which did not seem  
like a sequence of events that would be useful to memorialize in a  
regression test as-is.)  
  
Back-patch to all active branches.  
  

Fix debug message output when connecting to a logical slot.

  
commit   : 34a4318e7d64d93d48add738257ae0f6289799f6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 5 Aug 2015 13:26:01 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 5 Aug 2015 13:26:01 +0200    

Click here for diff

  
Previously the message erroneously printed the same LSN twice as the  
assignment to the start_lsn variable was before the message. Correct  
that.  
  
Reported-By: Marko Tiikkaja  
Author: Marko Tiikkaja  
Backpatch: 9.5, where logical decoding was introduced  
  

Fix comment atomics.h.

  
commit   : 04521eba3f024fdc226d6f0465e2bba7d37828a7    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 5 Aug 2015 13:06:04 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 5 Aug 2015 13:06:04 +0200    

Click here for diff

  
I appear to accidentally have switched the comments for  
pg_atomic_write_u32 and pg_atomic_read_u32 around. Also fix some minor  
typos I found while fixing.  
  
Noticed-By: Amit Kapila  
Backpatch: 9.5  
  

Docs: add an explicit example about controlling overall greediness of REs.

  
commit   : 5c499d5cd2da2fd67f1b234a2994dd940f28fbc2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Aug 2015 21:09:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Aug 2015 21:09:12 -0400    

Click here for diff

  
Per discussion of bug #13538.  
  

Fix pg_dump to dump shell types.

  
commit   : 1f507c7e9dc5b2e8373018fea2f002531c9c1d3a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Aug 2015 19:34:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Aug 2015 19:34:12 -0400    

Click here for diff

  
Per discussion, it really ought to do this.  The original choice to  
exclude shell types was probably made in the dark ages before we made  
it harder to accidentally create shell types; but that was in 7.3.  
  
Also, cause the standard regression tests to leave a shell type behind,  
for convenience in testing the case in pg_dump and pg_upgrade.  
  
Back-patch to all supported branches.  
  

Fix bogus “out of memory” reports in tuplestore.c.

  
commit   : e2035dc9a7a8056eab7c33a1c677cd25312eb312    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Aug 2015 18:18:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Aug 2015 18:18:46 -0400    

Click here for diff

  
The tuplesort/tuplestore memory management logic assumed that the chunk  
allocation overhead for its memtuples array could not increase when  
increasing the array size.  This is and always was true for tuplesort,  
but we (I, I think) blindly copied that logic into tuplestore.c without  
noticing that the assumption failed to hold for the much smaller array  
elements used by tuplestore.  Given rather small work_mem, this could  
result in an improper complaint about "unexpected out-of-memory situation",  
as reported by Brent DeSpain in bug #13530.  
  
The easiest way to fix this is just to increase tuplestore's initial  
array size so that the assumption holds.  Rather than relying on magic  
constants, though, let's export a #define from aset.c that represents  
the safe allocation threshold, and make tuplestore's calculation depend  
on that.  
  
Do the same in tuplesort.c to keep the logic looking parallel, even though  
tuplesort.c isn't actually at risk at present.  This will keep us from  
breaking it if we ever muck with the allocation parameters in aset.c.  
  
Back-patch to all supported versions.  The error message doesn't occur  
pre-9.3, not so much because the problem can't happen as because the  
pre-9.3 tuplestore code neglected to check for it.  (The chance of  
trouble is a great deal larger as of 9.3, though, due to changes in the  
array-size-increasing strategy.)  However, allowing LACKMEM() to become  
true unexpectedly could still result in less-than-desirable behavior,  
so let's patch it all the way back.  
  

  
commit   : a6f43986bf5a6a5b36c899aa9b12f26e5fab687e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Aug 2015 14:55:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Aug 2015 14:55:32 -0400    

Click here for diff

  
In commit b514a7460d9127ddda6598307272c701cbb133b7, I changed the planner  
so that it would allow nestloop paths to remain partially parameterized,  
ie the inner relation might need parameters from both the current outer  
relation and some upper-level outer relation.  That's fine so long as we're  
talking about distinct parameters; but the patch also allowed creation of  
nestloop paths for cases where the inner relation's parameter was a  
PlaceHolderVar whose eval_at set included the current outer relation and  
some upper-level one.  That does *not* work.  
  
In principle we could allow such a PlaceHolderVar to be evaluated at the  
lower join node using values passed down from the upper relation along with  
values from the join's own outer relation.  However, nodeNestloop.c only  
supports simple Vars not arbitrary expressions as nestloop parameters.  
createplan.c is also a few bricks shy of being able to handle such cases;  
it misplaces the PlaceHolderVar parameters in the plan tree, which is why  
the visible symptoms of this bug are "plan should not reference subplan's  
variable" and "failed to assign all NestLoopParams to plan nodes" planner  
errors.  
  
Adding the necessary complexity to make this work doesn't seem like it  
would be repaid in significantly better plans, because in cases where such  
a PHV exists, there is probably a corresponding join order constraint that  
would allow a good plan to be found without using the star-schema exception.  
Furthermore, adding complexity to nodeNestloop.c would create a run-time  
penalty even for plans where this whole consideration is irrelevant.  
So let's just reject such paths instead.  
  
Per fuzz testing by Andreas Seltenreich; the added regression test is based  
on his example query.  Back-patch to 9.2, like the previous patch.  
  

Cap wal_buffers to avoid a server crash when it’s set very large.

  
commit   : cd52e4a2b945403659219350c4d4c6e6539a1e11    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 4 Aug 2015 12:58:54 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 4 Aug 2015 12:58:54 -0400    

Click here for diff

  
It must be possible to multiply wal_buffers by XLOG_BLCKSZ without  
overflowing int, or calculations in StartupXLOG will go badly wrong  
and crash the server.  Avoid that by imposing a maximum value on  
wal_buffers.  This will be just under 2GB, assuming the usual value  
for XLOG_BLCKSZ.  
  
Josh Berkus, per an analysis by Andrew Gierth.  
  

Update comment to match behavior of latest code.

  
commit   : 9d7d0e640c21bfa36e1eeb7e7c9fcdbb2cfb9763    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 4 Aug 2015 11:45:29 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 4 Aug 2015 11:45:29 -0400    

Click here for diff

  
Peter Geoghegan  
  

Stamp 9.5alpha2.

  
commit   : 6bd01f082b2de4a502173e2d48a728c131f35a02    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2015 16:34:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2015 16:34:55 -0400    

Click here for diff

  
  

RLS: Keep deny policy when only restrictive exist

  
commit   : 8f439658524d4a3566682ff9e25d4791c5498e53    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 3 Aug 2015 15:32:49 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 3 Aug 2015 15:32:49 -0400    

Click here for diff

  
Only remove the default deny policy when a permissive policy exists  
(either from the hook or defined by the user).  If only restrictive  
policies exist then no rows will be visible, as restrictive policies  
shouldn't make rows visible.  To address this requirement, a single  
"USING (true)" permissive policy can be created.  
  
Update the test_rls_hooks regression tests to create the necessary  
"USING (true)" permissive policy.  
  
Back-patch to 9.5 where RLS was added.  
  
Per discussion with Dean.  
  

Translation updates

  
commit   : 58b30d9829ce9c3273e8ca32be62ebc2fd0e8153    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 3 Aug 2015 14:10:33 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 3 Aug 2015 14:10:33 -0400    

Click here for diff

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

Update 9.5 release notes through today.

  
commit   : 11daccb445260de9ce03e4408ac7d908545b3319    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2015 12:29:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2015 12:29:11 -0400    

Click here for diff

  
  

Fix psql \d output of policies.

  
commit   : 8f45a58d394bbe83c54306ba769ac02c9239c259    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Mon, 3 Aug 2015 09:08:01 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Mon, 3 Aug 2015 09:08:01 -0700    

Click here for diff

  
psql neglected to wrap parenthesis around USING and WITH CHECK  
expressions -- fixed. Back-patched to 9.5 where RLS policies were  
introduced.  
  

Make recovery rename tablespace_map to *.old if backup_label is not present.

  
commit   : 46e9019bbce96c309d27d4b164bf9a2d0d8292eb    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 3 Aug 2015 23:04:41 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 3 Aug 2015 23:04:41 +0900    

Click here for diff

  
If tablespace_map file is present without backup_label file, there is  
no use of such file.  There is no harm in retaining it, but it is better  
to get rid of the map file so that we don't have any redundant file  
in data directory and it will avoid any sort of confusion. It seems  
prudent though to just rename the file out of the way rather than  
delete it completely, also we ignore any error that occurs in rename  
operation as even if map file is present without backup_label file,  
it is harmless.  
  
Back-patch to 9.5 where tablespace_map file was introduced.  
  
Amit Kapila, reviewed by Robert Haas, Alvaro Herrera and me.  
  

  
commit   : 615b69595525385bbf050a170912b7671cacc5c8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 3 Aug 2015 15:23:56 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 3 Aug 2015 15:23:56 +0300    

Click here for diff

  
pg_xlog is often a symlink, typically to a different filesystem. Don't  
get confused and comlain about by that, and just always pretend that it's a  
normal directory, even if it's really a symlink.  
  
Also add a test case for this.  
  
Backpatch to 9.5.  
  

Clean up pg_rewind regression test script.

  
commit   : 2b917a58aec17ca5cf64196ee1d5d77ef8635caf    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 3 Aug 2015 13:06:47 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 3 Aug 2015 13:06:47 +0300    

Click here for diff

  
Since commit 01f6bb4b2, TestLib.pm has exported path to tmp_check directory,  
so let's use that also for the pg_rewind test clusters etc.  
  
Also, in master, the $tempdir_short variable has not been used since commit  
13d856e17, which moved the initdb-running code to TestLib.pm.  
  
Backpatch to 9.5.  
  

Make modules/test_ddl_deparse/.gitignore match its siblings.

  
commit   : 642ae4ee7dcb9b48a4abd1f02a46ff4d71aef931    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2015 00:02:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Aug 2015 00:02:26 -0400    

Click here for diff

  
Not sure why /tmp_check/ was omitted from this one, but even if it  
isn't really needed right now, it's inconsistent not to include it.  
  

contrib/isn now needs a .gitignore file.

  
commit   : 61015249259462020629703a4990234c4629cbee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2015 23:57:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2015 23:57:32 -0400    

Click here for diff

  
Oversight in commit cb3384a0cb4cf900622b77865f60e31259923079.  
Back-patch to 9.1, like that commit.  
  

Fix a number of places that produced XX000 errors in the regression tests.

  
commit   : 89e80b03297555277473fc3978b83c68ec9847b8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2015 23:49:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2015 23:49:19 -0400    

Click here for diff

  
It's against project policy to use elog() for user-facing errors, or to  
omit an errcode() selection for errors that aren't supposed to be "can't  
happen" cases.  Fix all the violations of this policy that result in  
ERRCODE_INTERNAL_ERROR log entries during the standard regression tests,  
as errors that can reliably be triggered from SQL surely should be  
considered user-facing.  
  
I also looked through all the files touched by this commit and fixed  
other nearby problems of the same ilk.  I do not claim to have fixed  
all violations of the policy, just the ones in these files.  
  
In a few places I also changed existing ERRCODE choices that didn't  
seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR  
by something more specific.  
  
Back-patch to 9.5, but no further; changing ERRCODE assignments in  
stable branches doesn't seem like a good idea.  
  

Avoid calling memcpy() with a NULL source pointer and count == 0.

  
commit   : c75b1f75b3d159c0e71c1ec7f42c922bce448d89    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2015 15:48:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2015 15:48:27 -0400    

Click here for diff

  
As in commit 0a52d378b03b7d5a, avoid doing something that has undefined  
results according to the C standard, even though in practice there does  
not seem to be any problem with it.  
  
This fixes two places in numeric.c that demonstrably could call memcpy()  
with such arguments.  I looked through that file and didn't see any other  
places with similar hazards; this is not to claim that there are not such  
places in other files.  
  
Per report from Piotr Stefaniak.  Back-patch to 9.5 which is where the  
previous commit was added.  We're more or less setting a precedent that  
we will not worry about this type of issue in pre-9.5 branches unless  
someone demonstrates a problem in the field.  
  

Fix output of ISBN-13 numbers beginning with 979.

  
commit   : ea8385df6ce95507951f6c12fa4defb5b3ba9cda    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 2 Aug 2015 22:12:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 2 Aug 2015 22:12:33 +0300    

Click here for diff

  
An EAN beginning with 979 (but not 9790 - those are ISMN's) are accepted  
as ISBN numbers, but they cannot be represented in the old, 10-digit ISBN  
format. They must be output in the new 13-digit ISBN-13 format. We printed  
out an incorrect value for those.  
  
Also add a regression test, to test this and some other basic functionality  
of the module.  
  
Patch by Fabien Coelho. This fixes bug #13442, reported by B.Z. Backpatch  
to 9.1, where we started to recognize ISBN-13 numbers.  
  

Fix incorrect order of lock file removal and failure to close() sockets.

  
commit   : 72697d2ba77074713cd4008995a97cf284de1712    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2015 14:54:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Aug 2015 14:54:44 -0400    

Click here for diff

  
Commit c9b0cbe98bd783e24a8c4d8d8ac472a494b81292 accidentally broke the  
order of operations during postmaster shutdown: it resulted in removing  
the per-socket lockfiles after, not before, postmaster.pid.  This creates  
a race-condition hazard for a new postmaster that's started immediately  
after observing that postmaster.pid has disappeared; if it sees the  
socket lockfile still present, it will quite properly refuse to start.  
This error appears to be the explanation for at least some of the  
intermittent buildfarm failures we've seen in the pg_upgrade test.  
  
Another problem, which has been there all along, is that the postmaster  
has never bothered to close() its listen sockets, but has just allowed them  
to close at process death.  This creates a different race condition for an  
incoming postmaster: it might be unable to bind to the desired listen  
address because the old postmaster is still incumbent.  This might explain  
some odd failures we've seen in the past, too.  (Note: this is not related  
to the fact that individual backends don't close their client communication  
sockets.  That behavior is intentional and is not changed by this patch.)  
  
Fix by adding an on_proc_exit function that closes the postmaster's ports  
explicitly, and (in 9.3 and up) reshuffling the responsibility for where  
to unlink the Unix socket files.  Lock file unlinking can stay where it  
is, but teach it to unlink the lock files in reverse order of creation.  
  

Fix race condition that lead to WALInsertLock deadlock with commit_delay.

  
commit   : 54f23a45f3742e9533dbfa7c1177f02f116b0457    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 2 Aug 2015 20:08:10 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 2 Aug 2015 20:08:10 +0300    

Click here for diff

  
If a call to WaitForXLogInsertionsToFinish() returned a value in the middle  
of a page, and another backend then started to insert a record to the same  
page, and then you called WaitXLogInsertionsToFinish() again, the second  
call might return a smaller value than the first call. The problem was in  
GetXLogBuffer(), which always updated the insertingAt value to the  
beginning of the requested page, not the actual requested location. Because  
of that, the second call might return a xlog pointer to the beginning of  
the page, while the first one returned a later position on the same page.  
XLogFlush() performs two calls to WaitXLogInsertionsToFinish() in  
succession, and holds WALWriteLock on the second call, which can deadlock  
if the second call to WaitXLogInsertionsToFinish() blocks.  
  
Reported by Spiros Ioannou. Backpatch to 9.4, where the more scalable  
WALInsertLock mechanism, and this bug, was introduced.  
  

Micro optimize LWLockAttemptLock() a bit.

  
commit   : 9074e41dbd41bc45ef79aeac1b6496bf087509a7    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 31 Jul 2015 20:50:35 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 31 Jul 2015 20:50:35 +0200    

Click here for diff

  
LWLockAttemptLock pointlessly read the lock's state in every loop  
iteration, even though pg_atomic_compare_exchange_u32() returns the old  
value. Instead do that only once before the loop iteration.  
  
Additionally there's no need to have the expected_state variable,  
old_state mostly had the same value anyway.  
  
Noticed-By: Heikki Linnakangas  
Backpatch: 9.5, no reason to let the branches diverge at this point  
  

Fix issues around the “variable” support in the lwlock infrastructure.

  
commit   : 27b719173516b54df63a1bba4266798e9f77bbb9    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 31 Jul 2015 20:20:43 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 31 Jul 2015 20:20:43 +0200    

Click here for diff

  
The lwlock scalability work introduced two race conditions into the  
lwlock variable support provided for xlog.c. First, and harmlessly on  
most platforms, it set/read the variable without the spinlock in some  
places. Secondly, due to the removal of the spinlock, it was possible  
that a backend missed changes to the variable's state if it changed in  
the wrong moment because checking the lock's state, the variable's state  
and the queuing are not protected by a single spinlock acquisition  
anymore.  
  
To fix first move resetting the variable's from LWLockAcquireWithVar to  
WALInsertLockRelease, via a new function LWLockReleaseClearVar. That  
prevents issues around waiting for a variable's value to change when a  
new locker has acquired the lock, but not yet set the value. Secondly  
re-check that the variable hasn't changed after enqueing, that prevents  
the issue that the lock has been released and already re-acquired by the  
time the woken up backend checks for the lock's state.  
  
Reported-By: Jeff Janes  
Analyzed-By: Heikki Linnakangas  
Reviewed-By: Heikki Linnakangas  
Discussion: 5592DB35.2060401@iki.fi  
Backpatch: 9.5, where the lwlock scalability went in  
  

Fix some planner issues with degenerate outer join clauses.

  
commit   : 7968238eb17ed5f2f1123271549b7921fa1d3aba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Aug 2015 20:57:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Aug 2015 20:57:41 -0400    

Click here for diff

  
An outer join clause that didn't actually reference the RHS (perhaps only  
after constant-folding) could confuse the join order enforcement logic,  
leading to wrong query results.  Also, nested occurrences of such things  
could trigger an Assertion that on reflection seems incorrect.  
  
Per fuzz testing by Andreas Seltenreich.  The practical use of such cases  
seems thin enough that it's not too surprising we've not heard field  
reports about it.  
  
This has been broken for a long time, so back-patch to all active branches.  
  

Teach predtest.c that “foo” implies “foo IS NOT NULL”.

  
commit   : 8dccf030e884ea8c723275a070acf8a8ed1eebe1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Aug 2015 14:31:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Aug 2015 14:31:46 -0400    

Click here for diff

  
Per complaint from Peter Holzer.  It's useful to cover this special case,  
since for a boolean variable "foo", earlier parts of the planner will have  
reduced variants like "foo = true" to just "foo", and thus we may fail  
to recognize the applicability of a partial index with predicate  
"foo IS NOT NULL".  
  
Back-patch to 9.5, but not further; given the lack of previous complaints  
this doesn't seem like behavior to change in stable branches.  
  

  
commit   : edf26ed033f18bddc9bfe5c239388330150766a1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jul 2015 19:26:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 31 Jul 2015 19:26:33 -0400    

Click here for diff

  
In many cases, we can implement a semijoin as a plain innerjoin by first  
passing the righthand-side relation through a unique-ification step.  
However, one of the cases where this does NOT work is where the RHS has  
a LATERAL reference to the LHS; that makes the RHS dependent on the LHS  
so that unique-ification is meaningless.  joinpath.c understood this,  
and so would not generate any join paths of this kind ... but join_is_legal  
neglected to check for the case, so it would think that we could do it.  
The upshot would be a "could not devise a query plan for the given query"  
failure once we had failed to generate any join paths at all for the bogus  
join pair.  
  
Back-patch to 9.3 where LATERAL was added.  
  

Consolidate makefile code for setting top_srcdir, srcdir and VPATH.

  
commit   : c7446194fa8fbbb9e8d948668bb47563ab58f45f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 30 Jul 2015 20:48:41 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 30 Jul 2015 20:48:41 -0400    

Click here for diff

  
Responsibility was formerly split between Makefile.global and pgxs.mk.  
As a result of commit b58233c71b93a32fcab7219585cafc25a27eb769, in the  
PGXS case, these variables were unset while parsing Makefile.global and  
callees.  Inclusion of Makefile.custom did not work from PGXS, and the  
subtle difference seemed like a recipe for future bugs.  Back-patch to  
9.4, where that commit first appeared.  
  

Fix volatility marking of commit timestamp functions

  
commit   : 71b66e78e432d99325db6356f056cb3f03b3d7b7    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Jul 2015 15:19:49 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Jul 2015 15:19:49 -0300    

Click here for diff

  
They are marked stable, but since they act on instantaneous state and it  
is possible to consult state of transactions as they commit, the results  
could change mid-query.  They need to be marked volatile, and this  
commit does so.  
  
There would normally be a catversion bump here, but this is so much a  
niche feature and I don't believe there's real damage from the incorrect  
marking, that I refrained.  
  
Backpatch to 9.5, where commit timestamps where introduced.  
  
Per note from Fujii Masao.  
  

Fix broken assertion in BRIN code

  
commit   : 244c378e243e3649efc99fe96ec9f123bbe9ffbc    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Jul 2015 15:07:19 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 30 Jul 2015 15:07:19 -0300    

Click here for diff

  
The code was assuming that any NULL value in scan keys was due to IS  
NULL or IS NOT NULL, but it turns out to be possible to get them with  
other operators too, if they are used in contrived-enough ways.  Easiest  
way out of the problem seems to check explicitely for the IS NOT NULL  
flag, instead of assuming it must be set if the IS NULL flag is not set,  
when a null scan key is found; if neither flag is set, follow the lead  
of other index AMs and assume that all indexable operators must be  
strict, and thus the query is never satisfiable.  
  
Also, add a comment to try and lure some future hacker into improving  
analysis of scan keys in brin.  
  
Per report from Andreas Seltenreich; diagnosis by Tom Lane.  
Backpatch to 9.5.  
  
Discussion: http://www.postgresql.org/message-id/20646.1437919632@sss.pgh.pa.us  
  

Improve CREATE FUNCTION doc WRT to LEAKPROOF RLS interaction.

  
commit   : 7be60a2459135199f8edff7f553b6d551729d79f    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Thu, 30 Jul 2015 10:16:49 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Thu, 30 Jul 2015 10:16:49 -0700    

Click here for diff

  
Patch by Dean Rasheed. Back-patched to 9.5 where RLS was introduced.  
  

Use appropriate command type when retrieving relation’s policies.

  
commit   : 23b5e726da6ef5ebbc1dbc821320ee35fa1d0737    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Thu, 30 Jul 2015 09:38:13 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Thu, 30 Jul 2015 09:38:13 -0700    

Click here for diff

  
When retrieving policies, if not working on the root target relation,  
we actually want the relation's SELECT policies, regardless of  
the top level query command type. For example in UPDATE t1...FROM t2  
we need to apply t1's UPDATE policies and t2's SELECT policies.  
Previously top level query command type was applied to all relations,  
which was wrong. Add some regression coverage to ensure we don't  
violate this principle in the future.  
  
Report and patch by Dean Rasheed. Cherry picked from larger refactoring  
patch and tweaked by me. Back-patched to 9.5 where RLS was introduced.  
  

Avoid some zero-divide hazards in the planner.

  
commit   : e91a1643ac723477d6ec2d47c8486cd0013660bb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Jul 2015 12:11:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Jul 2015 12:11:23 -0400    

Click here for diff

  
Although I think on all modern machines floating division by zero  
results in Infinity not SIGFPE, we still don't want infinities  
running around in the planner's costing estimates; too much risk  
of that leading to insane behavior.  
  
grouping_planner() failed to consider the possibility that final_rel  
might be known dummy and hence have zero rowcount.  (I wonder if it  
would be better to set a rows estimate of 1 for dummy relations?  
But at least in the back branches, changing this convention seems  
like a bad idea, so I'll leave that for another day.)  
  
Make certain that get_variable_numdistinct() produces a nonzero result.  
The case that can be shown to be broken is with stadistinct < 0.0 and  
small ntuples; we did not prevent the result from rounding to zero.  
For good luck I applied clamp_row_est() to all the nonconstant return  
values.  
  
In ExecChooseHashTableSize(), Assert that we compute positive nbuckets  
and nbatch.  I know of no reason to think this isn't the case, but it  
seems like a good safety check.  
  
Per reports from Piotr Stefaniak.  Back-patch to all active branches.  
  

Fix calculation of latency of pgbench backslash commands.

  
commit   : 2e75be6660dbaaf2da09b98c54d47c9fe0ac8cfa    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 30 Jul 2015 14:50:51 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 30 Jul 2015 14:50:51 +0300    

Click here for diff

  
When we loop back to the top of doCustom after processing a backslash  
command, we must reset the "now" timestamp, because that's used to  
calculate the time spent executing the previous command.  
  
Report and fix by Fabien Coelho. Backpatch to 9.5, where this was broken.  
  

Blacklist xlc 32-bit inlining.

  
commit   : a664d4790e5f93726f264c77c044a7ce4c1a675c    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 29 Jul 2015 22:49:48 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 29 Jul 2015 22:49:48 -0400    

Click here for diff

  
Per a suggestion from Tom Lane.  Back-patch to 9.0 (all supported  
versions).  While only 9.4 and up have code known to elicit this  
compiler bug, we were disabling inlining by accident until commit  
43d89a23d59c487bc9258fad7a6187864cb8c0c0.  
  

Remove redundant “make install” from pg_upgrade test suite.

  
commit   : 1471c0e27c2f71bed551463e8072da9c01c63dae    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 29 Jul 2015 22:49:36 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 29 Jul 2015 22:49:36 -0400    

Click here for diff

  
A top-level "make install" includes pg_upgrade since commit  
9fa8b0ee90c44c0f97d16bf65e94322988c94864.  Back-patch to 9.5, where that  
commit first appeared.  
  

MSVC: Revert most 9.5 changes to pre-9.5 vcregress.pl tests.

  
commit   : fdb8ea9366785d7e2a31469c1389ca8a6f11889f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 29 Jul 2015 22:48:56 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 29 Jul 2015 22:48:56 -0400    

Click here for diff

  
The reverted changes did not narrow the semantic gap between the MSVC  
build system and the GNU make build system.  For targets old and new  
that run multiple suites (contribcheck, modulescheck, tapcheck), restore  
vcregress.pl to mimicking "make -k" rather than the "make -S" default.  
Lack of "-k" would be more burdensome than lack of "-S".  Keep changes  
reflecting contemporary changes to the GNU make build system, and keep  
updates to Makefile parsing.  Keep the loss of --psqldir in "check" and  
"ecpgcheck" targets; it had been a no-op when used alongside  
--temp-install.  No log message mentioned any of the reverted changes.  
Based on a germ by Michael Paquier.  Back-patch to 9.5.  
  

MSVC: Remove duplicate PATH entry in test harness.

  
commit   : 95eb4b265502c26c9f72f0f554df41e273551858    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 29 Jul 2015 22:48:43 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 29 Jul 2015 22:48:43 -0400    

Click here for diff

  
Back-patch to 9.5, where commit 4cb7d671fddc8855c8def2de51fb23df1c8ac0af  
introduced it.  
  

MSVC: Future-proof installation file skip logic.

  
commit   : f7dca86fc3a2c423824a2056994319c348992913    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 29 Jul 2015 22:48:25 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 29 Jul 2015 22:48:25 -0400    

Click here for diff

  
This code relied on knowing exactly where in the source tree temporary  
installations might appear.  A reasonable hacker may not think to update  
this code when adding use of a temporary installation, making it  
fragile.  Observe that commit 9fa8b0ee90c44c0f97d16bf65e94322988c94864  
broke it unnoticed, and commit dcae5faccab64776376d354decda0017c648bb53  
fixed it unnoticed.  Back-patch to 9.5 only; use of temporary  
installations is unlikely to change in released versions.  
  

Create new ParseExprKind for use by policy expressions.

  
commit   : 43797ed42a7c0365c9143ad6efdc566ac9d93fd8    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Wed, 29 Jul 2015 15:41:00 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Wed, 29 Jul 2015 15:41:00 -0700    

Click here for diff

  
Policy USING and WITH CHECK expressions were using EXPR_KIND_WHERE for  
parse analysis, which results in inappropriate ERROR messages when  
the expression contains unsupported constructs such as aggregates.  
Create a new ParseExprKind called EXPR_KIND_POLICY and tailor the  
related messages to fit.  
  
Reported by Noah Misch. Reviewed by Dean Rasheed, Alvaro Herrera,  
and Robert Haas. Back-patch to 9.5 where RLS was introduced.  
  

Add some test coverage of EvalPlanQual with non-locked tables.

  
commit   : 3ef1a682d5e4a919dcaddc8256ea65de91654d1c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jul 2015 13:27:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jul 2015 13:27:15 -0400    

Click here for diff

  
A Salesforce colleague of mine griped that the regression tests don't  
exercise EvalPlanQualFetchRowMarks() and allied routines.  Which is  
a fair complaint.  Add test cases that go through the REFERENCE and COPY  
code paths.  Unfortunately we don't have sufficient infrastructure right  
now to exercise the FDW code path in the isolation tests, but this is  
surely better than before.  
  

Add missing post create and alter hooks to policy objects.

  
commit   : 0bfbf14f93c30ec8f505baba79625f5a3b010405    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Wed, 29 Jul 2015 09:39:28 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Wed, 29 Jul 2015 09:39:28 -0700    

Click here for diff

  
AlterPolicy() and CreatePolicy() lacked their respective hook invocations.  
Noted by Noah Misch, review by Dean Rasheed. Back-patch to 9.5 where  
RLS was introduced.  
  

Remove outdated comment in LWLockDequeueSelf’s header.

  
commit   : 81191f65820d3cf29ea94fe7f65c065e8c6a296c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 29 Jul 2015 10:14:32 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 29 Jul 2015 10:14:32 +0200    

Click here for diff

  
Noticed-By: Robert Haas  
Backpatch: 9.5, where the function was added  
  

Fix typo in comment.

  
commit   : 6f1789a475fe2726f8ade5ecd3aa14223b130fb1    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 29 Jul 2015 10:55:43 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 29 Jul 2015 10:55:43 +0300    

Click here for diff

  
Amit Langote  
  

Prevent platform-dependent output row ordering in a new test query.

  
commit   : d7f0bb8cc7f4b43830499e89384befc3690b1560    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jul 2015 20:00:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jul 2015 20:00:13 -0400    

Click here for diff

  
Buildfarm indicates this is necessary.  
  

Suppress “variable may be used uninitialized” warning.

  
commit   : cab23771eb0250fe8e2ad179cf10ef965658f3e7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jul 2015 19:55:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jul 2015 19:55:59 -0400    

Click here for diff

  
Also re-pgindent, just because I'm a neatnik.  
  

Disallow converting a table to a view if row security is present.

  
commit   : 344703bcc453ac3ce0060785d4958ddec7d2dbe9    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Tue, 28 Jul 2015 16:24:09 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Tue, 28 Jul 2015 16:24:09 -0700    

Click here for diff

  
When DefineQueryRewrite() is about to convert a table to a view, it checks  
the table for features unavailable to views.  For example, it rejects tables  
having triggers.  It omits to reject tables having relrowsecurity or a  
pg_policy record. Fix that. To faciliate the repair, invent  
relation_has_policies() which indicates the presence of policies on a  
relation even when row security is disabled for that relation.  
  
Reported by Noah Misch. Patch by me, review by Stephen Frost. Back-patch  
to 9.5 where RLS was introduced.  
  

Create a pg_shdepend entry for each role in TO clause of policies.

  
commit   : 992c9d345f6607c5b2cab2787f7cf72fba96673d    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Tue, 28 Jul 2015 16:01:56 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Tue, 28 Jul 2015 16:01:56 -0700    

Click here for diff

  
CreatePolicy() and AlterPolicy() omit to create a pg_shdepend entry for  
each role in the TO clause. Fix this by creating a new shared dependency  
type called SHARED_DEPENDENCY_POLICY and assigning it to each role.  
  
Reported by Noah Misch. Patch by me, reviewed by Alvaro Herrera.  
Back-patch to 9.5 where RLS was introduced.  
  

Update our documentation concerning where to create data directories.

  
commit   : 28b11bd1069ed35f45125b4057780cc55b9d716a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jul 2015 18:42:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jul 2015 18:42:59 -0400    

Click here for diff

  
Although initdb has long discouraged use of a filesystem mount-point  
directory as a PG data directory, this point was covered nowhere in the  
user-facing documentation.  Also, with the popularity of pg_upgrade,  
we really need to recommend that the PG user own not only the data  
directory but its parent directory too.  (Without a writable parent  
directory, operations such as "mv data data.old" fail immediately.  
pg_upgrade itself doesn't do that, but wrapper scripts for it often do.)  
  
Hence, adjust the "Creating a Database Cluster" section to address  
these points.  I also took the liberty of wordsmithing the discussion  
of NFS a bit.  
  
These considerations aren't by any means new, so back-patch to all  
supported branches.  
  

Only adjust negative indexes in json_get up to the length of the path.

  
commit   : 40a50a17b905dae233ddb8bb36b7deff9e3abb16    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 28 Jul 2015 17:54:13 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 28 Jul 2015 17:54:13 -0400    

Click here for diff

  
The previous code resulted in memory access beyond the path bounds. The  
cure is to move it into a code branch that checks the value of lex_level  
is within the correct bounds.  
  
Bug reported and diagnosed by Piotr Stefaniak.  
  

Reduce chatter from signaling of autovacuum workers.

  
commit   : 116be6c17102a4b300037d3c565694cac0bcba90    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jul 2015 17:34:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jul 2015 17:34:00 -0400    

Click here for diff

  
Don't print a WARNING if we get ESRCH from a kill() that's attempting  
to cancel an autovacuum worker.  It's possible (and has been seen in the  
buildfarm) that the worker is already gone by the time we are able to  
execute the kill, in which case the failure is harmless.  About the only  
plausible reason for reporting such cases would be to help debug corrupted  
lock table contents, but this is hardly likely to be the most important  
symptom if that happens.  Moreover issuing a WARNING might scare users  
more than is warranted.  
  
Also, since sending a signal to an autovacuum worker is now entirely a  
routine thing, and the worker will log the query cancel on its end anyway,  
reduce the message saying we're doing that from LOG to DEBUG1 level.  
  
Very minor cosmetic cleanup as well.  
  
Since the main practical reason for doing this is to avoid unnecessary  
buildfarm failures, back-patch to all active branches.  
  

  
commit   : cfa928ff6f944ac101802718f64db942060187b1    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Tue, 28 Jul 2015 13:21:37 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Tue, 28 Jul 2015 13:21:37 -0700    

Click here for diff

  
The pg_stats view is supposed to be restricted to only show rows  
about tables the user can read. However, it sometimes can leak  
information which could not otherwise be seen when row level security  
is enabled. Fix that by not showing pg_stats rows to users that would  
be subject to RLS on the table the row is related to. This is done  
by creating/using the newly introduced SQL visible function,  
row_security_active().  
  
Along the way, clean up three call sites of check_enable_rls(). The second  
argument of that function should only be specified as other than  
InvalidOid when we are checking as a different user than the current one,  
as in when querying through a view. These sites were passing GetUserId()  
instead of InvalidOid, which can cause the function to return incorrect  
results if the current user has the BYPASSRLS privilege and row_security  
has been set to OFF.  
  
Additionally fix a bug causing RI Trigger error messages to unintentionally  
leak information when RLS is enabled, and other minor cleanup and  
improvements. Also add WITH (security_barrier) to the definition of pg_stats.  
  
Bumped CATVERSION due to new SQL functions and pg_stats view definition.  
  
Back-patch to 9.5 where RLS was introduced. Reported by Yaroslav.  
Patch by Joe Conway and Dean Rasheed with review and input by  
Michael Paquier and Stephen Frost.  
  

Remove ssl renegotiation support.

  
commit   : 6087d952b31fce56642e1c63cfed243aeb4d09bd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 28 Jul 2015 21:39:32 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 28 Jul 2015 21:39:32 +0200    

Click here for diff

  
While postgres' use of SSL renegotiation is a good idea in theory, it  
turned out to not work well in practice. The specification and openssl's  
implementation of it have lead to several security issues. Postgres' use  
of renegotiation also had its share of bugs.  
  
Additionally OpenSSL has a bunch of bugs around renegotiation, reported  
and open for years, that regularly lead to connections breaking with  
obscure error messages. We tried increasingly complex workarounds to get  
around these bugs, but we didn't find anything complete.  
  
Since these connection breakages often lead to hard to debug problems,  
e.g. spuriously failing base backups and significant latency spikes when  
synchronous replication is used, we have decided to change the default  
setting for ssl renegotiation to 0 (disabled) in the released  
backbranches and remove it entirely in 9.5 and master.  
  
Author: Andres Freund  
Discussion: 20150624144148.GQ4797@alap3.anarazel.de  
Backpatch: 9.5 and master, 9.0-9.4 get a different patch  
  

Make tap tests store postmaster logs and handle vpaths correctly

  
commit   : da7db24cc22e3f0d96cfda134f3ed194279bb513    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 28 Jul 2015 16:04:05 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 28 Jul 2015 16:04:05 -0400    

Click here for diff

  
Given this it is possible that the buildfarm animals running these tests  
will be able to capture adequate logging to allow diagnosis of failures.  
  

Remove an unsafe Assert, and explain join_clause_is_movable_into() better.

  
commit   : f7cdc518e613b08831ccd798257df3ba3556ea21    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jul 2015 13:20:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Jul 2015 13:20:39 -0400    

Click here for diff

  
join_clause_is_movable_into() is approximate, in the sense that it might  
sometimes return "false" when actually it would be valid to push the given  
join clause down to the specified level.  This is okay ... but there was  
an Assert in get_joinrel_parampathinfo() that's only safe if the answers  
are always exact.  Comment out the Assert, and add a bunch of commentary  
to clarify what's going on.  
  
Per fuzz testing by Andreas Seltenreich.  The added regression test is  
a pretty silly query, but it's based on his crasher example.  
  
Back-patch to 9.2 where the faulty logic was introduced.  
  

Improve logging of TAP tests.

  
commit   : fa4a4df93c8c28d5684cacb1677fbd13f58bb9f2    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 28 Jul 2015 12:22:21 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 28 Jul 2015 12:22:21 -0400    

Click here for diff

  
Create a log file for each test run. Stdout and stderr of the test script,  
as well as any subprocesses run as part of the test, are redirected to  
the log file. This makes it a lot easier to debug test failures. Also print  
the test output (ok 12 - ... messages) to the log file, and the command  
line of any external programs executed with the system_or_bail and run_log  
functions. This makes it a lot easier to debug failing tests.  
  
Modify some of the pg_ctl and other command invocations to not use 'silent'  
or 'quiet' options, and don't redirect output to /dev/null, so that you get  
all the information in the log instead.  
  
In the passing, construct some command lines in a way that works if $tempdir  
contains quote-characters. I haven't systematically gone through all of  
them or tested that, so I don't know if this is enough to make that work.  
  
pg_rewind tests had a custom mechanism for creating a similar log file. Use  
the new generic facility instead.  
  
Michael Paquier and Heikki Linnakangas.  
  
This is a backpatch of Heikki's commit 1ea06203b82b98b5098808667f6ba652181ef5b2.  
  

Another attempt at fixing memory leak in xlogreader.

  
commit   : beebb259d2a994cd2021a1506b7af1716b16f476    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 28 Jul 2015 09:05:46 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 28 Jul 2015 09:05:46 +0300    

Click here for diff

  
max_block_id is also reset between reading records.  
  
Michael Paquier  
  

Fix pg_dump output of policies.

  
commit   : 510aad31eaf2129d28ae3dbfc58f98775192ee94    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Mon, 27 Jul 2015 20:24:27 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Mon, 27 Jul 2015 20:24:27 -0700    

Click here for diff

  
pg_dump neglected to wrap parenthesis around USING and WITH CHECK  
expressions -- fixed. Reported by Noah Misch.  
  

Improve RLS handling in copy.c

  
commit   : 5d179a28fb4c819f3812c40fa7e626b1d3081982    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 27 Jul 2015 16:48:26 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 27 Jul 2015 16:48:26 -0400    

Click here for diff

  
To avoid a race condition where the relation being COPY'd could be  
changed into a view or otherwise modified, keep the original lock  
on the relation.  Further, fully qualify the relation when building  
the query up.  
  
Also remove the poorly thought-out Assert() and check the entire  
relationOids list as, post-RLS, there can certainly be multiple  
relations involved and the planner does not guarantee their ordering.  
  
Per discussion with Noah and Andres.  
  
Back-patch to 9.5 where RLS was introduced.  
  

Further code review for pg_stat_ssl patch.

  
commit   : cb0bb53204d84cecf51022313fe47d625de8f01e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Jul 2015 16:29:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Jul 2015 16:29:14 -0400    

Click here for diff

  
Fix additional bogosity in commit 9029f4b37406b21a.  Include the  
BackendSslStatusBuffer in the BackendStatusShmemSize calculation,  
avoid ugly and error-prone casts to char* and back, put related  
code stanzas into a consistent order (and fix a couple of previous  
instances of that sin).  All cosmetic except for the size oversight.  
  

Fix pointer-arithmetic thinko in pg_stat_ssl patch.

  
commit   : f3cf8b6b6edc69f94fa1bcaa5b9b806e14281098    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Jul 2015 15:58:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Jul 2015 15:58:46 -0400    

Click here for diff

  
Nasty memory-stomp bug in commit 9029f4b37406b21a.  It's not apparent how  
this survived even cursory testing :-(.  Per report from Peter Holzer.  
  

Don’t assume that ‘char’ is signed.

  
commit   : 1b7f125bf7e74fb3b128b3bcbe593d9e7327ff50    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 21:48:51 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 21:48:51 +0300    

Click here for diff

  
On some platforms, notably ARM and PowerPC, 'char' is unsigned by  
default. This fixes an assertion failure at WAL replay on such platforms.  
  
Reported by Noah Misch. Backpatch to 9.5, where this was broken.  
  

Fix memory leaks in pg_rewind. Several PQclear() calls were missing.

  
commit   : d09c873f637b783ef36770c88de551efb08c9e4a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 20:38:44 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 20:38:44 +0300    

Click here for diff

  
Originally reported by Vladimir Borodin in the pg_rewind github project,  
patch by Michael Paquier.  
  

Don’t assume that PageIsEmpty() returns true on an all-zeros page.

  
commit   : 9c88e06b5a24341e0e82fbab7b02de271adf1f47    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 18:54:09 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 18:54:09 +0300    

Click here for diff

  
It does currently, and I don't see us changing that any time soon, but we  
don't make that assumption anywhere else.  
  
Per Tom Lane's suggestion. Backpatch to 9.2, like the previous patch that  
added this assumption.  
  

Fix memory leak in xlogreader facility.

  
commit   : 03a0a3532b47b2a634cd2700d49edc086af748a0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 18:27:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 18:27:27 +0300    

Click here for diff

  
XLogReaderFree failed to free the per-block data buffers, when they  
happened to not be used by the latest read WAL record.  
  
Michael Paquier. Backpatch to 9.5, where the per-block buffers were added.  
  

Reuse all-zero pages in GIN.

  
commit   : 202aea62a84135256c6aa394af2c4dbfa1700c85    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 12:30:26 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 12:30:26 +0300    

Click here for diff

  
In GIN, an all-zeros page would be leaked forever, and never reused. Just  
add them to the FSM in vacuum, and they will be reinitialized when grabbed  
from the FSM. On master and 9.5, attempting to access the page's opaque  
struct also caused an assertion failure, although that was otherwise  
harmless.  
  
Reported by Jeff Janes. Backpatch to all supported versions.  
  

Fix handling of all-zero pages in SP-GiST vacuum.

  
commit   : 2fa8ba34804211714a6e0a7fcf5512423c77f8dd    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 12:28:21 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 12:28:21 +0300    

Click here for diff

  
SP-GiST initialized an all-zeros page at vacuum, but that was not  
WAL-logged, which is not safe. You might get a torn page write, when it gets  
flushed to disk, and end-up with a half-initialized index page. To fix,  
leave it in the all-zeros state, and add it to the FSM. It will be  
initialized when reused. Also don't set the page-deleted flag when recycling  
an empty page. That was also not WAL-logged, and a torn write of that would  
cause the page to have an invalid checksum.  
  
Backpatch to 9.2, where SP-GiST indexes were added.  
  

Avoid calling PageGetSpecialPointer() on an all-zeros page.

  
commit   : 6a0a388c202098db207fff8e571f599296aa57d8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 12:24:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 12:24:27 +0300    

Click here for diff

  
That was otherwise harmless, but tripped the new assertion in  
PageGetSpecialPointer().  
  
Reported by Amit Langote. Backpatch to 9.5, where the assertion was added.  
  

Remove false comment about speculative insertion.

  
commit   : dd20a97219b569b92bdcbd0c195c214340298b4a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 11:46:11 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Jul 2015 11:46:11 +0300    

Click here for diff

  
There is no full discussion of speculative insertions in the executor  
README. There is a high-level explanation in execIndexing.c, but it doesn't  
seem necessary to refer it from here.  
  
Peter Geoghegan  
  

Fix oversight in flattening of subqueries with empty FROM.

  
commit   : 8fb61e0b5430b8dada0eca18b99e3956f4eaf6cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Jul 2015 17:44:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Jul 2015 17:44:27 -0400    

Click here for diff

  
I missed a restriction that commit f4abd0241de20d5d6a79b84992b9e88603d44134  
should have enforced: we can't pull up an empty-FROM subquery if it's under  
an outer join, because then we'd need to wrap its output columns in  
PlaceHolderVars.  As the code currently stands, the PHVs end up with empty  
relid sets, which doesn't work (and is correctly caught by an Assert).  
  
It's possible that this could be fixed by assigning the PHVs the relid  
sets of the parent FromExpr/JoinExpr, but getting that to work is more  
complication than I care to add right now; indeed it's likely that  
we'll never bother, since pulling up empty-FROM subqueries is a rather  
marginal optimization anyway.  
  
Per report from Andreas Seltenreich.  Back-patch to 9.5 where the faulty  
code was added.  
  

Make entirely-dummy appendrels get marked as such in set_append_rel_size.

  
commit   : 7481c6c2aa379f8d3427819fcaa0eac5c93b1dcf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Jul 2015 16:19:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Jul 2015 16:19:08 -0400    

Click here for diff

  
The planner generally expects that the estimated rowcount of any relation  
is at least one row, *unless* it has been proven empty by constraint  
exclusion or similar mechanisms, which is marked by installing a dummy path  
as the rel's cheapest path (cf. IS_DUMMY_REL).  When I split up  
allpaths.c's processing of base rels into separate set_base_rel_sizes and  
set_base_rel_pathlists steps, the intention was that dummy rels would get  
marked as such during the "set size" step; this is what justifies an Assert  
in indxpath.c's get_loop_count that other relations should either be dummy  
or have positive rowcount.  Unfortunately I didn't get that quite right  
for append relations: if all the child rels have been proven empty then  
set_append_rel_size would come up with a rowcount of zero, which is  
correct, but it didn't then do set_dummy_rel_pathlist.  (We would have  
ended up with the right state after set_append_rel_pathlist, but that's  
too late, if we generate indexpaths for some other rel first.)  
  
In addition to fixing the actual bug, I installed an Assert enforcing this  
convention in set_rel_size; that then allows simplification of a couple  
of now-redundant tests for zero rowcount in set_append_rel_size.  
  
Also, to cover the possibility that third-party FDWs have been careless  
about not returning a zero rowcount estimate, apply clamp_row_est to  
whatever an FDW comes up with as the rows estimate.  
  
Per report from Andreas Seltenreich.  Back-patch to 9.2.  Earlier branches  
did not have the separation between set_base_rel_sizes and  
set_base_rel_pathlists steps, so there was no intermediate state where an  
appendrel would have had inconsistent rowcount and pathlist.  It's possible  
that adding the Assert to set_rel_size would be a good idea in older  
branches too; but since they're not under development any more, it's likely  
not worth the trouble.  
  

Check the relevant index element in ON CONFLICT unique index inference.

  
commit   : 13d0053f98390ad17e373cefb95e27273c0c345c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 26 Jul 2015 18:20:41 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 26 Jul 2015 18:20:41 +0200    

Click here for diff

  
ON CONFLICT unique index inference had a thinko that could affect cases  
where the user-supplied inference clause required that an attribute  
match a particular (user specified) collation and/or opclass.  
  
infer_collation_opclass_match() has to check for opclass and/or  
collation matches and that the attribute is in the list of attributes or  
expressions known to be in the definition of the index under  
consideration. The bug was that these two conditions weren't necessarily  
evaluated for the same index attribute.  
  
Author: Peter Geoghegan  
Discussion: CAM3SWZR4uug=WvmGk7UgsqHn2MkEzy9YU-+8jKGO4JPhesyeWg@mail.gmail.com  
Backpatch: 9.5, where ON CONFLICT was introduced  
  

Fix flattening of nested grouping sets.

  
commit   : b17ae36ba9521014c5ae30cb3a3f77c439b41bb3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 26 Jul 2015 16:37:49 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 26 Jul 2015 16:37:49 +0200    

Click here for diff

  
Previously nested grouping set specifications accidentally weren't  
flattened, but instead contained the nested specification as a element  
in the outer list.  
  
Fix this by, as actually documented in comments, concatenating the  
nested set specification into the outer one. Also add tests to prevent  
this from breaking again.  
  
Author: Andrew Gierth, with tests from Jeevan Chalke  
Reported-By: Jeevan Chalke  
Discussion: CAM2+6=V5YvuxB+EyN4iH=GbD-XTA435TCNvnDFSD--YvXs+pww@mail.gmail.com  
Backpatch: 9.5, where grouping sets were introduced  
  

Allow to push down clauses from HAVING to WHERE when grouping sets are used.

  
commit   : 29e4455d7139d0b1bf8d3b62e566e7bb20cf0ec6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 26 Jul 2015 15:56:26 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 26 Jul 2015 15:56:26 +0200    

Click here for diff

  
Previously we disallowed pushing down quals to WHERE in the presence of  
grouping sets. That's overly restrictive.  
  
We now instead copy quals to WHERE if applicable, leaving the  
one in HAVING in place. That's because, at that stage of the planning  
process, it's nontrivial to determine if it's safe to remove the one in  
HAVING.  
  
Author: Andrew Gierth  
Discussion: 874mkt3l59.fsf@news-spur.riddles.org.uk  
Backpatch: 9.5, where grouping sets were introduced. This isn't exactly  
    a bugfix, but it seems better to keep the branches in sync at this point.  
  

Recognize GROUPING() as a aggregate expression.

  
commit   : 3500d1cc78f61927e05c0e73158b87ff24f81c09    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 26 Jul 2015 15:34:29 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 26 Jul 2015 15:34:29 +0200    

Click here for diff

  
Previously GROUPING() was not recognized as a aggregate expression,  
erroneously allowing the planner to move it from HAVING to WHERE.  
  
Author: Jeevan Chalke  
Reviewed-By: Andrew Gierth  
Discussion: CAM2+6=WG9omG5rFOMAYBweJxmpTaapvVp5pCeMrE6BfpCwr4Og@mail.gmail.com  
Backpatch: 9.5, where grouping sets were introduced  
  

Build column mapping for grouping sets in all required cases.

  
commit   : 65b86c1767a7dac0cc79dcfba7ba4cbd326dc03f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 26 Jul 2015 15:17:44 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 26 Jul 2015 15:17:44 +0200    

Click here for diff

  
The previous coding frequently failed to fail because for one it's  
unusual to have rollup clauses with one column, and for another  
sometimes the wrong mapping didn't cause obvious problems.  
  
Author: Jeevan Chalke  
Reviewed-By: Andrew Gierth  
Discussion: CAM2+6=W=9=hQOipH0HAPbkun3Z3TFWij_EiHue0_6UX=oR=1kw@mail.gmail.com  
Backpatch: 9.5, where grouping sets were introduced  
  

Improve markup for row_security.

  
commit   : 60624f45fc12a249fd48ac7557238c974d8e5011    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sat, 25 Jul 2015 17:46:33 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sat, 25 Jul 2015 17:46:33 -0700    

Click here for diff

  
Wrap the literals on, off, force, and BYPASSRLS with appropriate  
markup. Per Kevin Grittner.  
  

Dodge portability issue (apparent compiler bug) in new tablesample code.

  
commit   : d5b132bb626d126b6d0696f2f4068815053da115    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jul 2015 19:42:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jul 2015 19:42:32 -0400    

Click here for diff

  
Some of the older OS X critters in the buildfarm are failing regression,  
with symptoms showing that a request for 100% sampling in BERNOULLI or  
SYSTEM methods actually gets only around 50% of the table.  gdb revealed  
that the computation of the "cutoff" number was producing 0x7FFFFFFF  
rather than the expected 0x100000000.  Inspecting the assembly code,  
it looks like gcc is trying to use lrint() instead of rint() and then  
fumbling the conversion from long double to uint64.  This seems like a  
clear compiler bug, but assigning the intermediate result into a plain  
double variable works around it, so let's just do that.  (Another idea  
would be to give up one bit of hash width so that we don't need to use  
a uint64 cutoff, but let's see if this is enough.)  
  

Restore use of zlib default compression in pg_dump directory mode.

  
commit   : 08012455cd31a4148c5072a6aac1ad41a89e6d4b    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 25 Jul 2015 17:14:36 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 25 Jul 2015 17:14:36 -0400    

Click here for diff

  
This was broken by commit 0e7e355f27302b62af3e1add93853ccd45678443 and  
friends, which ignored the fact that gzopen() will treat "-1" in the  
mode argument as an invalid character, which it ignores, and a flag for  
compression level 1. Now, when this value is encountered no compression  
level flag is passed  to gzopen, leaving it to use the zlib default.  
  
Also, enforce the documented allowed range for pg_dump's -Z option,  
namely 0 .. 9, and remove some consequently dead code from  
pg_backup_tar.c.  
  
Problem reported by Marc Mamin.  
  
Backpatch to 9.1, like the patch that introduced the bug.  
  

Some platforms now need contrib/tsm_system_time to be linked with libm.

  
commit   : 62005e9465a409d317a7a41d821afc5ed235670b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jul 2015 16:37:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jul 2015 16:37:12 -0400    

Click here for diff

  
Buildfarm member hornet, at least, seems to want -lm in the link command.  
Probably this is due to the just-added use of isnan().  
  

In pg_ctl, report unexpected failure to stat() the postmaster.pid file.

  
commit   : 87221867e8b8fedb347e32d3d919e62ae85edc81    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jul 2015 15:58:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jul 2015 15:58:14 -0400    

Click here for diff

  
Any error other than ENOENT is a bit suspicious here, and perhaps should  
not be grounds for assuming the postmaster has failed.  For the moment  
though, just report it, and don't change the behavior otherwise.  The  
intent is mainly to try to determine why we are seeing intermittent  
failures in this area on some buildfarm members.  
  
Back-patch to 9.5 where some of these failures have happened.  
  

Update oidjoins regression test for 9.5.

  
commit   : 68c3549fb56834f47d57ef010ffbd3bdbd80b941    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jul 2015 15:46:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jul 2015 15:46:26 -0400    

Click here for diff

  
New FK relationships for pg_transform.  Also findoidjoins now detects a few  
relationships it didn't before for pre-existing catalogs, as a result of  
new regression tests leaving entries in those catalogs that weren't there  
before.  
  

Redesign tablesample method API, and do extensive code review.

  
commit   : 6fcb337fa507723d6940ed8e5658d3da1fac6195    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jul 2015 14:39:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 25 Jul 2015 14:39:00 -0400    

Click here for diff

  
The original implementation of TABLESAMPLE modeled the tablesample method  
API on index access methods, which wasn't a good choice because, without  
specialized DDL commands, there's no way to build an extension that can  
implement a TSM.  (Raw inserts into system catalogs are not an acceptable  
thing to do, because we can't undo them during DROP EXTENSION, nor will  
pg_upgrade behave sanely.)  Instead adopt an API more like procedural  
language handlers or foreign data wrappers, wherein the only SQL-level  
support object needed is a single handler function identified by having  
a special return type.  This lets us get rid of the supporting catalog  
altogether, so that no custom DDL support is needed for the feature.  
  
Adjust the API so that it can support non-constant tablesample arguments  
(the original coding assumed we could evaluate the argument expressions at  
ExecInitSampleScan time, which is undesirable even if it weren't outright  
unsafe), and discourage sampling methods from looking at invisible tuples.  
Make sure that the BERNOULLI and SYSTEM methods are genuinely repeatable  
within and across queries, as required by the SQL standard, and deal more  
honestly with methods that can't support that requirement.  
  
Make a full code-review pass over the tablesample additions, and fix  
assorted bugs, omissions, infelicities, and cosmetic issues (such as  
failure to put the added code stanzas in a consistent ordering).  
Improve EXPLAIN's output of tablesample plans, too.  
  
Back-patch to 9.5 so that we don't have to support the original API  
in production.  
  

Make RLS work with UPDATE … WHERE CURRENT OF

  
commit   : 7d4240d6cd91d83d263a45501cc2f44fb1d0a537    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Fri, 24 Jul 2015 12:56:25 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Fri, 24 Jul 2015 12:56:25 -0700    

Click here for diff

  
UPDATE ... WHERE CURRENT OF would not work in conjunction with  
RLS. Arrange to allow the CURRENT OF expression to be pushed down.  
Issue noted by Peter Geoghegan. Patch by Dean Rasheed. Back patch  
to 9.5 where RLS was introduced.  
  

Fix treatment of nulls in jsonb_agg and jsonb_object_agg

  
commit   : 016f28ad3dbf3bec14319cf2a49925b0063251aa    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 24 Jul 2015 09:40:46 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 24 Jul 2015 09:40:46 -0400    

Click here for diff

  
The wrong is_null flag was being passed to datum_to_json. Also, null  
object key values are not permitted, and this was not being checked  
for. Add regression tests covering these cases, and also add those tests  
to the json set, even though it was doing the right thing.  
  
Fixes bug #13514, initially diagnosed by Tom Lane.  
  

Fix bug around assignment expressions containing indirections.

  
commit   : bb0203f26fa5f09fe2689a9db4bc632c1435edec    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 24 Jul 2015 11:48:53 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 24 Jul 2015 11:48:53 +0200    

Click here for diff

  
Handling of assigned-to expressions with indirection (e.g. set f1[1] =  
3) was broken for ON CONFLICT DO UPDATE.  The problem was that  
ParseState was consulted to determine if an INSERT-appropriate or  
UPDATE-appropriate behavior should be used when transforming expressions  
with indirections. When the wrong path was taken the old row was  
substituted with NULL, leading to wrong results..  
  
To fix remove p_is_update and only use p_is_insert to decide how to  
transform the assignment expression, and uset p_is_insert while parsing  
the on conflict statement. This isn't particularly pretty, but it's not  
any worse than before.  
  
Author: Peter Geoghegan, slightly edited by me  
Discussion: CAM3SWZS8RPvA=KFxADZWw3wAHnnbxMxDzkEC6fNaFc7zSm411w@mail.gmail.com  
Backpatch: 9.5, where the feature was introduced  
  

Redirect install output of make check into a log file

  
commit   : fbf8dc21738749470f73f91a95ac01912c9deb10    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 23 Jul 2015 09:44:20 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 23 Jul 2015 09:44:20 -0400    

Click here for diff

  
dbf2ec1a changed make check so that the installation logs get directed  
to stdout and stderr. Per discussion on -hackers, this patch restores  
saving it to a file. It is now saved in /tmp_install/log, which is  
created once per invocation of any make target doing regression tests.  
  
Along the way, add a missing /log/ entry to test_ddl_deparse's  
.gitignore.  
  
Michael Paquier.  
  

Fix off-by-one error in calculating subtrans/multixact truncation point.

  
commit   : a9b3a22aa18345451a20696fe272b6e02f5a2bbb    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 23 Jul 2015 01:30:07 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 23 Jul 2015 01:30:07 +0300    

Click here for diff

  
If there were no subtransactions (or multixacts) active, we would calculate  
the oldestxid == next xid. That's correct, but if next XID happens to be  
on the next pg_subtrans (pg_multixact) page, the page does not exist yet,  
and SimpleLruTruncate will produce an "apparent wraparound" warning. The  
warning is harmless in this case, but looks very alarming to users.  
  
Backpatch to all supported versions. Patch and analysis by Thomas Munro.  
  

Fix add_rte_to_flat_rtable() for recent feature additions.

  
commit   : 41ae3b74d987d5d42f2c432812285c7d12d6f4c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jul 2015 20:03:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jul 2015 20:03:58 -0400    

Click here for diff

  
The TABLESAMPLE and row security patches each overlooked this function,  
though their errors of omission were opposite: RLS failed to zero out the  
securityQuals field, leading to wasteful copying of useless expression  
trees in finished plans, while TABLESAMPLE neglected to add a comment  
saying that it intentionally *isn't* deleting the tablesample subtree.  
There probably should be a similar comment about ctename, too.  
  
Back-patch as appropriate.  
  

Fix some oversights in BRIN patch.

  
commit   : 35ac618a7c4602b792160ae0d77b6dfb289f517e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jul 2015 13:38:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jul 2015 13:38:24 -0400    

Click here for diff

  
Remove HeapScanDescData.rs_initblock, which wasn't being used for anything  
in the final version of the patch.  
  
Fix IndexBuildHeapScan so that it supports syncscan again; the patch  
broke synchronous scanning for index builds by forcing rs_startblk  
to zero even when the caller did not care about that and had asked  
for syncscan.  
  
Add some commentary and usage defenses to heap_setscanlimits().  
  
Fix heapam so that asking for rs_numblocks == 0 does what you would  
reasonably expect.  As coded it amounted to requesting a whole-table  
scan, because those "--x <= 0" tests on an unsigned variable would  
behave surprisingly.  
  

Fix location of output logs of pg_regress

  
commit   : 29f171c81a0d064ab556417374b8809a8ebe2c08    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 21 Jul 2015 09:53:16 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 21 Jul 2015 09:53:16 -0400    

Click here for diff

  
initdb.log and postmaster.log were moved to within the temporary instance  
path by commit dcae5fa. This directory now gets removed at the end  
of the run of pg_regress when there are no failures found, which makes  
analysis of after-run issues difficult in some cases, and reduces the  
output verbosity of the buildfarm after a run.  
  
Fix by Michael Paquier  
  
Backpatch to 9.5  
  

Fix omission of OCLASS_TRANSFORM in object_classes[]

  
commit   : d6ec181cf14a1d3f3d8ca9400a404b9828776ca3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Jul 2015 13:20:53 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Jul 2015 13:20:53 +0200    

Click here for diff

  
This was forgotten in cac76582053e (and its fixup ad89a5d115).  Since it  
seems way too easy to miss this, this commit also introduces a mechanism  
to enforce that the array is consistent with the enum.  
  
Problem reported independently by Robert Haas and Jaimin Pan.  
Patches proposed by Jaimin Pan, Jim Nasby, Michael Paquier and myself,  
though I didn't use any of these and instead went with a cleaner  
approach suggested by Tom Lane.  
  
Backpatch to 9.5.  
  
Discussion:  
https://www.postgresql.org/message-id/CA+Tgmoa6SgDaxW_n_7SEhwBAc=mniYga+obUj5fmw4rU9_mLvA@mail.gmail.com  
https://www.postgresql.org/message-id/29788.1437411581@sss.pgh.pa.us  
  

Sanity-check that a page zeroed by redo routine is marked with WILL_INIT.

  
commit   : e015c3e51f76a05cc026c8323c51a373172adaa3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 20 Jul 2015 16:02:28 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 20 Jul 2015 16:02:28 +0300    

Click here for diff

  
There was already a sanity-check in the other direction: if a page was  
marked with WILL_INIT, it had to be initialized by the redo routine. It's  
not strictly necessary for correctness that a page is marked with WILL_INIT  
if it's going to be initialized at redo, but it's a missed optimization if  
nothing else.  
  
Fix a few instances of this issue in SP-GiST, where a block in WAL record  
was not marked with WILL_INIT, but was in fact always initialized at redo.  
We were creating a full-page image of the page unnecessarily in those  
cases.  
  
Backpatch to 9.5, where the new WILL_INIT flag was added.  
  

Don’t handle PUBLIC/NONE separately

  
commit   : 869eb8416255da99fe5ba1f6d98e52a41999d30e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Jul 2015 18:47:15 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Jul 2015 18:47:15 +0200    

Click here for diff

  
Since those role specifiers are checked in the grammar, there's no need  
for the old checks to remain in place after 31eae6028ec.  Remove them.  
  
Backpatch to 9.5.  
  
Noted and patch by Jeevan Chalke  
  

Improve tab-completion for DROP POLICY

  
commit   : 691c32f69a7efd6af9cda100c7e5ebf3b0c1937c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Jul 2015 15:37:17 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Jul 2015 15:37:17 +0200    

Click here for diff

  
Backpatch to 9.5.  
  
Author: Pavel Stěhule  
  

Fix (some of) pltcl memory usage

  
commit   : b0b6f8d71f03463854576b30c1b01e5d772076d8    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Jul 2015 14:18:08 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Jul 2015 14:18:08 +0200    

Click here for diff

  
As reported by Bill Parker, PL/Tcl did not validate some malloc() calls  
against NULL return.  Fix by using palloc() in a new long-lived memory  
context instead.  This allows us to simplify error handling too, by  
simply deleting the memory context instead of doing retail frees.  
  
There's still a lot that could be done to improve PL/Tcl's memory  
handling ...  
  
This is pretty ancient, so backpatch all the way back.  
  
Author: Michael Paquier and Álvaro Herrera  
Discussion: https://www.postgresql.org/message-id/CAFrbyQwyLDYXfBOhPfoBGqnvuZO_Y90YgqFM11T2jvnxjLFmqw@mail.gmail.com  
  

Improve BRIN documentation somewhat

  
commit   : 38b03caebc5de44704567d8422f256c3e66b4784    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Jul 2015 12:16:40 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Jul 2015 12:16:40 +0200    

Click here for diff

  
This removes some info about support procedures being used, which was  
obsoleted by commit db5f98ab4f, as well as add some more documentation  
on how to create new opclasses using the Minmax infrastructure.  
(Hopefully we can get something similar for Inclusion as well.)  
  
In passing, fix some obsolete mentions of "mmtuples" in source code  
comments.  
  
Backpatch to 9.5, where BRIN was introduced.  
  

Fix mis-merge in previous commit

  
commit   : b2f01a731647b84d7c88d2028e8dc7be5599740f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Jul 2015 11:59:31 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Jul 2015 11:59:31 +0200    

Click here for diff

  
  

Add some comments to test_ddl_deparse and a README

  
commit   : f1f3434f210450af2e3dab08fbc05a9edd0b67a4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Jul 2015 11:20:40 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Jul 2015 11:20:40 +0200    

Click here for diff

  
Per comments from Heikki Linnakangas.  
  
Backpatch to 9.5, where this module was introduced.  
  

Handle AT_ReAddComment in test_ddl_deparse, and add a catch-all default.

  
commit   : e66e31958fc5f5346394099a6481a7949cc1f02a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 20 Jul 2015 10:19:22 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 20 Jul 2015 10:19:22 +0300    

Click here for diff

  
In the passing, also move AT_ReAddComment to more logical position in the  
enum, after all the Constraint-related subcommands.  
  
This fixes a compiler warning, added by commit e42375fc. Backpatch to 9.5,  
like that patch.  
  

Remove dead code.

  
commit   : 0ed1e572b644e064e480e14d2f6afe03d11638a7    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 19 Jul 2015 13:19:38 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 19 Jul 2015 13:19:38 -0400    

Click here for diff

  
Defect noticed by Coverity.  
  

Make WaitLatchOrSocket’s timeout detection more robust.

  
commit   : fd735e976cab3a95374c710ff5d2865102e3145a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jul 2015 11:47:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jul 2015 11:47:13 -0400    

Click here for diff

  
In the previous coding, timeout would be noticed and reported only when  
poll() or socket() returned zero (or the equivalent behavior on Windows).  
Ordinarily that should work well enough, but it seems conceivable that we  
could get into a state where poll() always returns a nonzero value --- for  
example, if it is noticing a condition on one of the file descriptors that  
we do not think is reason to exit the loop.  If that happened, we'd be in a  
busy-wait loop that would fail to terminate even when the timeout expires.  
  
We can make this more robust at essentially no cost, by deciding to exit  
of our own accord if we compute a zero or negative time-remaining-to-wait.  
Previously the code noted this but just clamped the time-remaining to zero,  
expecting that we'd detect timeout on the next loop iteration.  
  
Back-patch to 9.2.  While 9.1 had a version of WaitLatchOrSocket, it was  
primitive compared to later versions, and did not guarantee reliable  
detection of timeouts anyway.  (Essentially, this is a refinement of  
commit 3e7fdcffd6f77187, which was back-patched only as far as 9.2.)  
  

Enable transforms modules to build and test on Cygwin.

  
commit   : d27fad73e8de2f3f9b68096926735d53d87e7f6a    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 18 Jul 2015 10:09:04 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 18 Jul 2015 10:09:04 -0400    

Click here for diff

  
This still doesn't work correctly with Python 3, but I am committing  
this so we can get Cygwin buildfarm members building with Python 2.  
  

Release note compatibility item

  
commit   : 0beef5af3a4821155251d8d445b9ba1296381645    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Jul 2015 21:08:03 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Jul 2015 21:08:03 -0400    

Click here for diff

  
Note that json and jsonb extraction operators no longer consider a  
negative subscript to be invalid.  
  

Support JSON negative array subscripts everywhere

  
commit   : 89ddd29bbd70c31652c6e7a179473753b89a3cac    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Jul 2015 20:56:13 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Jul 2015 20:56:13 -0400    

Click here for diff

  
Previously, there was an inconsistency across json/jsonb operators that  
operate on datums containing JSON arrays -- only some operators  
supported negative array count-from-the-end subscripting.  Specifically,  
only a new-to-9.5 jsonb deletion operator had support (the new "jsonb -  
integer" operator).  This inconsistency seemed likely to be  
counter-intuitive to users.  To fix, allow all places where the user can  
supply an integer subscript to accept a negative subscript value,  
including path-orientated operators and functions, as well as other  
extraction operators.  This will need to be called out as an  
incompatibility in the 9.5 release notes, since it's possible that users  
are relying on certain established extraction operators changed here  
yielding NULL in the event of a negative subscript.  
  
For the json type, this requires adding a way of cheaply getting the  
total JSON array element count ahead of time when parsing arrays with a  
negative subscript involved, necessitating an ad-hoc lex and parse.  
This is followed by a "conversion" from a negative subscript to its  
equivalent positive-wise value using the count.  From there on, it's as  
if a positive-wise value was originally provided.  
  
Note that there is still a minor inconsistency here across jsonb  
deletion operators.  Unlike the aforementioned new "-" deletion operator  
that accepts an integer on its right hand side, the new "#-" path  
orientated deletion variant does not throw an error when it appears like  
an array subscript (input that could be recognized by as an integer  
literal) is being used on an object, which is wrong-headed.  The reason  
for not being stricter is that it could be the case that an object pair  
happens to have a key value that looks like an integer; in general,  
these two possibilities are impossible to differentiate with rhs path  
text[] argument elements.  However, we still don't allow the "#-"  
path-orientated deletion operator to perform array-style subscripting.  
Rather, we just return the original left operand value in the event of a  
negative subscript (which seems analogous to how the established  
"jsonb/json #> text[]" path-orientated operator may yield NULL in the  
event of an invalid subscript).  
  
In passing, make SetArrayPath() stricter about not accepting cases where  
there is trailing non-numeric garbage bytes rather than a clean NUL  
byte.  This means, for example, that strings like "10e10" are now not  
accepted as an array subscript of 10 by some new-to-9.5 path-orientated  
jsonb operators (e.g. the new #- operator).  Finally, remove dead code  
for jsonb subscript deletion; arguably, this should have been done in  
commit b81c7b409.  
  
Peter Geoghegan and Andrew Dunstan  
  

Repair mishandling of cached cast-expression trees in plpgsql.

  
commit   : 9a5f369adc734e0a8d45192d1b790a6849a391dd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jul 2015 15:53:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jul 2015 15:53:10 -0400    

Click here for diff

  
In commit 1345cc67bbb014209714af32b5681b1e11eaf964, I introduced caching  
of expressions representing type-cast operations into plpgsql.  However,  
I supposed that I could cache both the expression trees and the evaluation  
state trees derived from them for the life of the session.  This doesn't  
work, because we execute the expressions in plpgsql's simple_eval_estate,  
which has an ecxt_per_query_memory that is only transaction-lifespan.  
Therefore we can end up putting pointers into the evaluation state tree  
that point to transaction-lifespan memory; in particular this happens if  
the cast expression calls a SQL-language function, as reported by Geoff  
Winkless.  
  
The minimum-risk fix seems to be to treat the state trees the same way  
we do for "simple expression" trees in plpgsql, ie create them in the  
simple_eval_estate's ecxt_per_query_memory, which means recreating them  
once per transaction.  
  
Since I had to introduce bookkeeping overhead for that anyway, I bought  
back some of the added cost by sharing the read-only expression trees  
across all functions in the session, instead of using a per-function  
table as originally.  The simple-expression bookkeeping takes care of  
the recursive-usage risk that I was concerned about avoiding before.  
  
At some point we should take a harder look at how all this works,  
and see if we can't reduce the amount of tree reinitialization needed.  
But that won't happen for 9.5.  
  

AIX: Test the -qlonglong option before use.

  
commit   : eb3b93b534e153b0e71ce17a2f48126e3a772167    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 17 Jul 2015 03:01:14 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 17 Jul 2015 03:01:14 -0400    

Click here for diff

  
xlc provides "long long" unconditionally at C99-compatible language  
levels, and this option provokes a warning.  The warning interferes with  
"configure" tests that fail in response to any warning.  Notably, before  
commit 85a2a8903f7e9151793308d0638621003aded5ae, it interfered with the  
test for -qnoansialias.  Back-patch to 9.0 (all supported versions).  
  

Fix a low-probability crash in our qsort implementation.

  
commit   : fd415ffc9cca3d938d21b24c8513e409af7b751c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jul 2015 22:57:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jul 2015 22:57:46 -0400    

Click here for diff

  
It's standard for quicksort implementations, after having partitioned the  
input into two subgroups, to recurse to process the smaller partition and  
then handle the larger partition by iterating.  This method guarantees  
that no more than log2(N) levels of recursion can be needed.  However,  
Bentley and McIlroy argued that checking to see which partition is smaller  
isn't worth the cycles, and so their code doesn't do that but just always  
recurses on the left partition.  In most cases that's fine; but with  
worst-case input we might need O(N) levels of recursion, and that means  
that qsort could be driven to stack overflow.  Such an overflow seems to  
be the only explanation for today's report from Yiqing Jin of a SIGSEGV  
in med3_tuple while creating an index of a couple billion entries with a  
very large maintenance_work_mem setting.  Therefore, let's spend the few  
additional cycles and lines of code needed to choose the smaller partition  
for recursion.  
  
Also, fix up the qsort code so that it properly uses size_t not int for  
some intermediate values representing numbers of items.  This would only  
be a live risk when sorting more than INT_MAX bytes (in qsort/qsort_arg)  
or tuples (in qsort_tuple), which I believe would never happen with any  
caller in the current core code --- but perhaps it could happen with  
call sites in third-party modules?  In any case, this is trouble waiting  
to happen, and the corrected code is probably if anything shorter and  
faster than before, since it removes sign-extension steps that had to  
happen when converting between int and size_t.  
  
In passing, move a couple of CHECK_FOR_INTERRUPTS() calls so that it's  
not necessary to preserve the value of "r" across them, and prettify  
the output of gen_qsort_tuple.pl a little.  
  
Back-patch to all supported branches.  The odds of hitting this issue  
are probably higher in 9.4 and up than before, due to the new ability  
to allocate sort workspaces exceeding 1GB, but there's no good reason  
to believe that it's impossible to crash older branches this way.  
  

Fix spelling error

  
commit   : 095b8e158b064b67239cf7030dba8a3c83c11c85    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 16 Jul 2015 10:31:58 +0300    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 16 Jul 2015 10:31:58 +0300    

Click here for diff

  
David Rowley  
  

Fix copy/past error in comment

  
commit   : 34a6c6172e99cb12dd9f079111231052510b78be    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 16 Jul 2015 10:28:44 +0300    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 16 Jul 2015 10:28:44 +0300    

Click here for diff

  
David Christensen  
  

  
commit   : 525a6a0d4580f52c13f0c9b7c9d82a4f96ef92fa    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 15 Jul 2015 21:00:26 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 15 Jul 2015 21:00:26 -0400    

Click here for diff

  
The result closely resembles linking of these modules for the "win32"  
port.  Augment the $(exports_file) header so the file is also usable as  
an import file.  Unfortunately, relocating an AIX installation will now  
require adding $(pkglibdir) to LD_LIBRARY_PATH.  Back-patch to 9.5,  
where the modules were introduced.  
  

  
commit   : c2b824e34e2ba9a26e914a41f4dd53f27304dc70    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 15 Jul 2015 21:00:26 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 15 Jul 2015 21:00:26 -0400    

Click here for diff

  
This allows PostgreSQL modules and their dependencies to have undefined  
symbols, resolved at runtime.  Perl module shared objects rely on that  
in Perl 5.8.0 and later.  This fixes the crash when PL/PerlU loads such  
modules, as the hstore_plperl test suite does.  Module authors can link  
using -Wl,-G to permit undefined symbols; by default, linking will fail  
as it has.  Back-patch to 9.0 (all supported versions).  
  

  
commit   : 21a101848b269e4fff9ccd3a5b5f777911399091    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 15 Jul 2015 21:00:26 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 15 Jul 2015 21:00:26 -0400    

Click here for diff

  
The MSVC build system already did this, and building against Python 3  
requires it.  Back-patch to 9.5, where the module was introduced.  
  

Mention table_rewrite as valid event trigger tag

  
commit   : 8bc8dd81ed215130ab88f12e8ea736d042692630    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 15 Jul 2015 17:08:46 +0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 15 Jul 2015 17:08:46 +0300    

Click here for diff

  
This was forgotten in 618c9430a8.  
  

Remove regression test added on auto-pilot.

  
commit   : 70446994959d67880373b6478ff3fb5f5efd2c87    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jul 2015 16:19:44 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Jul 2015 16:19:44 -0400    

Click here for diff

  
Test does not match the comment which precedes it.  
  
Peter Geoghegan  
  

Prevent pgstattuple() from reporting BRIN as unknown index.

  
commit   : 5658b0dc0425f987c3272a792ea0944bce23a959    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 14 Jul 2015 22:36:51 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 14 Jul 2015 22:36:51 +0900    

Click here for diff

  
Also this patch removes obsolete comment.  
  
Back-patch to 9.5 where BRIN index was added.  
  

Make regression test output stable.

  
commit   : fe92a72a2bf6f485fc9f08c3e6191838ac3c6441    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 Jul 2015 16:16:23 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 Jul 2015 16:16:23 +0300    

Click here for diff

  
In the test query I added for ALTER TABLE retaining comments, the order of  
the result rows was not stable, and varied across systems. Add an ORDER BY  
to make the order predictable. This should fix the buildfarm failures.  
  

Retain comments on indexes and constraints at ALTER TABLE … TYPE …

  
commit   : 9dee48c94b6eb544dd334ec021ff224454f2020f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 Jul 2015 11:40:22 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 Jul 2015 11:40:22 +0300    

Click here for diff

  
When a column's datatype is changed, ATExecAlterColumnType() rebuilds all  
the affected indexes and constraints, and the comments from the old  
indexes/constraints were not carried over.  
  
To fix, create a synthetic COMMENT ON command in the work queue, to re-add  
any comments on constraints. For indexes, there's a comment field in  
IndexStmt that is used.  
  
This fixes bug #13126, reported by Kirill Simonov. Original patch by  
Michael Paquier, reviewed by Petr Jelinek and me. This bug is present in  
all versions, but only backpatch to 9.5. Given how minor the issue is, it  
doesn't seem worth the work and risk to backpatch further than that.  
  

Reformat code in ATPostAlterTypeParse.

  
commit   : 6d5031efcbb4bfadc6a7c2f3c68f05a9281315f4    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 Jul 2015 11:38:08 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 Jul 2015 11:38:08 +0300    

Click here for diff

  
The code in ATPostAlterTypeParse was very deeply indented, mostly because  
there were two nested switch-case statements, which add a lot of  
indentation. Use if-else blocks instead, to make the code less indented  
and more readable.  
  
This is in preparation for next patch that makes some actualy changes to  
the function. These cosmetic parts have been separated to make it easier  
to see the real changes in the other patch.  
  

release notes: markup: vacuumdb is an application, not command

  
commit   : 3096ff924a9d58be7de56e0cae5c8713a51c6b46    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 12 Jul 2015 17:41:57 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 12 Jul 2015 17:41:57 -0400    

Click here for diff

  
  

Fix assorted memory leaks.

  
commit   : 0e78a610f24463f64d8a03b39f06e995581c923a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Jul 2015 16:25:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Jul 2015 16:25:51 -0400    

Click here for diff

  
Per Coverity (not that any of these are so non-obvious that they should not  
have been caught before commit).  The extent of leakage is probably minor  
to unnoticeable, but a leak is a leak.  Back-patch as necessary.  
  
Michael Paquier  
  

For consistency add a pfree to ON CONFLICT set_plan_refs code.

  
commit   : 1884708e25c444eb9de6b0665b94c268bab25689    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 12 Jul 2015 22:18:57 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 12 Jul 2015 22:18:57 +0200    

Click here for diff

  
Backpatch to 9.5 where ON CONFLICT was introduced.  
  
Author: Peter Geoghegan  
  

Optionally don’t error out due to preexisting slots in commandline utilities.

  
commit   : 0e8e48b0da6ea00f3dbcb659542b0c81a97d1253    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 12 Jul 2015 22:06:27 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 12 Jul 2015 22:06:27 +0200    

Click here for diff

  
pg_receivexlog and pg_recvlogical error out when --create-slot is  
specified and a slot with the same name already exists. In some cases,  
especially with pg_receivexlog, that's rather annoying and requires  
additional scripting.  
  
Backpatch to 9.5 as slot control functions have newly been added to  
pg_receivexlog, and there doesn't seem much point leaving it in a less  
useful state.  
  
Discussion: 20150619144755.GG29350@alap3.anarazel.de  
  

Add now-required #include.

  
commit   : ccd062cfb90e68f7e80c4b31c474db9087289b7d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jul 2015 23:34:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jul 2015 23:34:41 -0400    

Click here for diff

  
Fixes compiler warning induced by 808ea8fc7bb259ddd810353719cac66e85a608c8.  
  

doc: fix typo in CREATE POLICY manual page

  
commit   : 5181fc57dfb98b39d059908e04a0628ee6e65efc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 11 Jul 2015 22:46:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 11 Jul 2015 22:46:28 -0400    

Click here for diff

  
Backpatch through 9.5  
  

Add assign_expr_collations() to CreatePolicy() and AlterPolicy().

  
commit   : 7236f5b068ca78bb3e771f62ee1365ba945d4869    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sat, 11 Jul 2015 14:20:01 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sat, 11 Jul 2015 14:20:01 -0700    

Click here for diff

  
As noted by Noah Misch, CreatePolicy() and AlterPolicy() omit to call  
assign_expr_collations() on the node trees. Fix the omission and add  
his test case to the rowsecurity regression test.  
  

Copy-edit the docs changes of OWNER TO CURRENT/SESSION_USER additions.

  
commit   : ebe8bcd94e7191025e0309718284983891a89064    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 10 Jul 2015 14:28:34 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 10 Jul 2015 14:28:34 +0300    

Click here for diff

  
Commit 31eae602 added new syntax to many DDL commands to use CURRENT_USER  
or SESSION_USER instead of role name in ALTER ... OWNER TO, but because  
of a misplaced '{', the syntax in the docs implied that the syntax was  
"ALTER ... CURRENT_USER", instead of "ALTER ... OWNER TO CURRENT_USER".  
Fix that, and also the funny indentation in some of the modified syntax  
blurps.  
  

Improve documentation about array concat operator vs. underlying functions.

  
commit   : 5acc7730c8c93d5755bc6a0bf36df407f48b2b27    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jul 2015 18:50:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jul 2015 18:50:31 -0400    

Click here for diff

  
The documentation implied that there was seldom any reason to use the  
array_append, array_prepend, and array_cat functions directly.  But that's  
not really true, because they can help make it clear which case is meant,  
which the || operator can't do since it's overloaded to represent all three  
cases.  Add some discussion and examples illustrating the potentially  
confusing behavior that can ensue if the parser misinterprets what was  
meant.  
  
Per a complaint from Michael Herold.  Back-patch to 9.2, which is where ||  
started to behave this way.  
  

Fix postmaster’s handling of a startup-process crash.

  
commit   : 193e0270752b07f8d0700710a39c4ec367f57339    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jul 2015 13:22:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jul 2015 13:22:23 -0400    

Click here for diff

  
Ordinarily, a failure (unexpected exit status) of the startup subprocess  
should be considered fatal, so the postmaster should just close up shop  
and quit.  However, if we sent the startup process a SIGQUIT or SIGKILL  
signal, the failure is hardly "unexpected", and we should attempt restart;  
this is necessary for recovery from ordinary backend crashes in hot-standby  
scenarios.  I attempted to implement the latter rule with a two-line patch  
in commit 442231d7f71764b8c628044e7ce2225f9aa43b67, but it now emerges that  
that patch was a few bricks shy of a load: it failed to distinguish the  
case of a signaled startup process from the case where the new startup  
process crashes before reaching database consistency.  That resulted in  
infinitely respawning a new startup process only to have it crash again.  
  
To handle this properly, we really must track whether we have sent the  
*current* startup process a kill signal.  Rather than add yet another  
ad-hoc boolean to the postmaster's state, I chose to unify this with the  
existing RecoveryError flag into an enum tracking the startup process's  
state.  That seems more consistent with the postmaster's general state  
machine design.  
  
Back-patch to 9.0, like the previous patch.  
  

Make wal_compression PGC_SUSET rather than PGC_USERSET.

  
commit   : 19a65458159ca5f46d8ac154e62273fa2a8cf13f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Jul 2015 22:30:52 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Jul 2015 22:30:52 +0900    

Click here for diff

  
When enabling wal_compression, there is a risk to leak data similarly to  
the BREACH and CRIME attacks on SSL where the compression ratio of  
a full page image gives a hint of what is the existing data of this page.  
This vulnerability is quite cumbersome to exploit in practice, but doable.  
  
So this patch makes wal_compression PGC_SUSET in order to prevent  
non-superusers from enabling it and exploiting the vulnerability while  
DBA thinks the risk very seriously and disables it in postgresql.conf.  
  
Back-patch to 9.5 where wal_compression was introduced.  
  

  
commit   : 1a0959b3887f05e55712e1ef27b7d1b3c75d645f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2015 16:00:14 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2015 16:00:14 +0300    

Click here for diff

  
Tom fixed another one of these in commit 7f32dbcd, but there was another  
almost identical one in libpq docs. Per his comment:  
  
HP's web server has apparently become case-sensitive sometime recently.  
Per bug #13479 from Daniel Abraham.  Corrected link identified by Alvaro.  
  

Revert changes to pthread configure tests on REL9_5_STABLE.

  
commit   : 7f06c7082a34f4ea564e31ee01114784a788b9fa    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2015 10:58:24 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2015 10:58:24 +0300    

Click here for diff

  
Some buildfarm animals are still unhappy. These changes are becoming too  
invasive for backpatch, for little benefit. This reverts commits  
080c4dab3d9575449b81604051b160597cfd55c3 and  
ce0da6261004ac15f01c21d8b94f11af7a098243.  
  

  
commit   : c1fb42127944d5613df2f3d330c19448fc10ed01    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 8 Jul 2015 20:44:22 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 8 Jul 2015 20:44:22 -0400    

Click here for diff

  
The AIX 7.1 libm is static, and AIX postgres executables do not export  
symbols acquired from libraries.  Back-patch to 9.5, where commit  
cfe12763c32437bc708a64ce88a90c7544f16185 added a sqrt() call.  
  

Given a gcc-compatible xlc compiler, prefer xlc-style atomics.

  
commit   : c0d7342f1650b6fdefc865c6da33e1f092778af0    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 8 Jul 2015 20:44:21 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 8 Jul 2015 20:44:21 -0400    

Click here for diff

  
This evades a ppc64le "IBM XL C/C++ for Linux" compiler bug.  Back-patch  
to 9.5, where the atomics facility was introduced.  
  

Finish generic-xlc.h draft atomics implementation.

  
commit   : abf5190c07a7e4de2b10b01dc38723aaa28339f6    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 8 Jul 2015 20:44:21 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 8 Jul 2015 20:44:21 -0400    

Click here for diff

  
Back-patch to 9.5, where commit b64d92f1a5602c55ee8b27a7ac474f03b7aee340  
introduced this file.  
  

Revoke support for strxfrm() that write past the specified array length.

  
commit   : aaf15ee33a63c582fbb61b67befdd620e85da2ce    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 8 Jul 2015 20:44:21 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 8 Jul 2015 20:44:21 -0400    

Click here for diff

  
This formalizes a decision implicit in commit  
4ea51cdfe85ceef8afabceb03c446574daa0ac23 and adds clean detection of  
affected systems.  Vendor updates are available for each such known bug.  
Back-patch to 9.5, where the aforementioned commit first appeared.  
  

Replace use of “diff -q”.

  
commit   : 8ed6e70ace8e8d2f0747c16a796a21147ffaf404    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 8 Jul 2015 20:44:21 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 8 Jul 2015 20:44:21 -0400    

Click here for diff

  
POSIX does not specify the -q option, and many implementations do not  
offer it.  Don't bother changing the MSVC build system, because having  
non-GNU diff on Windows is vanishingly unlikely.  Back-patch to 9.2,  
where this invocation was introduced.  
  

Fix null pointer dereference in “\c” psql command.

  
commit   : fb990ce6c7d99d329843e5d70d4cdaf8d0825b38    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 8 Jul 2015 20:44:21 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 8 Jul 2015 20:44:21 -0400    

Click here for diff

  
The psql crash happened when no current connection existed.  (The second  
new check is optional given today's undocumented NULL argument handling  
in PQhost() etc.)  Back-patch to 9.0 (all supported versions).  
  

Move pthread-tests earlier in the autoconf script.

  
commit   : 080c4dab3d9575449b81604051b160597cfd55c3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2015 00:05:45 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 9 Jul 2015 00:05:45 +0300    

Click here for diff

  
On some Linux systems, "-lrt" exposed pthread-functions, so that linking  
with -lrt was seemingly enough to make a program that uses pthreads to  
work. However, when linking libpq, the dependency to libpthread was not  
marked correctly, so that when an executable was linked with -lpq but  
without -pthread, you got errors about undefined pthread_* functions from  
libpq.  
  
To fix, test for the flags required to use pthreads earlier in the autoconf  
script, before checking any other libraries.  
  
This should fix the failure on buildfarm member shearwater. gharial is also  
failing; hopefully this fixes that too although the failure looks somewhat  
different.  
  

Replace our hacked version of ax_pthread.m4 with latest upstream version.

  
commit   : ce0da6261004ac15f01c21d8b94f11af7a098243    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jul 2015 20:36:06 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jul 2015 20:36:06 +0300    

Click here for diff

  
Our version was different from the upstream version in that we tried to use  
all possible pthread-related flags that the compiler accepts, rather than  
just the first one that works. That change was made in commit  
e48322a6d6cfce1ec52ab303441df329ddbc04d1, to work-around a bug affecting GCC  
versions 3.2 and below (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8888),  
although we didn't realize that it was a GCC bug at the time. We hardly care  
about that old GCC versions anymore, so we no longer need that workaround.  
  
This fixes the macro for compilers that print warnings with the chosen  
flags. That's pretty annoying on its own right, but it also inconspicuously  
disabled thread-safety, because we refused to use any pthread-related flags  
if the compiler produced warnings. Max Filippov reported that problem when  
linking with uClibc and OpenSSL. The warnings-check was added because the  
workaround for the GCC bug caused warnings otherwise, so it's no longer  
needed either. We can just use the upstream version as is.  
  
If you really want to compile with GCC version 3.2 or older, you can still  
work-around it manually by setting PTHREAD_CFLAGS="-pthread -lpthread"  
manually on the configure command line.  
  
Backpatch to 9.5. I don't want to unnecessarily rock the boat on stable  
branches, but 9.5 seems like fair game.  
  

Improve regression test coverage of table lock modes vs permissions.

  
commit   : d5f551abcf78cb4e3f6c5d195bd260893443414b    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Tue, 7 Jul 2015 14:36:03 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Tue, 7 Jul 2015 14:36:03 -0700    

Click here for diff

  
Test the interactions with permissions and LOCK TABLE. Specifically  
ROW EXCLUSIVE, ACCESS SHARE, and ACCESS EXCLUSIVE modes against  
SELECT, INSERT, UPDATE, DELETE, and TRUNCATE permissions. Discussed  
by Stephen Frost and Michael Paquier, patch by the latter. Backpatch  
to 9.5 where matching behavior was first committed.  
  

Fix incorrect path in pg_regress log messages.

  
commit   : de184e57e894b13f51c4f30788d20f385b547048    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2015 01:54:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Jul 2015 01:54:17 +0900    

Click here for diff

  
Back-patch to 9.5 where the bug was introduced.  
  
David Christensen  
  

Fix portability issue in pg_upgrade test script: avoid $PWD.

  
commit   : bb67e357b2607eea3e7c929520945a61b8cff546    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Jul 2015 12:49:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Jul 2015 12:49:18 -0400    

Click here for diff

  
SUSv2-era shells don't set the PWD variable, though anything more modern  
does.  In the buildfarm environment this could lead to test.sh executing  
with PWD pointing to $HOME or another high-level directory, so that there  
were conflicts between concurrent executions of the test in different  
branch subdirectories.  This appears to be the explanation for recent  
intermittent failures on buildfarm members binturong and dingo (and might  
well have something to do with the buildfarm script's failure to capture  
log files from pg_upgrade tests, too).  
  
To fix, just use `pwd` in place of $PWD.  AFAICS test.sh is the only place  
in our source tree that depended on $PWD.  Back-patch to all versions  
containing this script.  
  
Per buildfarm.  Thanks to Oskari Saarenmaa for diagnosing the problem.  
  

Improve handling of out-of-memory in libpq.

  
commit   : 28c38396eda2d923974b99013b27e89a9093c766    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2015 18:37:45 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2015 18:37:45 +0300    

Click here for diff

  
If an allocation fails in the main message handling loop, pqParseInput3  
or pqParseInput2, it should not be treated as "not enough data available  
yet". Otherwise libpq will wait indefinitely for more data to arrive from  
the server, and gets stuck forever.  
  
This isn't a complete fix - getParamDescriptions and getCopyStart still  
have the same issue, but it's a step in the right direction.  
  
Michael Paquier and me. Backpatch to all supported versions.  
  

Add tab-completion for psql meta-commands.

  
commit   : 162ae5b9bb6542809453fbe9cfbb6468cb8eb06e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 7 Jul 2015 23:24:02 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 7 Jul 2015 23:24:02 +0900    

Click here for diff

  
Based on the original code from David Christensen, modified by me.  
  

Turn install.bat into a pure one line wrapper fort he perl script.

  
commit   : e5460aa02fd0e3e51b57aac1d15b3d2b494aac57    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2015 16:31:52 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2015 16:31:52 +0300    

Click here for diff

  
Build.bat and vcregress.bat got similar treatment years ago. I'm not sure  
why install.bat wasn't treated at the same time, but it seems like a good  
idea anyway.  
  
The immediate problem with the old install.bat was that it had quoting  
issues, and wouldn't work if the target directory's name contained spaces.  
This fixes that problem.  
  
I committed this to master yesterday, this is a backpatch of the same for  
all supported versions.  
  

Fix logical decoding bug leading to inefficient reopening of files.

  
commit   : cf051c4f9d4e990e5fce0a00bacb47b4e64261d6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 7 Jul 2015 13:13:15 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 7 Jul 2015 13:13:15 +0200    

Click here for diff

  
When spilling transaction data to disk a simple typo caused the output  
file to be closed and reopened for every serialized change. That happens  
to not have a huge impact on linux, which is why it probably wasn't  
noticed so far, but on windows that appears to trigger actual disk  
writes after every change. Not fun.  
  
The bug fortunately does not have any impact besides speed. A change  
could end up being in the wrong segment (last instead of next), but  
since we read all files to the end, that's just ugly, not really  
problematic. It's not a problem to upgrade, since transaction spill  
files do not persist across restarts.  
  
Bug: #13484  
Reported-By: Olivier Gosseaume  
Discussion: 20150703090217.1190.63940@wrigleys.postgresql.org  
  
Backpatch to 9.4, where logical decoding was added.  
  

Fix pg_recvlogical not to fsync output when it’s a tty or pipe.

  
commit   : 8022b0a35f7c4e71908a878c8c412b5c2ae8536c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 7 Jul 2015 12:47:44 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 7 Jul 2015 12:47:44 +0200    

Click here for diff

  
The previous coding tried to handle possible failures when fsyncing a  
tty or pipe fd by accepting EINVAL - but apparently some  
platforms (windows, OSX) don't reliably return that. So instead check  
whether the output fd refers to a pipe or a tty when opening it.  
  
Reported-By: Olivier Gosseaume, Marko Tiikkaja  
Discussion: 559AF98B.3050901@joh.to  
  
Backpatch to 9.4, where pg_recvlogical was added.  
  

  
commit   : 2867f26fecafc6d9930eb751abdd7b80359a6f51    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Mon, 6 Jul 2015 19:17:57 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Mon, 6 Jul 2015 19:17:57 -0700    

Click here for diff

  
Also updated regression expected output to match. Noted and patch by Daniele Varrazzo.  
  

Remove incorrect warning from pg_archivecleanup document.

  
commit   : a830c83c9b71b78c65c5ddd71db2ecd68601ce73    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 6 Jul 2015 20:58:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 6 Jul 2015 20:58:58 +0900    

Click here for diff

  
The .backup file name can be passed to pg_archivecleanup even if  
it includes the extension which is specified in -x option.  
However, previously the document incorrectly warned a user  
not to do that.  
  
Back-patch to 9.2 where pg_archivecleanup's -x option and  
the warning were added.  
  

Make a editorial pass over pgbench’s error messages.

  
commit   : c7673d2b1fd54caa82c9870927d0bef6518bb461    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jul 2015 19:36:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jul 2015 19:36:57 -0400    

Click here for diff

  
The lack of consistency, and lack of attention to our message style  
guidelines, was a bit striking.  Try to make 'em better.  
  

Fix some typos in regression test comments.

  
commit   : 486d3a2bb4b9e4c1cc64241f4b36643a22da8693    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jul 2015 13:14:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jul 2015 13:14:38 -0400    

Click here for diff

  
Back-patch to avoid unnecessary cross-branch differences.  
  
CharSyam  
  

Fix bad grammar in brin.sgml.

  
commit   : 9a92ad4b9eec0051296d6475feb9c9955c860a9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jul 2015 12:08:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jul 2015 12:08:15 -0400    

Click here for diff

  
Christoph Berg  
  

Make numeric form of PG version number readily available in Makefiles.

  
commit   : d1fec374f716ffbfb9f9a758c9b5b23c00f01fcb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jul 2015 12:01:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jul 2015 12:01:01 -0400    

Click here for diff

  
Expose PG_VERSION_NUM (e.g., "90600") as a Make variable; but for  
consistency with the other Make variables holding similar info,  
call the variable just VERSION_NUM not PG_VERSION_NUM.  
  
There was some discussion of making this value available as a pg_config  
value as well.  However, that would entail substantially more work than  
this two-line patch.  Given that there was not exactly universal consensus  
that we need this at all, let's just do a minimal amount of work for now.  
  
Back-patch of commit a5d489ccb7e613c7ca3be6141092b8c1d2c13fa7, so that this  
variable is actually useful for its intended purpose sometime before 2020.  
  
Michael Paquier, reviewed by Pavel Stehule  
  

Fix pgbench progress report behaviour when pgbench or a query gets stuck.

  
commit   : 5174ca17a2479e9f9844d72cc6e777f473f83566    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 3 Jul 2015 11:04:57 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 3 Jul 2015 11:04:57 +0300    

Click here for diff

  
There were two issues here. First, if a query got stuck so that it took  
e.g. 5 seconds, and progress interval was 1 second, no progress reports were  
printed until the query returned. Fix so that we wake up specifically to  
print the progress report. Secondly, if pgbench got stuck so that it would  
nevertheless not print a progress report on time, and enough time passes  
that it's already time to print the next progress report, just skip the one  
that was missed. Before this patch, it would print the missed one with 0 TPS  
immediately after the previous one.  
  
Fabien Coelho. Backpatch to 9.4, where progress reports were added.  
  

  
commit   : eeaf1b6afacba0fc0a0e1878c2ed23f4fceef039    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Jul 2015 11:53:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Jul 2015 11:53:58 +0900    

Click here for diff

  
Commit de76884 changed an archive recovery so that the last WAL  
segment with old timeline was renamed with suffix .partial. It should  
have updated WAL-related utilities so that they can handle such  
.paritial WAL files, but we forgot that.  
  
This patch changes pg_archivecleanup so that it can clean up even  
archived WAL files with .partial suffix. Also it allows us to specify  
.partial WAL file name as the command-line argument "oldestkeptwalfile".  
  
This patch also changes pg_resetxlog so that it can remove .partial  
WAL files in pg_xlog directory.  
  
pg_xlogdump cannot handle .partial WAL files. Per discussion,  
we decided only to document that limitation instead of adding the fix.  
Because a user can easily work around the limitation (i.e., just remove  
.partial suffix from the file name) and the fix seems complicated for  
very narrow use case.  
  
Back-patch to 9.5 where the problem existed.  
  
Review by Michael Paquier.  
Discussion: http://www.postgresql.org/message-id/CAHGQGwGxMKnVHGgTfiig2Bt_2djec0in3-DLJmtg7+nEiidFdQ@mail.gmail.com  
  

Fix misuse of TextDatumGetCString().

  
commit   : 69e9f9639d5c569a71c82f99550e7bf2912664f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jul 2015 17:02:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jul 2015 17:02:08 -0400    

Click here for diff

  
"TextDatumGetCString(PG_GETARG_TEXT_P(x))" is formally wrong: a text*  
is not a Datum.  Although this coding will accidentally fail to fail on  
all known platforms, it risks leaking memory if a detoast step is needed,  
unlike "TextDatumGetCString(PG_GETARG_DATUM(x))" which is what's used  
elsewhere.  Make pg_get_object_address() fall in line with other uses.  
  
Noted while reviewing two-arg current_setting() patch.  
  

Whitespace fix - replace tab with spaces in CREATE TABLE command.

  
commit   : cf2b5f9b33fda1cbeb8efdfd3989b5e88af74167    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Thu, 2 Jul 2015 09:46:34 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Thu, 2 Jul 2015 09:46:34 -0700    

Click here for diff

  
  

Don’t emit a spurious space at end of line in pg_dump of event triggers.

  
commit   : bcac470d5b8762629132428ddf8fc8f1baa701f3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 2 Jul 2015 12:50:29 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 2 Jul 2015 12:50:29 +0300    

Click here for diff

  
Backpatch to 9.3 and above, where event triggers were added.  
  

Use appendStringInfoString/Char et al where appropriate.

  
commit   : 02ec4cd179099fc409288bb55c40fea308a51204    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 2 Jul 2015 12:32:48 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 2 Jul 2015 12:32:48 +0300    

Click here for diff

  
Patch by David Rowley. Backpatch to 9.5, as some of the calls were new in  
9.5, and keeping the code in sync with master makes future backpatching  
easier.  
  

Fix name of argument to pg_stat_file.

  
commit   : 00ccea9e9dcee7b4f103674d274fadc8b09075f7    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 2 Jul 2015 12:12:05 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 2 Jul 2015 12:12:05 +0300    

Click here for diff

  
It's called "missing_ok" in the docs and in the C code.  
  
I refrained from doing a catversion bump for this, because the name of an  
input argument is just documentation, it has no effect on any callers.  
  
Michael Paquier  
  

Use American spelling for “behavior”.

  
commit   : 6c29ef48811d33fece01962b3be72511f1b1014e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 2 Jul 2015 12:11:32 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 2 Jul 2015 12:11:32 +0300    

Click here for diff

  
For consistency with the rest of the docs.  
  
Michael Paquier  
  

Allow MSVC’s contribcheck and modulescheck to run independently.

  
commit   : e1d273efde7828947e52bb531851f67f91c628c3    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 1 Jul 2015 23:28:41 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 1 Jul 2015 23:28:41 -0400    

Click here for diff

  
These require a temp install to have been done, so we now make sure it  
is done before proceeding.  
  
Michael Paquier.  
  

  
commit   : 163e29dc380137127cf7e9c23b1596b78ad0ce81    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 2 Jul 2015 10:35:38 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 2 Jul 2015 10:35:38 +0900    

Click here for diff

  
Commit 179cdd09 added macros to check if a filename is a WAL segment  
or other such file. However there were still some instances of the  
strlen + strspn combination to check for that in WAL-related utilities  
like pg_archivecleanup. Those checks can be replaced with the macros.  
  
This patch makes use of the macros in those utilities and  
which would make the code a bit easier to read.  
  
Back-patch to 9.5.  
  
Michael Paquier  
  

Make sampler_random_fract() actually obey its API contract.

  
commit   : cd7030ff085f5c378e837b392cb719cf23df9d0b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Jul 2015 18:07:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Jul 2015 18:07:48 -0400    

Click here for diff

  
This function is documented to return a value in the range (0,1),  
which is what its predecessor anl_random_fract() did.  However, the  
new version depends on pg_erand48() which returns a value in [0,1).  
The possibility of returning zero creates hazards of division by zero  
or trying to compute log(0) at some call sites, and it might well  
break third-party modules using anl_random_fract() too.  So let's  
change it to never return zero.  Spotted by Coverity.  
  
Michael Paquier, cosmetically adjusted by me  
  

Make XLogFileCopy() look the same as in 9.4.

  
commit   : 6cfb6d987419ce1e7bec0cf3ad22830ed3c2dc08    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 1 Jul 2015 10:54:47 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 1 Jul 2015 10:54:47 +0900    

Click here for diff

  
XLogFileCopy() was changed heavily in commit de76884. However it was  
partially reverted in commit 7abc685 and most of those changes to  
XLogFileCopy() were no longer needed. Then commit 7cbee7c removed  
those unnecessary code, but XLogFileCopy() looked different in master  
and 9.4 though the contents are almost the same.  
  
This patch makes XLogFileCopy() look the same in master and back-branches,  
which makes back-patching easier, per discussion on pgsql-hackers.  
Back-patch to 9.5.  
  
Discussion: 55760844.7090703@iki.fi  
  
Michael Paquier  
  

  
commit   : 31380b900ee427e86ffff2d873c3fe0f4417f8c9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Jun 2015 18:47:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Jun 2015 18:47:32 -0400    

Click here for diff

  
HP's web server has apparently become case-sensitive sometime recently.  
Per bug #13479 from Daniel Abraham.  Corrected link identified by Alvaro.  
  

Test -lrt for sched_yield

  
commit   : ab93f90cd3a4fcdd891cee9478941c3cc65795b8    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 30 Jun 2015 14:20:38 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 30 Jun 2015 14:20:38 -0300    

Click here for diff

  
Apparently, this is needed in some Solaris versions.  
  
Author: Oskari Saarenmaa  
  

Remove useless check for NULL subexpression.

  
commit   : 131926a52da0fbd77678cbd887914c83b48faa2d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Jun 2015 12:53:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Jun 2015 12:53:54 -0400    

Click here for diff

  
Coverity rightly gripes that it's silly to have a test here when  
the adjacent ExecEvalExpr() would choke on a NULL expression pointer.  
  
Petr Jelinek  
  

Add assertion to check the special size is sane before dereferencing it.

  
commit   : 302ac7f27197855afa8c89fae36c85c124ae156b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jun 2015 13:44:04 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jun 2015 13:44:04 +0300    

Click here for diff

  
This seems useful to catch errors of the sort I just fixed, where  
PageGetSpecialPointer is called before initializing the page.  
  

Don’t call PageGetSpecialPointer() on page until it’s been initialized.

  
commit   : fdf28853ae6a397497b79fea69f89f4f7b9aa991    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jun 2015 13:37:16 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jun 2015 13:37:16 +0300    

Click here for diff

  
After calling XLogInitBufferForRedo(), the page might be all-zeros if it was  
not in page cache already. btree_xlog_unlink_page initialized the page  
correctly, but it called PageGetSpecialPointer before initializing it, which  
would lead to a corrupt page at WAL replay, if the unlinked page is not in  
page cache.  
  
Backpatch to 9.4, the bug came with the rewrite of B-tree page deletion.  
  

In bttext_abbrev_convert, move pfree to the right place.

  
commit   : b48ecf862b3896631660ee8d38054aded82a4f8b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 29 Jun 2015 23:53:05 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 29 Jun 2015 23:53:05 -0400    

Click here for diff

  
Without this, we might access memory that's already been freed, or  
leak memory if in the C locale.  
  
Peter Geoghegan  
  

Initialize GIN metapage correctly when replaying metapage-update WAL record.

  
commit   : 47fe4d25d57c81b9d7b2ac88783a12ee487db220    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jun 2015 00:06:00 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jun 2015 00:06:00 +0300    

Click here for diff

  
I broke this with my WAL format refactoring patch. Before that, the metapage  
was read from disk, and modified in-place regardless of the LSN. That was  
always a bit silly, as there's no need to read the old page version from  
disk disk when we're overwriting it anyway. So that was changed in 9.5, but  
I failed to add a GinInitPage call to initialize the page-headers correctly.  
Usually you wouldn't notice, because the metapage is already in the page  
cache and is not zeroed.  
  
One way to reproduce this is to perform a VACUUM on an already vacuumed  
table (so that the vacuum has no real work to do), immediately after a  
checkpoint, and then perform an immediate shutdown. After recovery, the  
page headers of the metapage will be incorrectly all-zeroes.  
  
Reported by Jeff Janes  
  

Stamp 9.5alpha1.

  
commit   : f78329d594c2fe893f9174d5b3da7d3fbc6dd8b6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jun 2015 15:42:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jun 2015 15:42:18 -0400    

Click here for diff

  
  

Desultory review of 9.5 release notes.

  
commit   : 85c25fdbd7d624928bb8a1f1fd1e5043ec35dd74    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jun 2015 15:38:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jun 2015 15:38:46 -0400    

Click here for diff

  
Minor corrections and clarifications.  Notably, for stuff that got moved  
out of contrib, make sure it's documented somewhere other than "Additional  
Modules".  
  
I'm sure these need more work, but that's all I have time for today.  
  

Code + docs review for escaping of option values (commit 11a020eb6).

  
commit   : cbc8d65639344c390a1d1a7f646c186ff3ad8693    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jun 2015 12:42:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jun 2015 12:42:52 -0400    

Click here for diff

  
Avoid memory leak from incorrect choice of how to free a StringInfo  
(resetStringInfo doesn't do it).  Now that pg_split_opts doesn't scribble  
on the optstr, mark that as "const" for clarity.  Attach the commentary in  
protocol.sgml to the right place, and add documentation about the  
user-visible effects of this change on postgres' -o option and libpq's  
PGOPTIONS option.  
  

Replace ia64 S_UNLOCK compiler barrier with a full memory barrier.

  
commit   : 07cb8b02ab4c8b65bb2e3b87ad2402fdc6cce978    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 29 Jun 2015 14:53:32 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 29 Jun 2015 14:53:32 +0200    

Click here for diff

  
_Asm_sched_fence() is just a compiler barrier, not a memory barrier. But  
spinlock release on IA64 needs, at the very least, release  
semantics. Use a full barrier instead.  
  
This might be the cause for the occasional failures on buildfarm member  
anole.  
  
Discussion: 20150629101108.GB17640@alap3.anarazel.de  
  

Translation updates

  
commit   : c5e5d444de85a7caff462443c5915544d4406a62    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 28 Jun 2015 23:56:55 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 28 Jun 2015 23:56:55 -0400    

Click here for diff

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

Run the C portions of guc-file.l through pgindent.

  
commit   : 2bdc51a2946f9a66688eb705cd0cb584ebd8240a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Jun 2015 20:49:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Jun 2015 20:49:35 -0400    

Click here for diff

  
Yeah, I know, pretty anal-retentive of me.  But we oughta find some  
way to automate this for the .y and .l files.  
  

Improve design and implementation of pg_file_settings view.

  
commit   : 62d16c7fc5614d9f4d0dd1a9f164b232c273c128    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Jun 2015 18:06:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Jun 2015 18:06:14 -0400    

Click here for diff

  
As first committed, this view reported on the file contents as they were  
at the last SIGHUP event.  That's not as useful as reporting on the current  
contents, and what's more, it didn't work right on Windows unless the  
current session had serviced at least one SIGHUP.  Therefore, arrange to  
re-read the files when pg_show_all_settings() is called.  This requires  
only minor refactoring so that we can pass changeVal = false to  
set_config_option() so that it won't actually apply any changes locally.  
  
In addition, add error reporting so that errors that would prevent the  
configuration files from being loaded, or would prevent individual settings  
from being applied, are visible directly in the view.  This makes the view  
usable for pre-testing whether edits made in the config files will have the  
desired effect, before one actually issues a SIGHUP.  
  
I also added an "applied" column so that it's easy to identify entries that  
are superseded by later entries; this was the main use-case for the original  
design, but it seemed unnecessarily hard to use for that.  
  
Also fix a 9.4.1 regression that allowed multiple entries for a  
PGC_POSTMASTER variable to cause bogus complaints in the postmaster log.  
(The issue here was that commit bf007a27acd7b2fb unintentionally reverted  
3e3f65973a3c94a6, which suppressed any duplicate entries within  
ParseConfigFp.  However, since the original coding of the pg_file_settings  
view depended on such suppression *not* happening, we couldn't have fixed  
this issue now without first doing something with pg_file_settings.  
Now we suppress duplicates by marking them "ignored" within  
ProcessConfigFileInternal, which doesn't hide them in the view.)  
  
Lesser changes include:  
  
Drive the view directly off the ConfigVariable list, instead of making a  
basically-equivalent second copy of the data.  There's no longer any need  
to hang onto the data permanently, anyway.  
  
Convert show_all_file_settings() to do its work in one call and return a  
tuplestore; this avoids risks associated with assuming that the GUC state  
will hold still over the course of query execution.  (I think there were  
probably latent bugs here, though you might need something like a cursor  
on the view to expose them.)  
  
Arrange to run SIGHUP processing in a short-lived memory context, to  
forestall process-lifespan memory leaks.  (There is one known leak in this  
code, in ProcessConfigDirectory; it seems minor enough to not be worth  
back-patching a specific fix for.)  
  
Remove mistaken assignment to ConfigFileLineno that caused line counting  
after an include_dir directive to be completely wrong.  
  
Add missed failure check in AlterSystemSetConfigFile().  We don't really  
expect ParseConfigFp() to fail, but that's not an excuse for not checking.  
  

Also trigger restartpoints based on max_wal_size on standby.

  
commit   : d661532e27b34e9c89d0700c6ce246731e70072c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 29 Jun 2015 00:09:10 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 29 Jun 2015 00:09:10 +0300    

Click here for diff

  
When archive recovery and restartpoints were initially introduced,  
checkpoint_segments was ignored on the grounds that the files restored from  
archive don't consume any space in the recovery server. That was changed in  
later releases, but even then it was arguably a feature rather than a bug,  
as performing restartpoints as often as checkpoints during normal operation  
might be excessive, but you might nevertheless not want to waste a lot of  
space for pre-allocated WAL by setting checkpoint_segments to a high value.  
But now that we have separate min_wal_size and max_wal_size settings, you  
can bound WAL usage with max_wal_size, and still avoid consuming excessive  
space usage by setting min_wal_size to a lower value, so that argument is  
moot.  
  
There are still some issues with actually limiting the space usage to  
max_wal_size: restartpoints in recovery can only start after seeing the  
checkpoint record, while a checkpoint starts flushing buffers as soon as  
the redo-pointer is set. Restartpoint is paced to happen at the same  
leisurily speed, determined by checkpoint_completion_target, as checkpoints,  
but because they are started later, max_wal_size can be exceeded by upto  
one checkpoint cycle's worth of WAL, depending on  
checkpoint_completion_target. But that seems better than not trying at all,  
and max_wal_size is a soft limit anyway.  
  
The documentation already claimed that max_wal_size is obeyed in recovery,  
so this just fixes the behaviour to match the docs. However, add some  
weasel-words there to mention that max_wal_size may well be exceeded by  
some amount in recovery.  
  

Fix markup in docs.

  
commit   : 6ab4d38ab085b0177d7ce63f7e1f2fb3f3a8e4a5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 29 Jun 2015 00:01:26 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 29 Jun 2015 00:01:26 +0300    

Click here for diff

  
Oops. I could swear I built the docs before pushing, but I guess not..  
  

Promote the assertion that XLogBeginInsert() is not called twice into ERROR.

  
commit   : a32c3ec893cafbd3a4b42c34270a80198f28f123    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 28 Jun 2015 22:25:55 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 28 Jun 2015 22:25:55 +0300    

Click here for diff

  
Seems like cheap insurance for WAL bugs. A spurious call to  
XLogBeginInsert() in itself would be fairly harmless, but if there is any  
data registered and the insertion is not completed/cancelled properly, there  
is a risk that the data ends up in a wrong WAL record.  
  
Per Jeff Janes's suggestion.  
  

Fix double-XLogBeginInsert call in GIN page splits.

  
commit   : a45c70acf35e43257d86313dcbb7bb0e5201fab1    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 28 Jun 2015 21:59:29 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 28 Jun 2015 21:59:29 +0300    

Click here for diff

  
If data checksums or wal_log_hints is on, and a GIN page is split, the code  
to find a new, empty, block was called after having already called  
XLogBeginInsert(). That causes an assertion failure or PANIC, if finding the  
new block involves updating a FSM page that had not been modified since last  
checkpoint, because that update is WAL-logged, which calls XLogBeginInsert  
again. Nested XLogBeginInsert calls are not supported.  
  
To fix, rearrange GIN code so that XLogBeginInsert is called later, after  
finding the victim buffers.  
  
Reported by Jeff Janes.  
  

Don’t choke on files that are removed while pg_rewind runs.

  
commit   : b36805f3c54fe0e50e58bb9e6dad66daca46fbf6    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 28 Jun 2015 21:35:51 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 28 Jun 2015 21:35:51 +0300    

Click here for diff

  
If a file is removed from the source server, while pg_rewind is running, the  
invocation of pg_read_binary_file() will fail. Use the just-added missing_ok  
option to that function, to have it return NULL instead, and handle that  
gracefully. And similarly for pg_ls_dir and pg_stat_file.  
  
Reported by Fujii Masao, fix by Michael Paquier.  
  

Add missing_ok option to the SQL functions for reading files.

  
commit   : cb2acb1081e13b4b27a76c6b5311115528e49c59    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 28 Jun 2015 21:35:46 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 28 Jun 2015 21:35:46 +0300    

Click here for diff

  
This makes it possible to use the functions without getting errors, if there  
is a chance that the file might be removed or renamed concurrently.  
pg_rewind needs to do just that, although this could be useful for other  
purposes too. (The changes to pg_rewind to use these functions will come in  
a separate commit.)  
  
The read_binary_file() function isn't very well-suited for extensions.c's  
purposes anymore, if it ever was. So bite the bullet and make a copy of it  
in extension.c, tailored for that use case. This seems better than the  
accidental code reuse, even if it's a some more lines of code.  
  
Michael Paquier, with plenty of kibitzing by me.  
  

Fix comment for GetCurrentIntegerTimestamp().

  
commit   : cca8ba9529f8815acd23fe88c32763765d0e1b68    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 28 Jun 2015 12:43:59 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 28 Jun 2015 12:43:59 -0500    

Click here for diff

  
The unit of measure is microseconds, not milliseconds.  
  
Backpatch to 9.3 where the function and its comment were added.  
  

Fix function declaration style to respect the coding standard.

  
commit   : 527e6d3f099df22783465ca7046fc0c8a534c921    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 28 Jun 2015 18:54:27 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 28 Jun 2015 18:54:27 +0900    

Click here for diff

  
  

Avoid passing NULL to memcmp() in lookups of zero-argument functions.

  
commit   : 0a52d378b03b7d5ab1d64627a87edaf5ed311c6c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jun 2015 17:47:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jun 2015 17:47:39 -0400    

Click here for diff

  
A few places assumed they could pass NULL for the argtypes array when  
looking up functions known to have zero arguments.  At first glance  
it seems that this should be safe enough, since memcmp() is surely not  
allowed to fetch any bytes if its count argument is zero.  However,  
close reading of the C standard says that such calls have undefined  
behavior, so we'd probably best avoid it.  
  
Since the number of places doing this is quite small, and some other  
places looking up zero-argument functions were already passing dummy  
arrays, let's standardize on the latter solution rather than hacking  
the function lookup code to avoid calling memcmp() in these cases.  
I also added Asserts to catch any future violations of the new rule.  
  
Given the utter lack of any evidence that this actually causes any  
problems in the field, I don't feel a need to back-patch this change.  
  
Per report from Piotr Stefaniak, though this is not his patch.  
  

Fix test_decoding’s handling of nonexistant columns in old tuple versions.

  
commit   : d47a1136e441cebe7ae7fe72d70eb8ce278d5cd6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 27 Jun 2015 18:49:00 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 27 Jun 2015 18:49:00 +0200    

Click here for diff

  
test_decoding used fastgetattr() to extract column values. That's wrong  
when decoding updates and deletes if a table's replica identity is set  
to FULL and new columns have been added since the old version of the  
tuple was created. Due to the lack of a crosscheck with the datum's  
natts values an invalid value will be output, leading to errors or  
worse.  
  
Bug: #13470  
Reported-By: Krzysztof Kotlarski  
Discussion: 20150626100333.3874.90852@wrigleys.postgresql.org  
  
Backpatch to 9.4, where the feature, including the bug, was added.  
  

Add opaque declaration of HTAB to tqual.h.

  
commit   : 604e99396de02f6f23950ee373c13335d2ccdf05    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 27 Jun 2015 09:55:06 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 27 Jun 2015 09:55:06 -0500    

Click here for diff

  
Commit b89e151054a05f0f6d356ca52e3b725dd0505e53 added the  
ResolveCminCmaxDuringDecoding declaration to tqual.h, which uses an  
HTAB parameter, without declaring HTAB.  It accidentally fails to  
fail to build with current sources because a declaration happens to  
be included, directly or indirectly, in all source files that  
currently use tqual.h before tqual.h is first included, but we  
shouldn't count on that.  Since an opaque declaration is enough  
here, just use that, as was done in snapmgr.h.  
  
Backpatch to 9.4, where the HTAB reference was added to tqual.h.  
  

Fix typo in comment

  
commit   : 7845db2aa778aa751b41cff72c41c94993e975e3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 27 Jun 2015 10:17:42 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 27 Jun 2015 10:17:42 +0300    

Click here for diff

  
Etsuro Fujita  
  

Avoid hot standby cancels from VAC FREEZE

  
commit   : 66fbcb0d2e1b201477dd2977b6eb93b1cfd9dd6c    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 27 Jun 2015 00:41:47 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 27 Jun 2015 00:41:47 +0100    

Click here for diff

  
VACUUM FREEZE generated false cancelations of standby queries on an  
otherwise idle master. Caused by an off-by-one error on cutoff_xid  
which goes back to original commit.  
  
Backpatch to all versions 9.0+  
  
Analysis and report by Marco Nenciarini  
  
Bug fix by Simon Riggs  
  

Fix DDL command collection for TRANSFORM

  
commit   : 7d60b2af34842ae89b1abdd31fb5d303bd43c514    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Jun 2015 18:17:54 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Jun 2015 18:17:54 -0300    

Click here for diff

  
Commit b488c580ae, which added the DDL command collection feature,  
neglected to update the code that commit cac76582053e had previously  
added two weeks earlier for the TRANSFORM feature.  
  
Reported by Michael Paquier.  
  

Fix BRIN xlog replay

  
commit   : 402822246866e1094d35a617775a65b4be93d322    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Jun 2015 18:13:05 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Jun 2015 18:13:05 -0300    

Click here for diff

  
There was a confusion about which block number to use when storing an  
item's pointer in the revmap -- the revmap page's blkno was being used,  
not the data page's blkno.  
  
Spotted-by: Jeff Janes  
  

Fix grammar.

  
commit   : 7c02d48e698ad38bec1399a9dcc543c80b8f5b8f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 16:04:46 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 16:04:46 -0400    

Click here for diff

  
Reported by Peter Geoghegan.  
  

  
commit   : 8f15f74a44f68f9cb3a644786d3c732a5eeb237a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 15:53:13 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 15:53:13 -0400    

Click here for diff

  
Don't apply rmtree(), which will gleefully remove an entire subtree,  
and don't even apply unlink() unless it's symlink or a directory,  
the only things that we expect to find.  
  
Amit Kapila, with minor tweaks by me, per extensive discussions  
involving Andrew Dunstan, Fujii Masao, and Heikki Linnakangas,  
at least some of whom also reviewed the code.  
  

release notes: Add entry for commit 5ea86e6e6.

  
commit   : c66bc72e8a1318e43ea657ffa3798fa95f491650    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 14:48:52 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 14:48:52 -0400    

Click here for diff

  
Peter Geoghegan and Robert Haas  
  

Remove unnecessary NULL test.

  
commit   : 8a8c581a8c99b9beecbdc517957da866f427f297    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 14:45:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 14:45:32 -0400    

Click here for diff

  
Spotted by Coverity and reported by Michael Paquier.  Per discussion,  
we don't necessarily care about making Coverity happy in all such  
instances, but we can go ahead and change them where it otherwise  
seems to improve the code.  
  

release notes: Combine items for pg_upgrade and pg_upgrade_support moves.

  
commit   : 31c018ecda9f40fe80055d8ba95248c023593fb4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 14:20:29 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 14:20:29 -0400    

Click here for diff

  
Per suggestions from Amit Langote and Álvaro Herrera.  
  

Don’t warn about creating temporary or unlogged hash indexes.

  
commit   : 9043ef390f4f0b4586cfe59cbd22314b9c3e2957    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 11:37:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 11:37:32 -0400    

Click here for diff

  
Warning people that no WAL-logging will be done doesn't make sense  
in this case.  
  
Michael Paquier  
  

Reduce log level for background worker events from LOG to DEBUG1.

  
commit   : 91118f1a59f2038f072552fdbb98e01363e30b59    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 11:23:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 11:23:32 -0400    

Click here for diff

  
Per discussion, LOG is just too chatty for something that will happen  
as routinely as this.  
  
Pavel Stehule  
  

Fix the fallback memory barrier implementation to be reentrant.

  
commit   : 1b468a131bd260c9041484f78b8580c7f232d580    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 26 Jun 2015 17:00:01 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 26 Jun 2015 17:00:01 +0200    

Click here for diff

  
This was essentially "broken" since 0c8eda62; but until more  
recently (14e8803f) barriers usage in signal handlers was infrequent.  
  
The failure to be reentrant was noticed because the test_shm_mq, which  
uses memory barriers at a high frequency, occasionally got stuck on some  
solaris buildfarm animals. Turns out, those machines use sun studio  
12.1, which doesn't yet have efficient memory barrier support. A machine  
with a newer sun studio did not fail.  Forcing the barrier fallback to  
be used on x86 allows to reproduce the problem.  
  
The new fallback is to use kill(PostmasterPid, 0) based on the theory  
that that'll always imply a barrier due to checking the liveliness of  
PostmasterPid on systems old enough to need fallback support. It's hard  
to come up with a good and performant fallback.  
  
I'm not backpatching this for now - the problem isn't active in the back  
branches, and we haven't backpatched barrier changes for  
now. Additionally master looks entirely different than the back branches  
due to the new atomics abstraction. It seems better to let this rest in  
master, where the non-reentrancy actively causes a problem, and then  
consider backpatching.  
  
Found-By: Robert Haas  
Discussion: 55626265.3060800@dunslane.net  
  

Improve handling of CustomPath/CustomPlan(State) children.

  
commit   : 5ca611841bcd37c7ee8448c46c8398ef8d8edcc4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 09:40:47 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Jun 2015 09:40:47 -0400    

Click here for diff

  
Allow CustomPath to have a list of paths, CustomPlan a list of plans,  
and CustomPlanState a list of planstates known to the core system, so  
that custom path/plan providers can more reasonably use this  
infrastructure for nodes with multiple children.  
  
KaiGai Kohei, per a design suggestion from Tom Lane, with some  
further kibitzing by me.  
  

Fix a couple of bugs with wal_log_hints.

  
commit   : 4b8e24b9ad308c30dbe2184e06848e638e018114    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 26 Jun 2015 12:38:24 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 26 Jun 2015 12:38:24 +0300    

Click here for diff

  
1. Replay of the WAL record for setting a bit in the visibility map  
contained an assertion that a full-page image of that record type can only  
occur with checksums enabled. But it can also happen with wal_log_hints, so  
remove the assertion. Unlike checksums, wal_log_hints can be changed on the  
fly, so it would be complicated to figure out if it was enabled at the time  
that the WAL record was generated.  
  
2. wal_log_hints has the same effect on the locking needed to read the LSN  
of a page as data checksums. BufferGetLSNAtomic() didn't get the memo.  
  
Backpatch to 9.4, where wal_log_hints was added.  
  

Allow background workers to connect to no particular database.

  
commit   : f7bb7f0625771bc71869cdadafcf54450b2db08f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 25 Jun 2015 15:52:13 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 25 Jun 2015 15:52:13 -0400    

Click here for diff

  
The documentation claims that this is supported, but it didn't  
actually work.  Fix that.  
  
Reported by Pavel Stehule; patch by me.  
  

Fix the logic for putting relations into the relcache init file.

  
commit   : 5d1ff6bd559ea8df1b7302e245e690b01b9a4fa4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jun 2015 14:39:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jun 2015 14:39:05 -0400    

Click here for diff

  
Commit f3b5565dd4e59576be4c772da364704863e6a835 was a couple of bricks shy  
of a load; specifically, it missed putting pg_trigger_tgrelid_tgname_index  
into the relcache init file, because that index is not used by any  
syscache.  However, we have historically nailed that index into cache for  
performance reasons.  The upshot was that load_relcache_init_file always  
decided that the init file was busted and silently ignored it, resulting  
in a significant hit to backend startup speed.  
  
To fix, reinstantiate RelationIdIsInInitFile() as a wrapper around  
RelationSupportsSysCache(), which can know about additional relations  
that should be in the init file despite being unknown to syscache.c.  
  
Also install some guards against future mistakes of this type: make  
write_relcache_init_file Assert that all nailed relations get written to  
the init file, and make load_relcache_init_file emit a WARNING if it takes  
the "wrong number of nailed relations" exit path.  Now that we remove the  
init files during postmaster startup, that case should never occur in the  
field, even if we are starting a minor-version update that added or removed  
rels from the nailed set.  So the warning shouldn't ever be seen by end  
users, but it will show up in the regression tests if somebody breaks this  
logic.  
  
Back-patch to all supported branches, like the previous commit.  
  

Docs: fix claim that to_char(‘FM’) removes trailing zeroes.

  
commit   : d759b7eb6aee12bd52516905d790072845b4356f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jun 2015 10:44:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jun 2015 10:44:03 -0400    

Click here for diff

  
Of course, what it removes is leading zeroes.  Seems to have been a thinko  
in commit ffe92d15d53625d5ae0c23f4e1984ed43614a33d.  Noted by Hubert Depesz  
Lubaczewski.  
  

Add index terms for functions jsonb_set and jsonb_pretty.

  
commit   : 0b157a0dad4f88f6f4420faa4cddab1e5112988f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 24 Jun 2015 22:30:19 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 24 Jun 2015 22:30:19 +0900    

Click here for diff

  
  

Update get_relation_info comment.

  
commit   : 51d0fe5d5682a65e3bce7aa62d8666509fd08aa2    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 23 Jun 2015 10:08:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 23 Jun 2015 10:08:30 -0400    

Click here for diff

  
Thomas Munro  
  

Add missing newline to debug-message.

  
commit   : 9cb36981fbbf2f298db2476101f4475c52d00fbb    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 23 Jun 2015 15:49:28 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 23 Jun 2015 15:49:28 +0300    

Click here for diff

  
Michael Paquier  
  

pg_rewind: Improve message wording

  
commit   : e98d635d5dbf25e5cde282af111af9fdffafa557    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 22 Jun 2015 20:40:01 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 22 Jun 2015 20:40:01 -0400    

Click here for diff

  
  

pg_basebackup: Remove redundant newline in error message

  
commit   : 747781f25e7eaa2e5cb5ed69bdae3e5f61795d2e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 22 Jun 2015 20:39:41 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 22 Jun 2015 20:39:41 -0400    

Click here for diff

  
  

Improve inheritance_planner()’s performance for large inheritance sets.

  
commit   : 2cb9ec1bcb35dd6b4cf7a4a325aaa9791444e69d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Jun 2015 18:53:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Jun 2015 18:53:27 -0400    

Click here for diff

  
Commit c03ad5602f529787968fa3201b35c119bbc6d782 introduced a planner  
performance regression for UPDATE/DELETE on large inheritance sets.  
It required copying the append_rel_list (which is of size proportional to  
the number of inherited tables) once for each inherited table, thus  
resulting in O(N^2) time and memory consumption.  While it's difficult to  
avoid that in general, the extra work only has to be done for  
append_rel_list entries that actually reference subquery RTEs, which  
inheritance-set entries will not.  So we can buy back essentially all of  
the loss in cases without subqueries in FROM; and even for those, the added  
work is mainly proportional to the number of UNION ALL subqueries.  
  
Back-patch to 9.2, like the previous commit.  
  
Tom Lane and Dean Rasheed, per a complaint from Thomas Munro.  
  

psql: Add some tab completion for TABLESAMPLE.

  
commit   : da9ee026a0ddd100785b00defd1201b317c0797b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 22 Jun 2015 14:13:56 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 22 Jun 2015 14:13:56 -0400    

Click here for diff

  
Petr Jelinek, reviewed by Brendan Jurd  
  

Truncate strings in tarCreateHeader() with strlcpy(), not sprintf().

  
commit   : 4318118edd5582696027f357771e0a8b091fe2bf    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 21 Jun 2015 20:04:36 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 21 Jun 2015 20:04:36 -0400    

Click here for diff

  
This supplements the GNU libc bug #6530 workarounds introduced in commit  
54cd4f04576833abc394e131288bf3dd7dcf4806.  On affected systems, a  
tar-format pg_basebackup failed when some filename beneath the data  
directory was not valid character data in the postmaster/walsender  
locale.  Back-patch to 9.1, where pg_basebackup was introduced.  Extant,  
bug-prone conversion specifications receive only ASCII bytes or involve  
low-importance messages.  
  

Add transforms to pg_get_object_address and friends

  
commit   : ad89a5d115b3b4025f3c135f95f722e7e4becf13    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 21 Jun 2015 16:08:49 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 21 Jun 2015 16:08:49 -0300    

Click here for diff

  
This was missed when transforms were added by commit cac76582053ef8e.  
  
Extracted from a larger patch  
Author: Michael Paquier  
  

Improve multixact emergency autovacuum logic.

  
commit   : 667912aee649c3608e003568e4b47d95251b1c8c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 21 Jun 2015 18:57:28 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 21 Jun 2015 18:57:28 +0200    

Click here for diff

  
Previously autovacuum was not necessarily triggered if space in the  
members slru got tight. The first problem was that the signalling was  
tied to values in the offsets slru, but members can advance much  
faster. Thats especially a problem if old sessions had been around that  
previously prevented the multixact horizon to increase. Secondly the  
skipping logic doesn't work if the database was restarted after  
autovacuum was triggered - that knowledge is not preserved across  
restart. This is especially a problem because it's a common  
panic-reaction to restart the database if it gets slow to  
anti-wraparound vacuums.  
  
Fix the first problem by separating the logic for members from  
offsets. Trigger autovacuum whenever a multixact crosses a segment  
boundary, as the current member offset increases in irregular values, so  
we can't use a simple modulo logic as for offsets.  Add a stopgap for  
the second problem, by signalling autovacuum whenver ERRORing out  
because of boundaries.  
  
Discussion: 20150608163707.GD20772@alap3.anarazel.de  
  
Backpatch into 9.3, where it became more likely that multixacts wrap  
around.  
  

Add missing check for wal_debug GUC.

  
commit   : 90231cd5188c43da94f58f7a839eee9286d0f864    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 21 Jun 2015 18:35:59 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 21 Jun 2015 18:35:59 +0200    

Click here for diff

  
9a20a9b2 added a new elog(), enabled when WAL_DEBUG is defined. The  
other WAL_DEBUG dependant messages check for the wal_debug GUC, but this  
one did not. While at it replace 'upto' with 'up to'.  
  
Discussion: 20150610110253.GF3832@alap3.anarazel.de  
  
Backpatch to 9.4, the first release containing 9a20a9b2.  
  

PL/Perl: Add alternative expected file for Perl 5.22

  
commit   : 103382abf87453d6555755da8f9fbef0b9965f81    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 21 Jun 2015 10:37:24 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 21 Jun 2015 10:37:24 -0400    

Click here for diff

  
  

Fix failure to copy setlocale() return value.

  
commit   : f0a264a362343287051c4737b01aa3ebe36f21a6    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 20 Jun 2015 12:09:29 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 20 Jun 2015 12:09:29 -0400    

Click here for diff

  
POSIX permits setlocale() calls to invalidate any previous setlocale()  
return values, but commit 5f538ad004aa00cf0881f179f0cde789aad4f47e  
neglected to account for setlocale(LC_CTYPE, NULL) doing so.  The effect  
was to set the LC_CTYPE environment variable to an unintended value.  
pg_perm_setlocale() sets this variable to assist PL/Perl; without it,  
Perl would undo PostgreSQL's locale settings.  The known-affected  
configurations are 32-bit, release builds using Visual Studio 2012 or  
Visual Studio 2013.  Visual Studio 2010 is unaffected, as were all  
buildfarm-attested configurations.  In principle, this bug could leave  
the wrong LC_CTYPE in effect after PL/Perl use, which could in turn  
facilitate problems like corrupt tsvector datums.  No known platform  
experiences that consequence, because PL/Perl on Windows does not use  
this environment variable.  
  
The bug has been user-visible, as early postmaster failure, on systems  
with Windows ANSI code page set to CP936 for "Chinese (Simplified, PRC)"  
and probably on systems using other multibyte code pages.  
(SetEnvironmentVariable() rejects values containing character data not  
valid under the Windows ANSI code page.)  Back-patch to 9.4, where the  
faulty commit first appeared.  
  
Reported by Didi Hu and 林鹏程.  Reviewed by Tom Lane, though this fix  
strategy was not his first choice.  
  

Revert “Detect setlocale(LC_CTYPE, NULL) clobbering previous return values.”

  
commit   : 1f2a378de41bf3e516b8d2c4d65790aeefbfb89d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 20 Jun 2015 12:08:48 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 20 Jun 2015 12:08:48 -0400    

Click here for diff

  
This reverts commit b76e76be460a240e99c33f6fb470dd1d5fe01a2a.  The  
buildfarm yielded no related failures.  
  

Fix BRIN supported operators table

  
commit   : 1443a165db007462c5044ad8d03d919ac4323e6d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 20 Jun 2015 12:26:36 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 20 Jun 2015 12:26:36 -0300    

Click here for diff

  
Some of the entries in the inclusion opclasses where missing operators,  
and we had an entry for inet_inclusion_ops instead of  
network_inclusion_ops.  Sort the operators within each opclass by  
strategy number, just to make it easier to spot mistakes.  
  
Also sort the rows by data type name, rather than OID.  
  

Fix thinko in comment (launcher -> worker)

  
commit   : 3c400a3f2bf4bb93a60cefc09416d37fc3dab8ed    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 20 Jun 2015 11:45:59 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 20 Jun 2015 11:45:59 -0300    

Click here for diff

  
  

In immediate shutdown, postmaster should not exit till children are gone.

  
commit   : 48913db887e6a41fa3f1b6cdf80ee89e38f21d9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Jun 2015 14:23:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Jun 2015 14:23:39 -0400    

Click here for diff

  
This adjusts commit 82233ce7ea42d6ba519aaec63008aff49da6c7af so that the  
postmaster does not exit until all its child processes have exited, even  
if the 5-second timeout elapses and we have to send SIGKILL.  There is no  
great value in having the postmaster process quit sooner, and doing so can  
mislead onlookers into thinking that the cluster is fully terminated when  
actually some child processes still survive.  
  
This effect might explain recent test failures on buildfarm member hamster,  
wherein we failed to restart a cluster just after shutting it down with  
"pg_ctl stop -m immediate".  
  
I also did a bit of code review/beautification, including fixing a faulty  
use of the Max() macro on a volatile expression.  
  
Back-patch to 9.4.  In older branches, the postmaster never waited for  
children to exit during immediate shutdowns, and changing that would be  
too much of a behavioral change.  
  

Clamp autovacuum launcher sleep time to 5 minutes

  
commit   : da1a9d0f5bed1f93908be9233a4fef39b988e505    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 19 Jun 2015 12:44:36 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 19 Jun 2015 12:44:36 -0300    

Click here for diff

  
This avoids the problem that it might go to sleep for an unreasonable  
amount of time in unusual conditions like the server clock moving  
backwards an unreasonable amount of time.  
  
(Simply moving the server clock forward again doesn't solve the problem  
unless you wake up the autovacuum launcher manually, say by sending it  
SIGHUP).  
  
Per trouble report from Prakash Itnal in  
https://www.postgresql.org/message-id/CAHC5u79-UqbapAABH2t4Rh2eYdyge0Zid-X=Xz-ZWZCBK42S0Q@mail.gmail.com  
  
Analyzed independently by Haribabu Kommi and Tom Lane.  
  

Fix bogus range_table_mutator() logic for RangeTblEntry.tablesample.

  
commit   : be87143fe90adf8862791aeddd76151e88ce5603    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Jun 2015 11:41:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Jun 2015 11:41:45 -0400    

Click here for diff

  
Must make a copy of the TableSampleClause node; the previous coding  
modified the input data structure in-place.  
  
Petr Jelinek  
  

Fix corner case in autovacuum-forcing logic for multixact wraparound.

  
commit   : ed16f73c574660aa0902caa1c0adeba07f8c70a5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Jun 2015 11:28:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Jun 2015 11:28:30 -0400    

Click here for diff

  
Since find_multixact_start() relies on SimpleLruDoesPhysicalPageExist(),  
and that function looks only at the on-disk state, it's possible for it  
to fail to find a page that exists in the in-memory SLRU that has not  
been written yet.  If that happens, SetOffsetVacuumLimit() will  
erroneously decide to force emergency autovacuuming immediately.  
  
We should probably fix find_multixact_start() to consider the data  
cached in memory as well as on the on-disk state, but that's no excuse  
for SetOffsetVacuumLimit() to be stupid about the case where it can  
no longer read the value after having previously succeeded in doing so.  
  
Report by Andres Freund.  
  

Add PASSWORD to tab completions for CREATE/ALTER ROLE/USER/GROUP.

  
commit   : 86e4751786bb0dcb29528ef49b067d0e393e4934    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Jun 2015 11:11:22 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Jun 2015 11:11:22 -0400    

Click here for diff

  
Jeevan Chalke  
  

Change TAP test framework to not rely on having a chmod executable.

  
commit   : ca3f43aa48a83013ea50aeee7cd193a5859c4587    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Jun 2015 10:46:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Jun 2015 10:46:30 -0400    

Click here for diff

  
This might not work at all on Windows, and is not ever efficient.  
  
Michael Paquier  
  

Detect setlocale(LC_CTYPE, NULL) clobbering previous return values.

  
commit   : b76e76be460a240e99c33f6fb470dd1d5fe01a2a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 17 Jun 2015 08:13:33 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 17 Jun 2015 08:13:33 -0400    

Click here for diff

  
POSIX permits setlocale() calls to invalidate any previous setlocale()  
return values.  Commit 5f538ad004aa00cf0881f179f0cde789aad4f47e  
neglected to account for that.  In advance of fixing that bug, switch to  
failing hard on affected configurations.  This is a planned temporary  
commit to assay buildfarm-represented configurations.  
  

Fix comment in fmgr.h to refer to actual function used.

  
commit   : 41d798a139b5c94ad8ce10b192141b5bcc03dda3    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 15 Jun 2015 23:21:03 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 15 Jun 2015 23:21:03 -0400    

Click here for diff

  
FunctionLookup() is long gone if it ever existed, and fmgr_info() is  
what's now used, so the comments now reflect that.  
  

Check for out of memory when allocating sqlca.

  
commit   : 94a484222caece19e381a6941b8d826027ac2e75    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Mon, 15 Jun 2015 14:21:03 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Mon, 15 Jun 2015 14:21:03 +0200    

Click here for diff

  
Patch by Michael Paquier  
  

Fix memory leak in ecpglib’s connect function.

  
commit   : af0b49fc98cb3494d1e444a4f5c3364627a3ed5f    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Mon, 15 Jun 2015 14:20:09 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Mon, 15 Jun 2015 14:20:09 +0200    

Click here for diff

  
Patch by Michael Paquier  
  

release notes: fix Petr’s name typos

  
commit   : 2bed1cd7519fb9f017a8e2ce9881086f14a31d7c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 14 Jun 2015 13:41:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 14 Jun 2015 13:41:37 -0400    

Click here for diff

  
Report by Alvaro Herrera  
  

doc: Add note to pg_dump man page about pg_dumpall

  
commit   : a85054181b3e60d44d896168127b7f7e204ea9f4    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 13 Jun 2015 21:45:56 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 13 Jun 2015 21:45:56 -0400    

Click here for diff

  
suggested by Joshua Drake  
  

Remove stray character

  
commit   : 340c74dfdfb91d521fbdb20e5601973266da3428    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 13 Jun 2015 21:41:34 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 13 Jun 2015 21:41:34 -0400    

Click here for diff

  
  

release notes: consistently name “Alexander Shulgin”

  
commit   : 74cb688525e347121978a502368c76cd6af1bdd6    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 13 Jun 2015 21:10:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 13 Jun 2015 21:10:48 -0400    

Click here for diff

  
Report by Alvaro Herrera  
  

release notes: move/remove/adjust items

  
commit   : 62331ef3f67ec9ad16a26dec276b634f704de8d4    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 13 Jun 2015 21:07:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 13 Jun 2015 21:07:24 -0400    

Click here for diff

  
Report by Alvaro Herrera  
  

release notes: add accent to Petr Jelínek last name

  
commit   : 305f815ccd059fb31193939a060fc524ddd5a0ea    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 13 Jun 2015 21:00:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 13 Jun 2015 21:00:30 -0400    

Click here for diff

  
Report by Alvaro Herrera  
  

release notes: remove mention of pg_basebackup non-compat

  
commit   : 31cda8bf3c3209e0740dd2c8fa5aa1d0319f7292    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 13 Jun 2015 20:56:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 13 Jun 2015 20:56:30 -0400    

Click here for diff

  
Report by Amit Kapila  
  

release notes: add Petr Jelinek to JSON function item

  
commit   : 29d80d5fa8c61e635e5be4c0be859438e4209117    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 12 Jun 2015 22:34:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 12 Jun 2015 22:34:31 -0400    

Click here for diff

  
Report by Petr Jelinek  
  

release notes: fixes from Fujii Masao

  
commit   : 230ff9383c63ebfef11bfd6ba89aed7329b96c7e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 12 Jun 2015 22:31:17 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 12 Jun 2015 22:31:17 -0400    

Click here for diff

  
Report by Fujii Masao  
  

release notes: reorder hash performance authors, again

  
commit   : 644ac3e678f43402da3fbcbd6aa8e6c5915ad9c0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 12 Jun 2015 22:25:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 12 Jun 2015 22:25:30 -0400    

Click here for diff

  
Report by Robert Haas  
  

release notes: reorder sort performance authors

  
commit   : 51b47c5c095c53be4cda81e322b428167c81c6f2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 12 Jun 2015 22:23:40 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 12 Jun 2015 22:23:40 -0400    

Click here for diff

  
Report by Peter Geoghegan  
  

release notes: split apart hash items

  
commit   : 8bf51ad0cc26e80cbd082c111f45428db7a2f73b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 12 Jun 2015 22:16:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 12 Jun 2015 22:16:08 -0400    

Click here for diff

  
Report by Tom Lane, Robert Haas  
  

release notes: add two optimizer items

  
commit   : 89fe9bfc4ed3b5dc8e02119cc1fd39c975ffdea0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 12 Jun 2015 21:47:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 12 Jun 2015 21:47:08 -0400    

Click here for diff

  
Report by Tom Lane  
  

Fix “path” infrastructure bug affecting jsonb_set()

  
commit   : 2271d002d5c305441398e8f7a295f18ec3c132a9    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 12 Jun 2015 19:26:03 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 12 Jun 2015 19:26:03 -0400    

Click here for diff

  
jsonb_set() and other clients of the setPathArray() utility function  
could get spurious results when an array integer subscript is provided  
that is not within the range of int.  
  
To fix, ensure that the value returned by strtol() within setPathArray()  
is within the range of int;  when it isn't, assume an invalid input in  
line with existing, similar cases.  The path-orientated operators that  
appeared in PostgreSQL 9.3 and 9.4 do not call setPathArray(), and  
already independently take this precaution, so no change there.  
  
Peter Geoghegan  
  

Fix failure to cover scalar-vs-rowtype cases in exec_stmt_return().

  
commit   : ae58f1430abb4b0c309c40b377f91bf9d080334b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jun 2015 13:44:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jun 2015 13:44:06 -0400    

Click here for diff

  
In commit 9e3ad1aac52454569393a947c06be0d301749362 I modified plpgsql  
to use exec_stmt_return's simple-variables fast path in more cases.  
However, I overlooked that there are really two different return  
conventions in use here, depending on whether estate->retistuple is true,  
and the existing fast-path code had only bothered to handle one of them.  
So trying to return a scalar in a function returning composite, or vice  
versa, could lead to unexpected error messages (typically "cache lookup  
failed for type 0") or to a null-pointer-dereference crash.  
  
In the DTYPE_VAR case, we can just throw error if retistuple is true,  
corresponding to what happens in the general-expression code path that was  
being used previously.  (Perhaps someday both of these code paths should  
attempt a coercion, but today is not that day.)  
  
In the REC and ROW cases, just hand the problem to exec_eval_datum()  
when not retistuple.  Also clean up the ROW coding slightly so it looks  
more like exec_eval_datum().  
  
The previous commit also caused exec_stmt_return_next() to be used in  
more cases, but that code seems to be OK as-is.  
  
Per off-list report from Serge Rielau.  This bug is new in 9.5 so no need  
to back-patch.  
  

Improve error message and hint for ALTER COLUMN TYPE can’t-cast failure.

  
commit   : b00982344a73d9cb626430dd17a6da84c15c9980    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jun 2015 11:54:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Jun 2015 11:54:03 -0400    

Click here for diff

  
We already tried to improve this once, but the "improved" text was rather  
off-target if you had provided a USING clause.  Also, it seems helpful  
to provide the exact text of a suggested USING clause, so users can just  
copy-and-paste it when needed.  Per complaint from Keith Rarick and a  
suggestion from Merlin Moncure.  
  
Back-patch to 9.2 where the current wording was adopted.  
  

Make postmaster restart archiver soon after it dies, even during recovery.

  
commit   : b5fe62038f49f92c4a4f189c7cdacf3739effcdc    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 12 Jun 2015 23:11:51 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 12 Jun 2015 23:11:51 +0900    

Click here for diff

  
After the archiver dies, postmaster tries to start a new one immediately.  
But previously this could happen only while server was running normally  
even though archiving was enabled always (i.e., archive_mode was set to  
always). So the archiver running during recovery could not restart soon  
after it died. This is an oversight in commit ffd3774.  
  
This commit changes reaper(), postmaster's signal handler to cleanup  
after a child process dies, so that it tries to a new archiver even during  
recovery if necessary.  
  
Patch by me. Review by Alvaro Herrera.  
  

Fixed some memory leaks in ECPG.

  
commit   : 96ad72d1c00fa6526eb4d5e9c2a747b44752b4ee    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Fri, 12 Jun 2015 14:52:55 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Fri, 12 Jun 2015 14:52:55 +0200    

Click here for diff

  
Patch by Michael Paquier  
  

Fix intoasc() in Informix compat lib. This function used to be a noop.

  
commit   : 82be1bf5099c0f6d1ef482ba3ca9cf1741db1eb3    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Fri, 12 Jun 2015 14:50:47 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Fri, 12 Jun 2015 14:50:47 +0200    

Click here for diff

  
Patch by Michael Paquier  
  

Fix alphabetization in catalogs.sgml.

  
commit   : 091c02a958fd0ae02b96492d9728efe8526385e6    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 12 Jun 2015 12:59:29 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 12 Jun 2015 12:59:29 +0900    

Click here for diff

  
System catalogs and views should be listed alphabetically  
in catalog.sgml, but only pg_file_settings view not.  
  
This patch also fixes typos in pg_file_settings comments.  
  

Clean up useless mention of RMGRDESCSOURCES in pg_rewind Makefile.

  
commit   : cd3cff4778e011c584e1481a6803dec5d4756a6e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 12 Jun 2015 12:32:48 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 12 Jun 2015 12:32:48 +0900    

Click here for diff

  
RMGRDESCSOURCES is defined and used only in pg_xlogdump Makefile,  
but pg_rewind Makefile mentioned it as extra files to remove in "make clean".  
This patch removes that useless mention from pg_rewind Makefile.  
  
Michael Paquier  
  

  
commit   : 66447916f719130212c7930c47e902586a4bf054    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2015 23:04:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2015 23:04:46 -0400    

Click here for diff

  
  

release notes: update hash item

  
commit   : 778fed04cd175510e9e75509033e2b985cf49e30    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2015 11:32:32 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2015 11:32:32 -0400    

Click here for diff

  
Report by Tomas Vondra  
  

release notes: move pg_buffercache item to the right section

  
commit   : 7b7be78a12ea98c7cb9653d78c156a83d322df6e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2015 11:13:49 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2015 11:13:49 -0400    

Click here for diff

  
Report by Amit Langote  
  

release notes: implement suggestions

  
commit   : bab74070b325704f7b7a86c4bd72f9a6b3318ed7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2015 11:11:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2015 11:11:43 -0400    

Click here for diff

  
Report by Michael Paquier  
  

release notes: explain meaning of pg_stat_get_snapshot_timestamp()

  
commit   : 1cc9f8ccd9b7406c52fb85e48435cb6d265d006e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2015 10:58:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2015 10:58:38 -0400    

Click here for diff

  
Report by Michael Paquier  
  

release notes: update for pg_basebackup in tar format

  
commit   : 5a4ea8e2004db269497ef18048ed5238c2c6e5cb    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2015 10:51:18 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2015 10:51:18 -0400    

Click here for diff

  
Report by Amit Kapila  
  

Rename jsonb - text[] operator to #- to avoid ambiguity.

  
commit   : 908e234733574545866045c7d5f93d4dd50ef66d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 11 Jun 2015 10:06:58 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 11 Jun 2015 10:06:58 -0400    

Click here for diff

  
Following recent discussion  on -hackers. The underlying function is  
also renamed to jsonb_delete_path. The regression tests now don't need  
ugly type casts to avoid the ambiguity, so they are also removed.  
  
Catalog version bumped.  
  

Fix some issues in pg_rewind.

  
commit   : 966c37fdb5ed9b87f3e91eace4dbbed7909f6769    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 11 Jun 2015 22:31:18 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 11 Jun 2015 22:31:18 +0900    

Click here for diff

  
* Remove invalid option character "N" from the third argument (valid option  
string) of getopt_long().  
  
* Use pg_free() or pfree() to free the memory allocated by pg_malloc() or  
palloc() instead of always using free().  
  
* Assume problem is no disk space if write() fails but doesn't set errno.  
  
* Fix several typos.  
  
Patch by me. Review by Michael Paquier.  
  

First draft of 9.5 release notes

  
commit   : aacb8b9277ec63ee848442ccc1aa4b3f6eab1893    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2015 00:08:55 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jun 2015 00:08:55 -0400    

Click here for diff

  
  

doc: Use “connections” instead of “slots” to avoid confusion

  
commit   : e80f619acf018a9f79dc6188472ac94ba6742ab5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 Jun 2015 21:34:03 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 Jun 2015 21:34:03 -0400    

Click here for diff

  
The text was written before replication slots existed, but now "slot" is  
best not used for anything else in the space of replication.  
  

doc: Fix typo

  
commit   : 28d17269a1fff9fa9c4dd2c588a586a028fa4798    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 Jun 2015 21:33:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 Jun 2015 21:33:35 -0400    

Click here for diff

  
  

Fix typo

  
commit   : 385522c7dc6351a57e459b17cc66912daf4ab90e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 Jun 2015 21:30:17 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 Jun 2015 21:30:17 -0400    

Click here for diff

  
  

doc: Call xmllint for validity also in the fop build

  
commit   : 75a49ba550bae7a44bc1c4b2b7413a1768f70829    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 Jun 2015 19:54:28 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 Jun 2015 19:54:28 -0400    

Click here for diff

  
This was somehow missed in commit  
5d93ce2d0c619ba1b408eb749715e7223e23f6ae.  
  

Fix typo in comment.

  
commit   : 870681017a9e39e25aca14a2426cdbc57e3ce2af    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 10 Jun 2015 17:03:56 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 10 Jun 2015 17:03:56 -0500    

Click here for diff

  
Backpatch to 9.4 to minimize possible conflicts.  
  

docs: update release note regex suggestions

  
commit   : 1e87d4d0680b950eabf3e050071559a6f04fa07a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Jun 2015 16:33:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Jun 2015 16:33:46 -0400    

Click here for diff

  
  

Fix typo in comment.

  
commit   : ea9c4c1e4a7a9b602d867dcb02e07ef1fe51f6ec    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 10 Jun 2015 15:26:02 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 10 Jun 2015 15:26:02 +0900    

Click here for diff

  
David Rowley  
  

Release notes for 9.4.4, 9.3.9, 9.2.13, 9.1.18, 9.0.22.

  
commit   : b94085920b016e64ee40a0f6c50199889565cc56    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Jun 2015 14:33:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Jun 2015 14:33:43 -0400    

Click here for diff

  
  

Report more information if pg_perm_setlocale() fails at startup.

  
commit   : f6e9cbfd9153958226b27e31d658e7b64351c71f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Jun 2015 13:37:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Jun 2015 13:37:08 -0400    

Click here for diff

  
We don't know why a few Windows users have seen this fail, but the  
taciturnity of the error message certainly isn't helping debug it.  
Let's at least find out which LC category isn't working.  
  

First-draft release notes for 9.4.4, 9.3.9, 9.2.13, 9.1.18, 9.0.22.

  
commit   : 21187cfc7dfd82461db9119377a76366c00d27c3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Jun 2015 13:07:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Jun 2015 13:07:15 -0400    

Click here for diff

  
  

Fix typos

  
commit   : 94232c909da4e39273efd66fc7c9c4a3fd9ef51a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 8 Jun 2015 15:35:43 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 8 Jun 2015 15:35:43 -0300    

Click here for diff

  
tablesapce -> tablespace  
there -> their  
  
These were introduced in 72d422a52, so no need to backpatch.  
  

Refactor WAL segment copying code.

  
commit   : 7abc68597436da1475b4d9b08f4fa9f3c5ed6185    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 9 Jun 2015 03:03:24 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 9 Jun 2015 03:03:24 +0900    

Click here for diff

  
* Remove unused argument "dstfname" and related code from XLogFileCopy().  
  
* Previously XLogFileCopy() returned a pstrdup'd string so that  
InstallXLogFileSegment() used it later. Since the pstrdup'd string was never  
free'd, there could be a risk of memory leak. It was almost harmless because  
the startup process exited just after calling XLogFileCopy(), it existed.  
This commit changes XLogFileCopy() so that it directly calls  
InstallXLogFileSegment() and doesn't call pstrdup() at all. Which fixes that  
memory leak problem.  
  
* Extend InstallXLogFileSegment() so that the caller can specify the log level.  
Which allows us to emit an error when InstallXLogFileSegment() fails a disk  
file access like link() and rename(). Previously it was always logged with  
LOG level and additionally needed to be logged with ERROR when we wanted  
to treat it as an error.  
  
Michael Paquier  
  

Allow HotStandbyActiveInReplay() to be called in single user mode.

  
commit   : d1b958218ac183d0e88348341ff6ba31397086ad    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 8 Jun 2015 00:30:26 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 8 Jun 2015 00:30:26 +0200    

Click here for diff

  
HotStandbyActiveInReplay, introduced in 061b079f, only allowed WAL  
replay to happen in the startup process, missing the single user case.  
  
This buglet is fairly harmless as it only causes problems when single  
user mode in an assertion enabled build is used to replay a btree vacuum  
record.  
  
Backpatch to 9.2. 061b079f was backpatched further, but the assertion  
was not.  
  

Clarify documentation of jsonb - text

  
commit   : 94d6727dbe61117addd9c24eea28440a2151ccf4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 7 Jun 2015 21:31:52 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 7 Jun 2015 21:31:52 -0400    

Click here for diff

  
Peter Geoghegan  
  

Desupport jsonb subscript deletion on objects

  
commit   : b81c7b4098f52e64df89efe1461ba00a54649a10    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 7 Jun 2015 20:46:00 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 7 Jun 2015 20:46:00 -0400    

Click here for diff

  
Supporting deletion of JSON pairs within jsonb objects using an  
array-style integer subscript allowed for surprising outcomes.  This was  
mostly due to the implementation-defined ordering of pairs within  
objects for jsonb.  
  
It also seems desirable to make jsonb integer subscript deletion  
consistent with the 9.4 era general purpose integer subscripting  
operator for jsonb (although that operator returns NULL when an object  
is encountered, while we prefer here to throw an error).  
  
Peter Geoghegan, following discussion on -hackers.  
  

  
commit   : d23a3a603b8eed5e8e34b193d43e9ca5f380ef3f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 7 Jun 2015 20:27:27 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 7 Jun 2015 20:27:27 -0400    

Click here for diff

  
FOP doesn't handle links to table rows, so put the link to a cell  
instead.  
  

Use a safer method for determining whether relcache init file is stale.

  
commit   : f3b5565dd4e59576be4c772da364704863e6a835    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Jun 2015 15:32:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Jun 2015 15:32:09 -0400    

Click here for diff

  
When we invalidate the relcache entry for a system catalog or index, we  
must also delete the relcache "init file" if the init file contains a copy  
of that rel's entry.  The old way of doing this relied on a specially  
maintained list of the OIDs of relations present in the init file: we made  
the list either when reading the file in, or when writing the file out.  
The problem is that when writing the file out, we included only rels  
present in our local relcache, which might have already suffered some  
deletions due to relcache inval events.  In such cases we correctly decided  
not to overwrite the real init file with incomplete data --- but we still  
used the incomplete initFileRelationIds list for the rest of the current  
session.  This could result in wrong decisions about whether the session's  
own actions require deletion of the init file, potentially allowing an init  
file created by some other concurrent session to be left around even though  
it's been made stale.  
  
Since we don't support changing the schema of a system catalog at runtime,  
the only likely scenario in which this would cause a problem in the field  
involves a "vacuum full" on a catalog concurrently with other activity, and  
even then it's far from easy to provoke.  Remarkably, this has been broken  
since 2002 (in commit 786340441706ac1957a031f11ad1c2e5b6e18314), but we had  
never seen a reproducible test case until recently.  If it did happen in  
the field, the symptoms would probably involve unexpected "cache lookup  
failed" errors to begin with, then "could not open file" failures after the  
next checkpoint, as all accesses to the affected catalog stopped working.  
Recovery would require manually removing the stale "pg_internal.init" file.  
  
To fix, get rid of the initFileRelationIds list, and instead consult  
syscache.c's list of relations used in catalog caches to decide whether a  
relation is included in the init file.  This should be a tad more efficient  
anyway, since we're replacing linear search of a list with ~100 entries  
with a binary search.  It's a bit ugly that the init file contents are now  
so directly tied to the catalog caches, but in practice that won't make  
much difference.  
  
Back-patch to all supported branches.  
  

Get rid of a //-style comment.

  
commit   : 1497369e5df8bb129256f677a85327f80d3767d3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jun 2015 17:04:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jun 2015 17:04:07 -0400    

Click here for diff

  
Not sure how "//XXX" got into a committed patch in the first place,  
as it's both content-free and against project style.  pgindent made a  
bit of a hash of it, too.  
  
Going forward, we should have at least one buildfarm member using  
"gcc -ansi" to catch such things, at least till such time as we  
decide the project target language isn't C90 any more.  I've turned  
this option on on dromedary.  
  

Fix incorrect order of database-locking operations in InitPostgres().

  
commit   : ac23b711dd6ccb82fb70ca0f153fe755fd809a46    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jun 2015 13:22:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Jun 2015 13:22:27 -0400    

Click here for diff

  
We should set MyProc->databaseId after acquiring the per-database lock,  
not beforehand.  The old way risked deadlock against processes trying to  
copy or delete the target database, since they would first acquire the lock  
and then wait for processes with matching databaseId to exit; that left a  
window wherein an incoming process could set its databaseId and then block  
on the lock, while the other process had the lock and waited in vain for  
the incoming process to exit.  
  
CountOtherDBBackends() would time out and fail after 5 seconds, so this  
just resulted in an unexpected failure not a permanent lockup, but it's  
still annoying when it happens.  A real-world example of a use-case is that  
short-duration connections to a template database should not cause CREATE  
DATABASE to fail.  
  
Doing it in the other order should be fine since the contract has always  
been that processes searching the ProcArray for a database ID must hold the  
relevant per-database lock while searching.  Thus, this actually removes  
the former race condition that required an assumption that storing to  
MyProc->databaseId is atomic.  
  
It's been like this for a long time, so back-patch to all active branches.  
  

Cope with possible failure of the oldest MultiXact to exist.

  
commit   : 068cfadf9e2190bdd50a30d19efc7c9f0b825b5e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 5 Jun 2015 08:34:52 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 5 Jun 2015 08:34:52 -0400    

Click here for diff

  
Recent commits, mainly b69bf30b9bfacafc733a9ba77c9587cf54d06c0c and  
53bb309d2d5a9432d2602c93ed18e58bd2924e15, introduced mechanisms to  
protect against wraparound of the MultiXact member space: the number  
of multixacts that can exist at one time is limited to 2^32, but the  
total number of members in those multixacts is also limited to 2^32,  
and older code did not take care to enforce the second limit,  
potentially allowing old data to be overwritten while it was still  
needed.  
  
Unfortunately, these new mechanisms failed to account for the fact  
that the code paths in which they run might be executed during  
recovery or while the cluster was in an inconsistent state.  Also,  
they failed to account for the fact that users who used pg_upgrade  
to upgrade a PostgreSQL version between 9.3.0 and 9.3.4 might have  
might oldestMultiXid = 1 in the control file despite the true value  
being larger.  
  
To fix these problems, first, avoid unnecessarily examining the  
mmembers of MultiXacts when the cluster is not known to be consistent.  
TruncateMultiXact has done this for a long time, and this patch does  
not fix that.  But the new calls used to prevent member wraparound  
are not needed until we reach normal running, so avoid calling them  
earlier.  (SetMultiXactIdLimit is actually called before InRecovery  
is set, so we can't rely on that; we invent our own multixact-specific  
flag instead.)  
  
Second, make failure to look up the members of a MultiXact a non-fatal  
error.  Instead, if we're unable to determine the member offset at  
which wraparound would occur, postpone arming the member wraparound  
defenses until we are able to do so.  If we're unable to determine the  
member offset that should force autovacuum, force it continuously  
until we are able to do so.  If we're unable to deterine the member  
offset at which we should truncate the members SLRU, log a message and  
skip truncation.  
  
An important consequence of these changes is that anyone who does have  
a bogus oldestMultiXid = 1 value in pg_control will experience  
immediate emergency autovacuuming when upgrading to a release that  
contains this fix.  The release notes should highlight this fact.  If  
a user has no pg_multixact/offsets/0000 file, but has oldestMultiXid = 1  
in the control file, they may wish to vacuum any tables with  
relminmxid = 1 prior to upgrading in order to avoid an immediate  
emergency autovacuum after the upgrade.  This must be done with a  
PostgreSQL version 9.3.5 or newer and with vacuum_multixact_freeze_min_age  
and vacuum_multixact_freeze_table_age set to 0.  
  
This patch also adds an additional log message at each database server  
startup, indicating either that protections against member wraparound  
have been engaged, or that they have not.  In the latter case, once  
autovacuum has advanced oldestMultiXid to a sane value, the message  
indicating that the guards have been engaged will appear at the next  
checkpoint.  A few additional messages have also been added at the DEBUG1  
level so that the correct operation of this code can be properly audited.  
  
Along the way, this patch fixes another, related bug in TruncateMultiXact  
that has existed since PostgreSQL 9.3.0: when no MultiXacts exist at  
all, the truncation code looks up NextMultiXactId, which doesn't exist  
yet.  This can lead to TruncateMultiXact removing every file in  
pg_multixact/offsets instead of keeping one around, as it should.  
This in turn will cause the database server to refuse to start  
afterwards.  
  
Patch by me.  Review by Álvaro Herrera, Andres Freund, Noah Misch, and  
Thomas Munro.  
  

doc: Session identifiers truncate, not round, the backend start time.

  
commit   : 99cfd5e136e2a20c77021390a1378d18a24b7388    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 4 Jun 2015 17:57:39 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 4 Jun 2015 17:57:39 -0400    

Click here for diff

  
Joel Jacobson  
  

docs: Fix list of object types pg_table_is_visible() can handle.

  
commit   : 1c645da8ebb5532105481ad77bb1d9a671b1f086    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 4 Jun 2015 17:48:00 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 4 Jun 2015 17:48:00 -0400    

Click here for diff

  
Materialized views and foreign tables were missing from the list,  
probably because they are newer than the other object types that were  
mentioned.  
  
Etsuro Fujita  
  

Second try at stabilizing query plans in rowsecurity regression test.

  
commit   : 1d27842519999cbac7e1cca8beaef053be9c7825    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2015 16:42:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2015 16:42:23 -0400    

Click here for diff

  
This reverts commit 5cdf25e16843dff33dbc2ddc02941458032e3ad4,  
which was almost immediately proven insufficient by the buildfarm.  
  
On second thought, the tables involved are not large enough that  
autovacuum or autoanalyze would notice them; what seems far more  
likely to be the culprit is the database-wide "vacuum analyze"  
in the concurrent gist test.  That thing has given us one headache  
too many, so get rid of it in favor of targeted vacuuming of that  
test's own tables only.  
  

Fix brin regression test so it actually tests cidr.

  
commit   : 1676e4381f48f7bf211f0965ad23abe10a683818    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2015 15:24:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2015 15:24:22 -0400    

Click here for diff

  
The problem noted in my previous commit was simpler than I thought:  
we weren't getting an index plan because the column wasn't indexed.  
  

Tighten the per-operator testing done in brin regression test.

  
commit   : 79454c696bd3346a9f00f5e940398fb01a337fad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2015 14:39:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2015 14:39:52 -0400    

Click here for diff

  
Verify that the number of matches is exactly what it should be, not just  
that it not be zero.  This should help us detect any environment-dependent  
issues.  
  
Also, verify that we're getting the expected type of scan plan (either  
bitmap or seqscan as appropriate).  Right now, this is failing on the  
cidrcol test cases, as shown in the output file.  I'll look into that  
in a bit, but it seems good to commit this as-is temporarily to verify  
that it behaves as expected on the buildfarm.  
  

Fix brin “char” test to actually test what it meant to test.

  
commit   : 78e72794a76fef3233c06800c6046aaad0704a22    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2015 13:50:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2015 13:50:32 -0400    

Click here for diff

  
Casting to char, without quotes, does not give the same results as casting  
to "char".  That meant we were not testing the brin "char" paths at all,  
since we ended up with a text operator not a "char" operator.  
  

Stabilize results of brin regression test.

  
commit   : bac99475eb6e9e6d69a91fee30b5420b8e0115be    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2015 13:46:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2015 13:46:34 -0400    

Click here for diff

  
This test used seqscans on tenk1, with LIMIT, to build test data.  
That works most of the time, but if the synchronized-seqscan logic  
kicks in, we get varying test data.  This seems likely to explain  
the erratic test failures on buildfarm member chipmunk, which uses  
smaller-than-default shared_buffers.  To fix, add ORDER BY clauses to  
force the ordering to be what it was implicitly being assumed to be.  
  
Peter Geoghegan had noticed this with respect to one of the trouble  
spots, though not the ones actually causing the chipmunk issue.  
  

Stabilize query plans in rowsecurity regression test.

  
commit   : 5cdf25e16843dff33dbc2ddc02941458032e3ad4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2015 10:37:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Jun 2015 10:37:06 -0400    

Click here for diff

  
Some recent buildfarm failures can be explained by supposing that  
autovacuum or autoanalyze fired on the tables created by this test,  
resulting in plan changes.  Do a proactive VACUUM ANALYZE on the  
test's principal tables to try to forestall such changes.  
  

Remove -i/–ignore-version option from pg_dump, pg_dumpall and pg_restore.

  
commit   : 232cd63b1f26e2ee3b3e03da8fc7348f4b067946    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 4 Jun 2015 19:54:43 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 4 Jun 2015 19:54:43 +0900    

Click here for diff

  
The commit c22ed3d523782c43836c163c16fa5a7bb3912826 turned  
the -i/--ignore-version options into no-ops and marked as deprecated.  
Considering we shipped that in 8.4, it's time to remove all trace of  
those switches, per discussion. We'd still have to wait a couple releases  
before it'd be safe to use -i for something else, but it'd be a start.  
  

Fix some issues in pg_class.relminmxid and pg_database.datminmxid documentation.

  
commit   : 38d500ac2e5d4d4f3468b505962fb85850c1ff4b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 4 Jun 2015 13:22:49 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 4 Jun 2015 13:22:49 +0900    

Click here for diff

  
- Correct the name of directory which those catalog columns allow to be shrunk.  
- Correct the name of symbol which is used as the value of pg_class.relminmxid  
  when the relation is not a table.  
- Fix "ID ID" typo.  
  
Backpatch to 9.3 where those cataog columns were introduced.  
  

doc: Fix PDF build with FOP

  
commit   : afae1f78547b8ff02cd2d07fe845a28e37a3b272    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 Jun 2015 20:19:47 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 Jun 2015 20:19:47 -0400    

Click here for diff

  
Because of a bug in the DocBook XSL FO style sheet, an xref to a  
varlistentry whose term includes an indexterm fails to build.  One such  
instance was introduced in commit  
5086dfceba79ecd5d1eb28b8f4ed5221838ff3a6.  Fix by adding the upstream  
bug fix to our customization layer.  
  

Fix some questionable edge-case behaviors in add_path() and friends.

  
commit   : 3b0f77601b9f9f3a2e36a813e4cd32c00e0864d6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Jun 2015 18:02:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Jun 2015 18:02:39 -0400    

Click here for diff

  
add_path_precheck was doing exact comparisons of path costs, but it really  
needs to do them fuzzily to be sure it won't reject paths that could  
survive add_path's comparisons.  (This can only matter if the initial cost  
estimate is very close to the final one, but that turns out to often be  
true.)  
  
Also, it should ignore startup cost for this purpose if and only if  
compare_path_costs_fuzzily would do so.  The previous coding always ignored  
startup cost for parameterized paths, which is wrong as of commit  
3f59be836c555fa6; it could result in improper early rejection of paths that  
we care about for SEMI/ANTI joins.  It also always considered startup cost  
for unparameterized paths, which is just as wrong though the only effect is  
to waste planner cycles on paths that can't survive.  Instead, it should  
consider startup cost only when directed to by the consider_startup/  
consider_param_startup relation flags.  
  
Likewise, compare_path_costs_fuzzily should have symmetrical behavior  
for parameterized and unparameterized paths.  In this case, the best  
answer seems to be that after establishing that total costs are fuzzily  
equal, we should compare startup costs whether or not the consider_xxx  
flags are on.  That is what it's always done for unparameterized paths,  
so let's make the behavior for parameterized  paths match.  
  
These issues were noted while developing the SEMI/ANTI join costing fix  
of commit 3f59be836c555fa6, but we chose not to back-patch these fixes,  
because they can cause changes in the planner's choices among  
nearly-same-cost plans.  (There is in fact one minor change in plan choice  
within the core regression tests.)  Destabilizing plan choices in back  
branches without very clear improvements is frowned on, so we'll just fix  
this in HEAD.  
  

Fix planner’s cost estimation for SEMI/ANTI joins with inner indexscans.

  
commit   : 3f59be836c555fa679bbe0ec76de50a8b5cb23e0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Jun 2015 11:58:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Jun 2015 11:58:47 -0400    

Click here for diff

  
When the inner side of a nestloop SEMI or ANTI join is an indexscan that  
uses all the join clauses as indexquals, it can be presumed that both  
matched and unmatched outer rows will be processed very quickly: for  
matched rows, we'll stop after fetching one row from the indexscan, while  
for unmatched rows we'll have an indexscan that finds no matching index  
entries, which should also be quick.  The planner already knew about this,  
but it was nonetheless charging for at least one full run of the inner  
indexscan, as a consequence of concerns about the behavior of materialized  
inner scans --- but those concerns don't apply in the fast case.  If the  
inner side has low cardinality (many matching rows) this could make an  
indexscan plan look far more expensive than it actually is.  To fix,  
rearrange the work in initial_cost_nestloop/final_cost_nestloop so that we  
don't add the inner scan cost until we've inspected the indexquals, and  
then we can add either the full-run cost or just the first tuple's cost as  
appropriate.  
  
Experimentation with this fix uncovered another problem: add_path and  
friends were coded to disregard cheap startup cost when considering  
parameterized paths.  That's usually okay (and desirable, because it thins  
the path herd faster); but in this fast case for SEMI/ANTI joins, it could  
result in throwing away the desired plain indexscan path in favor of a  
bitmap scan path before we ever get to the join costing logic.  In the  
many-matching-rows cases of interest here, a bitmap scan will do a lot more  
work than required, so this is a problem.  To fix, add a per-relation flag  
consider_param_startup that works like the existing consider_startup flag,  
but applies to parameterized paths, and set it for relations that are the  
inside of a SEMI or ANTI join.  
  
To make this patch reasonably safe to back-patch, care has been taken to  
avoid changing the planner's behavior except in the very narrow case of  
SEMI/ANTI joins with inner indexscans.  There are places in  
compare_path_costs_fuzzily and add_path_precheck that are not terribly  
consistent with the new approach, but changing them will affect planner  
decisions at the margins in other cases, so we'll leave that for a  
HEAD-only fix.  
  
Back-patch to 9.3; before that, the consider_startup flag didn't exist,  
meaning that the second aspect of the patch would be too invasive.  
  
Per a complaint from Peter Holzer and analysis by Tomas Vondra.  
  

Minor improvement to txid_current() documentation.

  
commit   : 37013621f3b0e296aa71b812ca9d46871ead95e2    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 3 Jun 2015 12:12:48 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 3 Jun 2015 12:12:48 +0900    

Click here for diff

  
Michael Paquier, reviewed by Christoph Berg and Naoya Anzai  
  

Release notes for 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21.

  
commit   : 82ec7d28211b97a2c9917b7a71edbe6b019578da    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jun 2015 13:27:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Jun 2015 13:27:43 -0400    

Click here for diff

  
Also sneak entries for commits 97ff2a564 et al into the sections for  
the previous releases in the relevant branches.  Those fixes did go out  
in the previous releases, but missed getting documented.  
  

pgindent: add typedef blog URL

  
commit   : ab959cc0ea7ee143e017e18fae23e4269a1ba435    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 1 Jun 2015 11:27:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 1 Jun 2015 11:27:30 -0400    

Click here for diff

  
  

Avoid naming a variable “new”, and remove bogus initializer.

  
commit   : 50ab76d3c19c95589f4eb19683e25cb88a2506e2    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 31 May 2015 22:56:53 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 31 May 2015 22:56:53 -0400    

Click here for diff

  
Per gripe from Tom Lane.  
  

Add a couple of missing JsonbValue type initialisers.

  
commit   : 28b29f7e44534339f88ea914794f8b64e13bc528    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 31 May 2015 22:51:58 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 31 May 2015 22:51:58 -0400    

Click here for diff

  
  

Rename jsonb_replace to jsonb_set and allow it to add new values

  
commit   : 37def4224505f3a23a5eef000f0d05daea59c5b5    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 31 May 2015 20:34:10 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 31 May 2015 20:34:10 -0400    

Click here for diff

  
The function is given a fourth parameter, which defaults to true. When  
this parameter is true, if the last element of the path is missing  
in the original json, jsonb_set creates it in the result and assigns it  
the new value. If it is false then the function does nothing unless all  
elements of the path are present, including the last.  
  
Based on some original code from Dmitry Dolgov, heavily modified by me.  
  
Catalog version bumped.  
  

Make Python tests more portable

  
commit   : 75f9d17638c9c6bec34f80326c35010c47924728    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 31 May 2015 07:10:45 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 31 May 2015 07:10:45 -0400    

Click here for diff

  
Newer Python versions randomize the hash seed for dictionaries,  
resulting in a random output order, which messes up the regression test  
diffs.  
  
Instead, use Python assert to compare the dictionaries with their  
expected value.  
  

pg_upgrade: add missing period in C comment

  
commit   : ac6f22957d2f2999034b6a14d0d4bee25ba95f04    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 29 May 2015 17:44:14 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 29 May 2015 17:44:14 -0400    

Click here for diff

  
  

initdb -S should now have an explicit check that $PGDATA is valid.

  
commit   : 1943c000b7a22d3ca334196cfe3f7b8159b210c2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 May 2015 17:02:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 May 2015 17:02:58 -0400    

Click here for diff

  
The fsync code from the backend essentially assumes that somebody's already  
validated PGDATA, at least to the extent of it being a readable directory.  
That's safe enough for initdb's normal code path too, but "initdb -S"  
doesn't have any other processing at all that touches the target directory.  
To have reasonable error-case behavior, add a pg_check_dir call.  
Per gripe from Peter E.  
  

Remove special cases for ETXTBSY from new fsync’ing logic.

  
commit   : 57e1138bcc621ffeb8b1f1379ac4016a5c34d43e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 May 2015 15:11:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 May 2015 15:11:36 -0400    

Click here for diff

  
The argument that this is a sufficiently-expected case to be silently  
ignored seems pretty thin.  Andres had brought it up back when we were  
still considering that most fsync failures should be hard errors, and it  
probably would be legit not to fail hard for ETXTBSY --- but the same is  
true for EROFS and other cases, which is why we gave up on hard failures.  
ETXTBSY is surely not a normal case, so logging the failure seems fine  
from here.  
  

Check that all aliases of a built-in function have same leakproof property.

  
commit   : 1c8c656b3c217aaffc503ad703dcc60cdabe7445    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 May 2015 13:26:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 May 2015 13:26:21 -0400    

Click here for diff

  
opr_sanity.sql has a test checking that relevant properties of built-in  
functions match when the same C function is referenced by multiple pg_proc  
entries.  The test neglected to check proleakproof, though, and when  
I added that condition it exposed that xideqint4 hadn't been updated to  
match xideq.  So fix that as well, and in consequence bump catversion.  
  
This isn't very critical, so no need to worry about fixing back branches.  
  

Adjust initdb to also not consider fsync’ing failures fatal.

  
commit   : c07d8c963e39980f192e8daca73b7585ef76cc9b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 May 2015 13:05:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 May 2015 13:05:16 -0400    

Click here for diff

  
Make initdb's version of this logic look as much like the backend's  
as possible.  This is much less critical than in the backend since not  
so many people use "initdb -S", but we want the same corner-case error  
handling in both cases.  
  
Back-patch to 9.3 where initdb -S option was introduced.  Before that,  
initdb only had to deal with freshly-created data directories, wherein  
no failures should be expected.  
  
Abhijit Menon-Sen  
  

Revert exporting of internal GUC variable “data_directory”.

  
commit   : da33a3894e0fc440ac53cdc0f2e360e703b13b8c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 May 2015 11:57:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 May 2015 11:57:33 -0400    

Click here for diff

  
This undoes a poorly-thought-out choice in commit 970a18687f9b3058, namely  
to export guc.c's internal variable data_directory.  The authoritative  
variable so far as C code is concerned is DataDir; there is no reason for  
anything except specific bits of GUC code to look at the GUC variable.  
  
After yesterday's commits fixing the fsync-on-restart patch, the only  
remaining misuse of data_directory was in AlterSystemSetConfigFile(),  
which would be much better off just using a relative path anyhow: it's  
less code and it doesn't break if the DBA moves the data directory of a  
running system, which is a case we've taken some pains over in the past.  
  
This is mostly cosmetic, so no need for a back-patch (and I'd be hesitant  
to remove a global variable in stable branches anyway).  
  

Fix fsync-at-startup code to not treat errors as fatal.

  
commit   : d8179b001ae574da00c8f4549577095bf90f3337    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 May 2015 17:33:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 May 2015 17:33:03 -0400    

Click here for diff

  
Commit 2ce439f3379aed857517c8ce207485655000fc8e introduced a rather serious  
regression, namely that if its scan of the data directory came across any  
un-fsync-able files, it would fail and thereby prevent database startup.  
Worse yet, symlinks to such files also caused the problem, which meant that  
crash restart was guaranteed to fail on certain common installations such  
as older Debian.  
  
After discussion, we agreed that (1) failure to start is worse than any  
consequence of not fsync'ing is likely to be, therefore treat all errors  
in this code as nonfatal; (2) we should not chase symlinks other than  
those that are expected to exist, namely pg_xlog/ and tablespace links  
under pg_tblspc/.  The latter restriction avoids possibly fsync'ing a  
much larger part of the filesystem than intended, if the user has left  
random symlinks hanging about in the data directory.  
  
This commit takes care of that and also does some code beautification,  
mainly moving the relevant code into fd.c, which seems a much better place  
for it than xlog.c, and making sure that the conditional compilation for  
the pre_sync_fname pass has something to do with whether pg_flush_data  
works.  
  
I also relocated the call site in xlog.c down a few lines; it seems a  
bit silly to be doing this before ValidateXLOGDirectoryStructure().  
  
The similar logic in initdb.c ought to be made to match this, but that  
change is noncritical and will be dealt with separately.  
  
Back-patch to all active branches, like the prior commit.  
  
Abhijit Menon-Sen and Tom Lane  
  

Remove pgaudit references also.

  
commit   : d5442cb2434c303fa2afc747cdac65df958ff8ac    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Thu, 28 May 2015 13:02:09 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Thu, 28 May 2015 13:02:09 -0400    

Click here for diff

  
Fixes the docs build.  
  

Finish removing pg_audit

  
commit   : cde9cf170cf0f6fbd06b24930dab22d4445e3fb6    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Thu, 28 May 2015 12:48:25 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Thu, 28 May 2015 12:48:25 -0400    

Click here for diff

  
  

  
commit   : 0381fefaa44f04e17dffb7e46e7677374a4fb2c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 May 2015 12:44:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 May 2015 12:44:31 -0400    

Click here for diff

  
The previous coding suffered a null-pointer dereference if it found any  
symlink at the top level of $PGDATA.  Fix that, and teach it to recurse  
into a symlink for pg_xlog, but not anything else.  
  
Per note from Abhijit Menon-Sen.  
  

Remove pg_audit

  
commit   : e5f1a4f1e350f1e72531d032eaa9095ba5baeb51    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Thu, 28 May 2015 12:41:26 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Thu, 28 May 2015 12:41:26 -0400    

Click here for diff

  
This removes pg_audit, per discussion:  
  
20150528082038.GU26667@tamriel.snowman.net  
  

  
commit   : 32f628be74d8ab43423ca7913b81f7eb21b312d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 May 2015 12:17:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 May 2015 12:17:22 -0400    

Click here for diff

  
Ensure that we null-terminate the result string (one place in pg_rewind).  
Be paranoid about out-of-range results from readlink() (should not happen,  
but there is no good reason for some call sites to be careful about it and  
others not).  Consistently use the whole buffer, not sometimes one byte  
less.  Ensure we emit an appropriate errcode() in all cases.  Spell the  
error messages the same way.  
  
The only serious bug here is the missing null-termination in pg_rewind,  
which is new code, so no need for a back-patch.  
  
Abhijit Menon-Sen and Tom Lane  
  

Fix pg_get_functiondef() to print a function’s LEAKPROOF property.

  
commit   : f46edf479e2468a08caca2a03ec7e258930a7161    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 May 2015 11:24:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 May 2015 11:24:37 -0400    

Click here for diff

  
Seems to have been an oversight in the original leakproofness patch.  
Per report and patch from Jeevan Chalke.  
  
In passing, prettify some awkward leakproof-related code in AlterFunction.  
  

Fix portability issue in isolationtester grammar.

  
commit   : aa9eac45ea868e6ddabc4eb076d18be10ce84c6a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 May 2015 19:14:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 May 2015 19:14:39 -0400    

Click here for diff

  
specparse.y and specscanner.l used "string" as a token name.  Now, bison  
likes to define each token name as a macro for the token code it assigns,  
which means those names are basically off-limits for any other use within  
the grammar file or included headers.  So names as generic as "string" are  
dangerous.  This is what was causing the recent failures on protosciurus:  
some versions of Solaris' sys/kstat.h use "string" as a field name.  
With late-model bison we don't see this problem because the token macros  
aren't defined till later (that is why castoroides didn't show the problem  
even though it's on the same machine).  But protosciurus uses bison 1.875  
which defines the token macros up front.  
  
This land mine has been there from day one; we'd have found it sooner  
except that protosciurus wasn't trying to run the isolation tests till  
recently.  
  
To fix, rename the token to "string_literal" which is hopefully less  
likely to collide with names used by system headers.  Back-patch to  
all branches containing the isolation tests.  
  

Revert “Add all structured objects passed to pushJsonbValue piecewise.”

  
commit   : f41042cea0619eaa812e630f87472e805b0dfdb0    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 26 May 2015 22:54:55 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 26 May 2015 22:54:55 -0400    

Click here for diff

  
This reverts commit 54547bd87f49326d67051254c363e6597d16ffda.  
  
This appears to have been a thinko on my part. I will try to come up  
wioth a better solution.  
  

Revert “Simplify addJsonbToParseState()”

  
commit   : 956cc4434c3a8e69813b325618402508d1dbdcd9    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 26 May 2015 22:54:11 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 26 May 2015 22:54:11 -0400    

Click here for diff

  
This reverts commit fba12c8c6c4159e1923958a4006b26f3cf873254.  
  
This relied on a commit that is also being reverted.  
  

Remove configure check prohibiting threaded libpython on OpenBSD.

  
commit   : 86832eb8912b9cac0f4961facb9efda81828e214    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 May 2015 22:14:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 May 2015 22:14:59 -0400    

Click here for diff

  
According to recent tests, this case now works fine, so there's no reason  
to reject it anymore.  (Even if there are still some OpenBSD platforms  
in the wild where it doesn't work, removing the check won't break any case  
that worked before.)  
  
We can actually remove the entire test that discovers whether libpython  
is threaded, since without the OpenBSD case there's no need to know that  
at all.  
  
Per report from Davin Potts.  Back-patch to all active branches.  
  

Suppress occasional failures in brin regression test.

  
commit   : 1f303fd1be51f26553e7c95d8696aa4e28ece1c6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 May 2015 14:10:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 May 2015 14:10:46 -0400    

Click here for diff

  
brin.sql included a call of brin_summarize_new_values(), and expected  
it to always report exactly 5 summarization events.  This failed sometimes  
during parallel regression tests, as a consequence of the database-wide  
VACUUM in gist.sql getting there first.  The most future-proof way  
to avoid variation in the test results is to forget about using  
brin_summarize_new_values() and just do a plain "VACUUM brintest",  
which will exercise the same code anyway.  
  
Having done that, there's no need for preventing autovacuum on brintest;  
doing so just reduces the scope of test coverage, so let's not.  
  

Simplify addJsonbToParseState()

  
commit   : fba12c8c6c4159e1923958a4006b26f3cf873254    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 26 May 2015 11:46:02 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 26 May 2015 11:46:02 -0400    

Click here for diff

  
This function no longer needs to walk non-scalar structures passed to  
it, following commit 54547bd87f49326d67051254c363e6597d16ffda.  
  

Add all structured objects passed to pushJsonbValue piecewise.

  
commit   : 54547bd87f49326d67051254c363e6597d16ffda    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 26 May 2015 11:16:52 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 26 May 2015 11:16:52 -0400    

Click here for diff

  
Commit 9b74f32cdbff8b9be47fc69164eae552050509ff did this for objects of  
type jbvBinary, but in trying further to simplify some of the new jsonb  
code I discovered that objects of type jbvObject or jbvArray passed as  
WJB_ELEM or WJB_VALUE also caused problems. These too are now added  
component by component.  
  
Backpatch to 9.4.  
  

Fix valgrind’s “unaddressable bytes” whining about BRIN code.

  
commit   : 79f2b5d583e2e2a7ccd13e31d0e20a900c8f2f61    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 May 2015 21:56:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 May 2015 21:56:19 -0400    

Click here for diff

  
brin_form_tuple calculated an exact tuple size, then palloc'd and  
filled just that much.  Later, brin_doinsert or brin_doupdate would  
MAXALIGN the tuple size and tell PageAddItem that that was the size  
of the tuple to insert.  If the original tuple size wasn't a multiple  
of MAXALIGN, the net result would be that PageAddItem would memcpy  
a few more bytes than the palloc request had been for.  
  
AFAICS, this is totally harmless in the real world: the error is a  
read overrun not a write overrun, and palloc would certainly have  
rounded the request up to a MAXALIGN multiple internally, so there's  
no chance of the memcpy fetching off the end of memory.  Valgrind,  
however, is picky to the byte level not the MAXALIGN level.  
  
Fix it by pushing the MAXALIGN step back to brin_form_tuple.  (The other  
possible source of tuples in this code, brin_form_placeholder_tuple,  
was already producing a MAXALIGN'd result.)  
  
In passing, be a bit more paranoid about internal allocations in  
brin_form_tuple.  
  

pgindent: document location of “all” typedef lists

  
commit   : 3503003eb70c5a56c59afb20b4c7abec6cf9eb86    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 25 May 2015 16:53:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 25 May 2015 16:53:48 -0400    

Click here for diff

  
  

Explain CHECK constraint handling in postgres_fdw’s IMPORT FOREIGN SCHEMA.

  
commit   : e70ec8230a2c0e7363bb7abf4d55dddbdec89fe1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 May 2015 14:12:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 May 2015 14:12:51 -0400    

Click here for diff

  
The existing documentation could easily be misinterpreted, and it failed to  
explain the inconsistent-evaluation hazard that deterred us from supporting  
automatic importing of check constraints.  Revise it.  
  
Etsuro Fujita, further expanded by me  
  

Update README.tuplock

  
commit   : cdbdc4382743fcfabb3437ea7c4d103adaa01324    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 May 2015 15:09:05 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 May 2015 15:09:05 -0300    

Click here for diff

  
Multixact truncation is now handled differently, and this file hadn't  
gotten the memo.  
  
Per note from Amit Langote.  I didn't use his patch, though.  
  
Also update the description of infomask bits, which weren't completely up  
to date either.  This commit also propagates b01a4f6838 back to 9.3 and  
9.4, which apparently I failed to do back then.  
  

Clean up and simplify jsonb_concat code.

  
commit   : 6739aa298b5e3260481a2d5723a75b057d6119c6    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 25 May 2015 11:43:06 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 25 May 2015 11:43:06 -0400    

Click here for diff

  
Some of this is made possible by commit  
9b74f32cdbff8b9be47fc69164eae552050509ff which lets pushJsonbValue  
handle binary Jsonb values, meaning that clients no longer have to, and  
some is just doing things in simpler and more straightforward ways.  
  

pgindent: fix typo

  
commit   : 8339e70da6682059f7ab40f0c0b0dfcdcb78761d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 25 May 2015 08:08:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 25 May 2015 08:08:05 -0400    

Click here for diff

  
Report by Michael Paquier  
  

Fix rescan of IndexScan node with the new lossy GiST distance functions.

  
commit   : 12e6c5a6cae1e34da2d320390993010b6e15ba9e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 25 May 2015 14:42:21 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 25 May 2015 14:42:21 +0300    

Click here for diff

  
Must reset the "reached end" flag and reorder queue at rescan.  
  
Per report from Regina Obe, bug #13349  
  

pgindent: more doc updates for skipping asm files

  
commit   : 266b6984cd7391e42770ca3a9922a9e8b1d4d7d3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 24 May 2015 21:51:42 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 24 May 2015 21:51:42 -0400    

Click here for diff

  
  

Revert 9.5 pgindent changes to atomics directory files

  
commit   : befa3e648ce018d84cd2a0df701927c56fe3da4e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 24 May 2015 21:44:57 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 24 May 2015 21:44:57 -0400    

Click here for diff

  
This is because there are many __asm__ blocks there that pgindent messes  
up.  Also configure pgindent to skip that directory in the future.  
  

Manual cleanup of pgindent results.

  
commit   : 2aa0476dc38f7e510b8cde627e83b4c76fa05d61    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 May 2015 15:04:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 May 2015 15:04:10 -0400    

Click here for diff

  
Fix some places where pgindent did silly stuff, often because project  
style wasn't followed to begin with.  (I've not touched the atomics  
headers, though.)  
  

Rename pg_shdepend.c’s typedef “objectType” to SharedDependencyObjectType.

  
commit   : 17b48a1a9f87f7479d38dcc78a27c23f1f8124f8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 May 2015 13:03:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 May 2015 13:03:45 -0400    

Click here for diff

  
The name objectType is widely used as a field name, and it's pure luck that  
this conflict has not caused pgindent to go crazy before.  It messed up  
pg_audit.c pretty good though.  Since pg_shdepend.c doesn't export this  
typedef and only uses it in three places, changing that seems saner than  
changing the field usages.  
  
Back-patch because we're contemplating using the union of all branch  
typedefs for future pgindent runs, so this won't fix anything if it  
stays the same in back branches.  
  

Add a bit more commentary about regex’s colormap tree data structure.

  
commit   : 23116d5437d0e8d077e7fd5391f5fa0fc781b7d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 May 2015 12:40:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 May 2015 12:40:38 -0400    

Click here for diff

  
Per an off-list question from Piotr Stefaniak.  
  

Remove no-longer-required function declarations.

  
commit   : 91e79260f636ab4d5a43910b6a38bc75651ad14c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 May 2015 12:20:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 May 2015 12:20:23 -0400    

Click here for diff

  
Remove a bunch of "extern Datum foo(PG_FUNCTION_ARGS);" declarations that  
are no longer needed now that PG_FUNCTION_INFO_V1(foo) provides that.  
  
Some of these were evidently missed in commit e7128e8dbb305059, but others  
were cargo-culted in in code added since then.  Possibly that can be blamed  
in part on the fact that we'd not fixed relevant documentation examples,  
which I've now done.  
  

pgindent run for 9.5

  
commit   : 807b9e0dff663c5da875af7907a5106c0ff90673    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 May 2015 21:35:49 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 May 2015 21:35:49 -0400    

Click here for diff

  
  

Update typedef file in preparation for pgindent run

  
commit   : 225892552bd3052982d2b97b749e5945ea71facc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 May 2015 21:20:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 May 2015 21:20:37 -0400    

Click here for diff

  
  

Improve pgindent instructions regarding Perl backup files

  
commit   : 58affdfb88a7705df477f0cfc0710bf638ccd3e9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 May 2015 21:09:00 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 23 May 2015 21:09:00 -0400    

Click here for diff

  
  

Add error check for lossy distance functions in index-only scans.

  
commit   : f84c8601d604811a530dadb53ddb52f08639e72b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 May 2015 16:24:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 May 2015 16:24:31 -0400    

Click here for diff

  
Maybe we should actually support this, but for the moment let's just  
throw an error if the opclass tries it.  
  

Fix incorrect snprintf() limit.

  
commit   : 72809480d658fbc0654239b2f089991c077c676a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 May 2015 16:05:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 May 2015 16:05:52 -0400    

Click here for diff

  
Typo in commit 7cbee7c0a.  No practical effect since the buffer should  
never actually be overrun, but various compilers and static analyzers will  
whine about it.  
  
Petr Jelinek  
  

Still more fixes for lossy-GiST-distance-functions patch.

  
commit   : 821b821a2421beaa58225ff000833df69fb962c5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 May 2015 15:22:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 May 2015 15:22:25 -0400    

Click here for diff

  
Fix confusion in documentation, substantial memory leakage if float8 or  
float4 are pass-by-reference, and assorted comments that were obsoleted  
by commit 98edd617f3b62a02cb2df9b418fcc4ece45c7ec0.  
  

Fix yet another bug in ON CONFLICT rule deparsing.

  
commit   : 284bef297733e553c73f1c858e0ce1532f754d18    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 23 May 2015 02:16:24 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 23 May 2015 02:16:24 +0200    

Click here for diff

  
Expand testing of rule deparsing a good bit, it's evidently needed.  
  
Author: Peter Geoghegan, Andres Freund  
Discussion: CAM3SWZQmXxZhQC32QVEOTYfNXJBJ_Q2SDENL7BV14Cq-zL0FLg@mail.gmail.com  
  

Remove the new UPSERT command tag and use INSERT instead.

  
commit   : 631d7490074cdaef8026db57a5f2772b8730f600    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 23 May 2015 00:49:27 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 23 May 2015 00:49:27 +0200    

Click here for diff

  
Previously, INSERT with ON CONFLICT DO UPDATE specified used a new  
command tag -- UPSERT.  It was introduced out of concern that INSERT as  
a command tag would be a misrepresentation for ON CONFLICT DO UPDATE, as  
some affected rows may actually have been updated.  
  
Alvaro Herrera noticed that the implementation of that new command tag  
was incomplete; in subsequent discussion we concluded that having it  
doesn't provide benefits that are in line with the compatibility breaks  
it requires.  
  
Catversion bump due to the removal of PlannedStmt->isUpsert.  
  
Author: Peter Geoghegan  
Discussion: 20150520215816.GI5885@postgresql.org  
  

Fix recently-introduced crash in array_contain_compare().

  
commit   : 49ad32d5d99cb4a79bf648c0b7f9eca19b54cf1d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 May 2015 18:36:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 May 2015 18:36:48 -0400    

Click here for diff

  
Silly oversight in commit 1dc5ebc9077ab742079ce5dac9a6664248d42916:  
when array2 is an expanded array, it might have array2->xpn.dnulls equal  
to NULL, indicating the array is known null-free.  The code wasn't  
expecting that, because it formerly always used deconstruct_array() which  
always delivers a nulls array.  
  
Per bug #13334 from Regina Obe.  
  

Unpack jbvBinary objects passed to pushJsonbValue

  
commit   : 5302760a50332a684e35b9865ff47ff5fd4970c2    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 22 May 2015 10:21:41 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 22 May 2015 10:21:41 -0400    

Click here for diff

  
pushJsonbValue was accepting jbvBinary objects passed as WJB_ELEM or  
WJB_VALUE data. While this succeeded, when those objects were later  
encountered in attempting to convert the result to Jsonb, errors  
occurred. With this change we ghuarantee that a JSonbValue constructed  
from calls to pushJsonbValue does not contain any jbvBinary objects.  
This cures a problem observed with jsonb_delete.  
  
This means callers of pushJsonbValue no longer need to perform this  
unpacking themselves. A subsequent patch will perform some cleanup in  
that area.  
  
The error was not triggered by any 9.4 code, but this is a publicly  
visible routine, and so the error could be exercised by third party  
code, therefore backpatch to 9.4.  
  
Bug report from Peter Geoghegan, fix by me.  
  

Minor enhancement of readability of ALTER TABLE syntax in the doc.

  
commit   : 6d1733fa90a3f8037c7c815ed6ab4d97c295e525    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 22 May 2015 21:42:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 22 May 2015 21:42:15 +0900    

Click here for diff

  
Fabrízio Mello  
  

At promotion, don’t leave behind a partial segment on the old timeline.

  
commit   : 7cbee7c0a1db668c60c020a3fd1e3234daa562a9    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 21 May 2015 15:28:22 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 21 May 2015 15:28:22 +0300    

Click here for diff

  
With commit de768844, a copy of the partial segment was archived with the  
.partial suffix, but the original file was still left in pg_xlog, so it  
didn't actually solve the problems with archiving the partial segment that  
it was supposed to solve. With this patch, the partial segment is renamed  
rather than copied, so we only archive it with the .partial suffix.  
  
Also be more robust in detecting if the last segment is already being  
archived. Previously I used XLogArchiveIsBusy() for that, but that's not  
quite right. With archive_mode='always', there might be a .ready file for  
it, and we don't want to rename it to .partial in that case.  
  
The old segment is needed until we're fully committed to the new timeline,  
i.e. until we've written the end-of-recovery WAL record and updated the  
min recovery point and timeline in the control file. So move the renaming  
later in the startup sequence, after all that's been done.  
  

More fixes for lossy-GiST-distance-functions patch.

  
commit   : c5dd8ead403f85bd041590d2e3e79b72830472d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 May 2015 19:47:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 May 2015 19:47:48 -0400    

Click here for diff

  
Paul Ramsey reported that commit 35fcb1b3d038a501f3f4c87c05630095abaaadab  
induced a core dump on commuted ORDER BY expressions, because it was  
assuming that the indexorderby expression could be found verbatim in the  
relevant equivalence class, but it wasn't there.  We really don't need  
anything that complicated anyway; for the data types likely to be used for  
index ORDER BY operators in the foreseeable future, the exprType() of the  
ORDER BY expression will serve fine.  (The case where we'd have to work  
harder is where the ORDER BY expression's result is only binary-compatible  
with the declared input type of the ordering operator; long before worrying  
about that, one would need to get rid of GiST's hard-wired assumption that  
said datatype is float8.)  
  
Aside from fixing that crash and adding a regression test for the case,  
I did some desultory code review:  
  
nodeIndexscan.c was likewise overthinking how hard it ought to work to  
identify the datatype of the ORDER BY expressions.  
  
Add comments explaining how come nodeIndexscan.c can get away with  
simplifying assumptions about NULLS LAST ordering and no backward scan.  
  
Revert no-longer-needed changes of find_ec_member_for_tle(); while the  
new definition was no worse than the old, it wasn't better either, and  
it might cause back-patching pain.  
  
Revert entirely bogus additions to genam.h.  
  

Improve packing/alignment annotation for ItemPointerData.

  
commit   : d4b538ea367de43b2f2b939621272682417cd290    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 May 2015 17:21:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 May 2015 17:21:46 -0400    

Click here for diff

  
We want this struct to be exactly a series of 3 int16 words, no more  
and no less.  Historically, at least, some ARM compilers preferred to  
pad it to 8 bytes unless coerced.  Our old way of doing that was just  
to use __attribute__((packed)), but as pointed out by Piotr Stefaniak,  
that does too much: it also licenses the compiler to give the struct  
only byte-alignment.  We don't want that because it adds access overhead,  
possibly quite significant overhead.  According to the GCC manual, what  
we want requires also specifying __attribute__((align(2))).  It's not  
entirely clear if all the relevant compilers accept this pragma as well,  
but we can hope the buildfarm will tell us if not.  We can also add a  
static assertion that should fire if the compiler padded the struct.  
  
Since the combination of these pragmas should define exactly what we  
want on any compiler that accepts them, let's try using them wherever  
we think they exist, not only for __arm__.  (This is likely to expose  
that the conditional definitions in c.h are inadequate, but finding  
that out would be a good thing.)  
  
The immediate motivation for this is that the current definition of  
ExecRowMark allows its curCtid field to be misaligned.  It is not clear  
whether there are any other uses of ItemPointerData with a similar hazard.  
We could change the definition of ExecRowMark if this doesn't work, but  
it would be far better to have a future-proof fix.  
  
Piotr Stefaniak, some further hacking by me  
  

Correct two mistakes in the ALTER FOREIGN TABLE reference page.

  
commit   : 160a9aaabf400106232e7e6fce0966ee5fdf84e2    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 21 May 2015 11:16:33 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 21 May 2015 11:16:33 -0400    

Click here for diff

  
Etsuro Fujita  
  

Correct the names of pgstattuple_approx output columns in the doc.

  
commit   : cad3708960ef2da237b93f835d706197f16e5492    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 21 May 2015 20:51:52 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 21 May 2015 20:51:52 +0900    

Click here for diff

  
  

Make recovery_target_action = pause work.

  
commit   : 85d0e661aae656d3ec710dab24f883c4b4ef90da    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 21 May 2015 13:56:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 21 May 2015 13:56:17 +0900    

Click here for diff

  
Previously even if recovery_target_action was set to pause and  
the recovery target was reached, the recovery could never be paused.  
Because the setting of pause was *always* overridden with that of  
shutdown unexpectedly. This override is valid and intentional  
if hot_standby is not enabled because there is no way to resume  
the paused recovery in this case and the setting of pause is  
completely useless. But not if hot_standby is enabled.  
  
This patch changes the code so that the setting of pause is overridden  
with that of shutdown only when hot_standby is not enabled.  
  
Bug reported by Andres Freund  
  

Another typo fix.

  
commit   : a6a66bd647d471aeb55d8ba3e24d197ccd8a5abb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 May 2015 14:50:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 May 2015 14:50:22 -0400    

Click here for diff

  
In the spirit of the season.  
  

Fix more typos in comments.

  
commit   : fa60fb63e511e7bbcf57ce972338711593a5e7c9    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 20 May 2015 19:44:46 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 20 May 2015 19:44:46 +0300    

Click here for diff

  
Patch by CharSyam, plus a few more I spotted with grep.  
  

Collection of typo fixes.

  
commit   : 4fc72cc7bb9d2105261b8ee45558af50d788cd19    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 20 May 2015 16:18:11 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 20 May 2015 16:18:11 +0300    

Click here for diff

  
Use "a" and "an" correctly, mostly in comments. Two error messages were  
also fixed (they were just elogs, so no translation work required). Two  
function comments in pg_proc.h were also fixed. Etsuro Fujita reported one  
of these, but I found a lot more with grep.  
  
Also fix a few other typos spotted while grepping for the a/an typos.  
For example, "consists out of ..." -> "consists of ...". Plus a "though"/  
"through" mixup reported by Euler Taveira.  
  
Many of these typos were in old code, which would be nice to backpatch to  
make future backpatching easier. But much of the code was new, and I didn't  
feel like crafting separate patches for each branch. So no backpatching.  
  

Fix spelling in comment

  
commit   : f6a54fefc299b933052885bb0532c476d382cc71    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 19 May 2015 18:37:46 -0400    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 19 May 2015 18:37:46 -0400    

Click here for diff