PostgreSQL 9.1.19 commit log

Stamp 9.1.19.

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

Click here for diff

  
  

doc: Update URLs of external projects

  
commit   : 21369340f7c0d81a4473f552a1bf700c53224b5b    
  
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

  
  

Translation updates

  
commit   : e01548b5e2af51294263b336212abcf1d04ea2ca    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 5 Oct 2015 10:45:18 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 5 Oct 2015 10:45:18 -0400    

Click here for diff

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

Last-minute updates for release notes.

  
commit   : 7bb63b2f8451dad154f9314efc3c5d9714dc4bfe    
  
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   : 93837732f71f3faa61591090e5923a274cfceece    
  
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)  
  

Prevent stack overflow in query-type functions.

  
commit   : 879877b00bb54ba9dcdef0d218bd36c4e5404d6f    
  
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   : 9581e2699f6379e29151b0bef04ca45a06f5afe0    
  
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.  
  

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

  
commit   : 48f6310bc5b0a2d883c9439fbc7eb1bd7bd4833d    
  
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  
  

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

  
commit   : 7116a3e98a465a4dced4ecf0b330e0da4bd79873    
  
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  
  

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

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

Click here for diff

  
  

Further twiddling of nodeHash.c hashtable sizing calculation.

  
commit   : d84cc40e4bbaa3e708029e0744cba1566ebff324    
  
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 possible “invalid memory alloc request size” failure in nodeHash.c.

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

Click here for diff

  
Limit the size of the hashtable pointer array to not more than  
MaxAllocSize.  We've seen reports of failures due to this in HEAD/9.5,  
and it seems possible in older branches as well.  The change in  
NTUP_PER_BUCKET in 9.5 may have made the problem more likely, but  
surely it didn't introduce it.  
  
Tomas Vondra, slightly modified by me  
  

Update time zone data files to tzdata release 2015g.

  
commit   : 3a68e0a101bc80d6e14f743152017aa4d9b4bf0c    
  
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.  
  

Add recursion depth protection to LIKE matching.

  
commit   : f80af01174fa1aafa97b9464f31db2b554d26f47    
  
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   : e7de1bc0979ad81789864e6c2d346a5c16f28ad2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 14:51:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 14:51:59 -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   : 6301549550b7eab46435dd059a9cb9b54dd67033    
  
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   : da8ff292026482d81a4b5068c90b508b5f96475d    
  
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   : 3b0c1d9573d47b3dad208dc055e0d0bd45d54f16    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 13:30:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 Oct 2015 13:30:43 -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.  
  

Fix documentation error in commit 8703059c6b55c427100e00a09f66534b6ccbfaa1.

  
commit   : b44a55fa9563afcee05fda28fc9f0b0204d46d4d    
  
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.  
  

Improve LISTEN startup time when there are many unread notifications.

  
commit   : 2bbe8a6847a0b449a96b29a1e2d3ed7b9a55ef37    
  
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  
  

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

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

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

  
commit   : 54499a14fcfc44adfc5354ae801a49c12776073b    
  
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.  
  

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

  
commit   : f8864347670a9f837c83cde90366b2df72ab4a43    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Sep 2015 12:20:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Sep 2015 12:20:46 -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   : c48623d8db8558036771e9ee0eeff132f8ea30f8    
  
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   : 7ddadacec4ddea5d0b2e7452ec7adccd015c3bb6    
  
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.  
  

Lower *_freeze_max_age minimum values.

  
commit   : ff090bbb76b24d8070a8c1a5f434f912d908ec19    
  
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: 9.0 (in parts)  
  

Docs: fix typo in to_char() example.

  
commit   : f5f9d1b74e9cbf3a19ef947ac36376f73a0c10f5    
  
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.  
  

Fix possible internal overflow in numeric multiplication.

  
commit   : 5f79730ec0f015e3168e822ee25554cff5fbe070    
  
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.  
  

Restrict file mode creation mask during tmpfile().

  
commit   : 5dc49efe9012793110ef5dab9a9a1a7730a70e3f    
  
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   : 553ce7e9a8d147cae75f0656a628c29dcbe498d8    
  
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   : a369ef9136885ac2c3eb46439587e1c44a5d302b    
  
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.  
  

Fix low-probability memory leak in regex execution.

  
commit   : 28c396134e0640e21610a984b89393825753b30d    
  
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.  
  

Fix documentation of regular expression character-entry escapes.

  
commit   : dad7ea7e4dcc9ebdfb5480aa91cd1424135214e9    
  
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.  
  

Remove set-but-not-used variable.

  
commit   : 06a1ada7935acce6c6b9f5569ca3da9260a50784    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Sep 2015 11:11:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 12 Sep 2015 11:11:08 -0400    

Click here for diff

  
In branches before 9.3, commit 8703059c6 caused join_is_legal()'s  
unique_ified variable to become unused, since its only remaining  
use is for LATERAL-related tests which don't exist pre-9.3.  
My compiler didn't complain about that, but Peter's does.  
  

pg_dump, pg_upgrade: allow postgres/template1 tablespace moves

  
commit   : c5391e9334c32fb2cb9251f0e7bb824bb50c9d8c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 Sep 2015 15:51:10 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 11 Sep 2015 15:51:10 -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  
  

Revert “Fix typo in setrefs.c”

  
commit   : a3b420e6c84e47669fb5bc99036361cab03363e8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2015 10:26:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Sep 2015 10:26:36 -0400    

Click here for diff

  
This reverts commit 7f0ca9a33682a73c150f14baabdce2d973c6101a.  
  

Fix typo in setrefs.c

  
commit   : 7f0ca9a33682a73c150f14baabdce2d973c6101a    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Thu, 10 Sep 2015 09:22:40 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Thu, 10 Sep 2015 09:22:40 -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   : 5bd86b21dfbca103ffb142da55cb25211395d3a9    
  
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   : 60fe73b79ce8a65ee4eda34a2f4f204a95081603    
  
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  
  

Add gin_fuzzy_search_limit to postgresql.conf.sample.

  
commit   : da5fb2af3520acbc5230a77549cfd1a1c874bfb9    
  
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   : cedb3e66ae718d097a065ec0d357164332c15d80    
  
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

  
  

Add more sanity checks in contrib/sslinfo

  
commit   : adc48eaa4411ef785bb328ed1311cb707706a568    
  
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   : 0252d7777299a1325f29a70f761c8250fe8c4b6b    
  
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   : 364c0235708af88f5013f7a0b35ab3e615fbeb0b    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 7 Sep 2015 17:18:45 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 7 Sep 2015 17:18:45 +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   : e3fa55d14324677391e9c1ff6342e6ffa7d560b0    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 7 Sep 2015 15:22:18 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Mon, 7 Sep 2015 15:22:18 +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   : 07cef3eb8a621690ff5e1a1d576656284957caf1    
  
author   : Greg Stark <stark@mit.edu>    
date     : Sun, 6 Sep 2015 04:02:57 +0100    
  
committer: Greg Stark <stark@mit.edu>    
date     : Sun, 6 Sep 2015 04:02:57 +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  
  

Fix misc typos.

  
commit   : 20d309a8f4c3c033b1d1202b77d1115a9d5bfb2b    
  
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 subtransaction cleanup after an outer-subtransaction portal fails.

  
commit   : dae1c9480e770a2c6f1716f3f0e1ad186cd7e7b3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2015 13:36:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Sep 2015 13:36:50 -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  
  

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

  
commit   : 14b497cfbbbbd7663edb14a0d666ed511b81bfe7    
  
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.  
  

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

Add a small cache of locks owned by a resource owner in ResourceOwner.

  
commit   : 9b1b9446f563c85d1fe6bb8fca91a2608f3b9577    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Aug 2015 12:22:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Aug 2015 12:22:10 -0400    

Click here for diff

  
Back-patch 9.3-era commit eeb6f37d89fc60c6449ca12ef9e91491069369cb, to  
improve the older branches' ability to cope with pg_dump dumping a large  
number of tables.  
  
I back-patched into 9.2 and 9.1, but not 9.0 as it would have required a  
significant amount of refactoring, thus negating the argument that this  
is by-now-well-tested code.  
  
Jeff Janes, reviewed by Amit Kapila and Heikki Linnakangas.  
  

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

  
commit   : 31934dd3ddc8efe1066fcc39137a142749556479    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Aug 2015 19:12:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 25 Aug 2015 19:12:46 -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.  
  

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

  
commit   : 87b8c9e12f3025b70bd040c42d7d5f39ef9314bc    
  
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  
  

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

  
commit   : 1d190d095ff8e7d11877fc7d4dc82727871a91c1    
  
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   : f2ae044babe846f36b42577dc91b25b1cc40f8b9    
  
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.  
  

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

  
commit   : 17aa3c2d13a050a264bd3fee954ae98c0ae14ecf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Aug 2015 19:22:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Aug 2015 19:22:38 -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  
  

Improve documentation about MVCC-unsafe utility commands.

  
commit   : 138f76533cdcbf4b6c61ba9f8d92dd74b332ccba    
  
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.  
  

Use fuzzy path cost tiebreaking rule in our oldest supported branches.

  
commit   : 3218f8c33612baca0a1f44d4a243c598ddebad9d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Aug 2015 11:02:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Aug 2015 11:02:17 -0400    

Click here for diff

  
We've been doing it that way since 9.2, cf commit 33e99153e93b9acc,  
but some recently-added regression test cases are making a few buildfarm  
members fail (ie choose the "wrong" plan) in 9.0 and 9.1 due to  
platform-specific roundoff differences in cost calculations.  To fix,  
back-port the patch that made add_path treat cost difference ratios of  
less than 1e-10 as equal.  
  

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

  
commit   : 8749aafde2179de243bc8ffeec23a28a94ec5def    
  
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  
  

Fix declaration of isarray variable.

  
commit   : 665ae7f9b4a9f5763e10eddb6761d3c95ffccc55    
  
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.  
  

  
commit   : 4390ba7bf937f56f647359b52e6ba04f31b21901    
  
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.  
  

This routine was calling ecpg_alloc to allocate to memory but did not actually check the returned pointer allocated, potentially NULL which could be the result of a malloc call.

  
commit   : a2b2565fc9318b8903ef4821bc0be40a64810aec    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Thu, 5 Feb 2015 15:12:34 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Thu, 5 Feb 2015 15:12:34 +0100    

Click here for diff

  
Issue noted by Coverity, fixed by Michael Paquier <michael@otacoo.com>  
  

Fix some possible low-memory failures in regexp compilation.

  
commit   : 7a801ba8ce7befc2309ece2ca918eb688c67fda9    
  
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.  
  

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

  
commit   : 34f1a85e513d56980417afe4b47454ffe951bb26    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2015 20:10:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Aug 2015 20:10:16 -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   : af932fff28d4f7c28d9ca4f68cb1d3bbc0bb696d    
  
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.  
  

Further fixes for degenerate outer join clauses.

  
commit   : 656b1e8cf358990b7700448d3b9e85202105cde0    
  
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.  
  

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

  
commit   : 48d4f1e39df53ef3ab44fde2ff84ea778f672a9f    
  
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.  
  

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

  
commit   : dacbdda1092e20507249bade076c859993f5e837    
  
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   : 270a877cca21cf0252ae7c81dd085ae61233ab56    
  
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   : 9965aff1ca7ec0f6218ff845a47eeac34f44c425    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Aug 2015 18:18:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Aug 2015 18:18:47 -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.  
  

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

  
commit   : 4e51ea8fd26f743d92cd35905eac334aafe2b1cc    
  
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.  
  

contrib/isn now needs a .gitignore file.

  
commit   : 1e1bb203bcfdb90ef81e97169812a5f5f942b124    
  
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 output of ISBN-13 numbers beginning with 979.

  
commit   : 2d19a0e977080713bd7bb370b20a0025fba6c794    
  
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   : f1e84d3ebd6062f5bb25cdc7017be1ffa3364f49    
  
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 some planner issues with degenerate outer join clauses.

  
commit   : b9dfa07e8ebc4b6fded7a64038873e589eebd7df    
  
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.  
  

Avoid some zero-divide hazards in the planner.

  
commit   : ea6e286491210e4ec2ddd542faccfe9227eb890f    
  
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.  
  

Blacklist xlc 32-bit inlining.

  
commit   : d20327a4fdc13ca4a1ce25c91ceaf43927b6dc3c    
  
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.  
  

Update our documentation concerning where to create data directories.

  
commit   : adf0072ab8ae283ab26793f0cd8acb5685910b3c    
  
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.  
  

Reduce chatter from signaling of autovacuum workers.

  
commit   : 3f12041e7ca85ef57e48f0a12f6ae3e32c2e442f    
  
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.  
  

Disable ssl renegotiation by default.

  
commit   : 624a3c9befeed42c48d38871a437b2b35dc92898    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 28 Jul 2015 21:50:11 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 28 Jul 2015 21:50:11 +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: Michael Paquier, with changes by me  
Discussion: 20150624144148.GQ4797@alap3.anarazel.de  
Backpatch: 9.0-9.4; 9.5 and master get a different patch  
  

Reuse all-zero pages in GIN.

  
commit   : a471700e3cd3c38529ace909984ef10562888084    
  
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 up bad call to exit_nicely from commit af225551ef

  
commit   : 2e226763e3ad160b768b13793db645b31455edea    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 25 Jul 2015 18:44:37 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 25 Jul 2015 18:44:37 -0400    

Click here for diff

  
The signature for this changed in 9.2  
  

Restore use of zlib default compression in pg_dump directory mode.

  
commit   : af225551ef8435eb911e0b063358c42fcdecb853    
  
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.  
  

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

  
commit   : e54e17aca2f57b4f0ccad3af9d85c3ab12efe668    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 23 Jul 2015 01:30:17 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 23 Jul 2015 01:30:17 +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 (some of) pltcl memory usage

  
commit   : 14ade020ffa805b8335af10a11520b7b2249c99e    
  
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  
  

AIX: Test the -qlonglong option before use.

  
commit   : 76fa354c533c1955cc5fdcbff4a82edac274174c    
  
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   : faef3dc288d4b0d0c7cae4f5c0b0ea71e0f6b73c    
  
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.  
  

  
commit   : 1dd2b6b680e9575ddb2c1b31e48ebfb9f51d9779    
  
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).  
  

Fix assorted memory leaks.

  
commit   : e9a859b549d77dc8006670d012fecd94594c0a70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Jul 2015 16:25:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Jul 2015 16:25:52 -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  
  

Fix postmaster’s handling of a startup-process crash.

  
commit   : da1e7eb72ef6748f6c8b379e1ceacbecbcab9976    
  
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.  
  

  
commit   : f0357edeb32adf735ad22620d0b4bd4ba088457c    
  
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.  
  

Fix null pointer dereference in “\c” psql command.

  
commit   : 5f173a9f2a9726c3be9f47eb2081ec4b089bf046    
  
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).  
  

Oops, PQExpBufferDataBroken doesn’t exist before 9.2.

  
commit   : a788cbfdc406952ec41e34b1df64e65128021312    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2015 18:54:08 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 7 Jul 2015 18:54:08 +0300    

Click here for diff

  
My previous back-patching went wrong.  
  

Improve handling of out-of-memory in libpq.

  
commit   : dcbaf4b373b46f696ca58f39a99b07c0a6782d07    
  
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.  
  

Turn install.bat into a pure one line wrapper fort he perl script.

  
commit   : 3b7cf436784f568fa37d40c51134aaea127c10be    
  
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.  
  

Make numeric form of PG version number readily available in Makefiles.

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

PL/Perl: Add alternative expected file for Perl 5.22

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

  
  

  
commit   : 9da81d0f79594e2cd06fd63ac2d34a48f78269d8    
  
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   : a9f886f41d783795a0b35de4c9fc578c3ea41e75    
  
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  
  

Revoke incorrectly applied patch version

  
commit   : b340502b052e5bba4bbe736244cc9ea6156e2974    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 27 Jun 2015 02:22:26 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 27 Jun 2015 02:22:26 +0100    

Click here for diff

  
  

Avoid hot standby cancels from VAC FREEZE

  
commit   : 9e23d05b256adb0964f13464f9be5ae6e856cd19    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 27 Jun 2015 00:48:06 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 27 Jun 2015 00:48:06 +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 the logic for putting relations into the relcache init file.

  
commit   : a9b7bf82fab90cd7005d7f89fd374ce51319e971    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jun 2015 14:39:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jun 2015 14:39:06 -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   : f99158229046d92db270bb7963b59f0eb9fe460f    
  
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.  
  

Truncate strings in tarCreateHeader() with strlcpy(), not sprintf().

  
commit   : 3508ee9c3c2c4e8c0f0f3d20327051f47105da57    
  
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.  
  

Fix thinko in comment (launcher -> worker)

  
commit   : 4545222a6eb1173ae572aaa3f381356188bbc34c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 20 Jun 2015 11:45:58 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 20 Jun 2015 11:45:58 -0300    

Click here for diff

  
  

Clamp autovacuum launcher sleep time to 5 minutes

  
commit   : 2fed5731a39643ddbf9e9127a75664dfd4b21877    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 19 Jun 2015 12:44:33 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 19 Jun 2015 12:44:33 -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.  
  

Check for out of memory when allocating sqlca.

  
commit   : 6ab1a53dd595098390d2412e4f6d390f206b82dc    
  
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   : a38f08bb9de6064fe3f42d273bd60a96adceb4bd    
  
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  
  

Fixed some memory leaks in ECPG.

  
commit   : a5238ced6789191c24d4979fdd06dd8d4412f72c    
  
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  
  
Conflicts:  
	src/interfaces/ecpg/preproc/variable.c  
	src/interfaces/ecpg/preproc/pgc.l  
  

Fix intoasc() in Informix compat lib. This function used to be a noop.

  
commit   : 866e7f591550929991d1cc683c4a3faa74263036    
  
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