PostgreSQL 9.4.1 commit log

commit   : d0f83327d3739a45102fdd486947248c70e0249d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Feb 2015 15:42:55 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 Feb 2015 15:42:55 -0500    

commit   : 3face5a8d9ffbb5d37b5c29949d4363bd64f7446    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Feb 2015 11:24:02 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 Feb 2015 11:24:02 -0500    

Add entries for security issues.  
  
Security: CVE-2015-0241 through CVE-2015-0244  

commit   : 57ec87c6b8dcb5258aae414fbdbeaf6eaf09feb1    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 2 Feb 2015 17:08:56 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 2 Feb 2015 17:08:56 +0200    

If any error occurred while we were in the middle of reading a protocol  
message from the client, we could lose sync, and incorrectly try to  
interpret a part of another message as a new protocol message. That will  
usually lead to an "invalid frontend message" error that terminates the  
connection. However, this is a security issue because an attacker might  
be able to deliberately cause an error, inject a Query message in what's  
supposed to be just user data, and have the server execute it.  
  
We were quite careful to not have CHECK_FOR_INTERRUPTS() calls or other  
operations that could ereport(ERROR) in the middle of processing a message,  
but a query cancel interrupt or statement timeout could nevertheless cause  
it to happen. Also, the V2 fastpath and COPY handling were not so careful.  
It's very difficult to recover in the V2 COPY protocol, so we will just  
terminate the connection on error. In practice, that's what happened  
previously anyway, as we lost protocol sync.  
  
To fix, add a new variable in pqcomm.c, PqCommReadingMsg, that is set  
whenever we're in the middle of reading a message. When it's set, we cannot  
safely ERROR out and continue running, because we might've read only part  
of a message. PqCommReadingMsg acts somewhat similarly to critical sections  
in that if an error occurs while it's set, the error handler will force the  
connection to be terminated, as if the error was FATAL. It's not  
implemented by promoting ERROR to FATAL in elog.c, like ERROR is promoted  
to PANIC in critical sections, because we want to be able to use  
PG_TRY/CATCH to recover and regain protocol sync. pq_getmessage() takes  
advantage of that to prevent an OOM error from terminating the connection.  
  
To prevent unnecessary connection terminations, add a holdoff mechanism  
similar to HOLD/RESUME_INTERRUPTS() that can be used hold off query cancel  
interrupts, but still allow die interrupts. The rules on which interrupts  
are processed when are now a bit more complicated, so refactor  
ProcessInterrupts() and the calls to it in signal handlers so that the  
signal handlers always call it if ImmediateInterruptOK is set, and  
ProcessInterrupts() can decide to not do anything if the other conditions  
are not met.  
  
Reported by Emil Lenngren. Patch reviewed by Noah Misch and Andres Freund.  
Backpatch to all supported versions.  
  
Security: CVE-2015-0244  

commit   : ca84dfa90e9929737bda7393f88b488cb7161147    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 2 Feb 2015 10:00:45 -0500    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 2 Feb 2015 10:00:45 -0500    

This function uses uninitialized stack and heap buffers as supplementary  
entropy sources.  Mark them so Memcheck will not complain.  Back-patch  
to 9.4, where Valgrind Memcheck cooperation first appeared.  
  
Marko Tiikkaja  

commit   : 258e294dbbd8cb55b7825759adee3156f6aaa744    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 2 Feb 2015 10:00:45 -0500    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 2 Feb 2015 10:00:45 -0500    

This covers alterations to buffer sizing and zeroing made between imath  
1.3 and imath 1.20.  Valgrind Memcheck identified the buffer overruns  
and reliance on uninitialized data; their exploit potential is unknown.  
Builds specifying --with-openssl are unaffected, because they use the  
OpenSSL BIGNUM facility instead of imath.  Back-patch to 9.0 (all  
supported versions).  
  
Security: CVE-2015-0243  

commit   : 82806cf4e5442db51f1ca62631ea15b3343a9a76    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 2 Feb 2015 10:00:45 -0500    
  
committer: Noah Misch <[email protected]>    
date     : Mon, 2 Feb 2015 10:00:45 -0500    

Most callers pass a stack buffer.  The ensuing stack smash can crash the  
server, and we have not ruled out the viability of attacks that lead to  
privilege escalation.  Back-patch to 9.0 (all supported versions).  
  
Marko Tiikkaja  
  
Security: CVE-2015-0243  

commit   : 2ac95c83ce9321cb428bf3508a606df31c762ef1    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 2 Feb 2015 10:00:45 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 2 Feb 2015 10:00:45 -0500    

Prevent port/snprintf() from overflowing its local fixed-size  
buffer and pad to the desired number of digits with zeros, even  
if the precision is beyond the ability of the native sprintf().  
port/snprintf() is only used on systems that lack a native  
snprintf().  
  
Reported by Bruce Momjian. Patch by Tom Lane.	Backpatch to all  
supported versions.  
  
Security: CVE-2015-0242  

commit   : 56d2bee9db219b21592c6fef9d29ce1d5e3c6c59    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 2 Feb 2015 10:00:45 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 2 Feb 2015 10:00:45 -0500    

Previously very long localized month and weekday strings could  
overflow the allocated buffers, causing a server crash.  
  
Reported and patch reviewed by Noah Misch.  Backpatch to all  
supported versions.  
  
Security: CVE-2015-0241  

commit   : 1628a0bbfa2e30cd52daaa3ae78961d301adad2f    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 2 Feb 2015 10:00:44 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 2 Feb 2015 10:00:44 -0500    

Previously very long field masks for floats could access memory  
beyond the existing buffer allocated to hold the result.  
  
Reported by Andres Freund and Peter Geoghegan.	Backpatch to all  
supported versions.  
  
Security: CVE-2015-0241  

commit   : e87dedc0c492a4dcc45ec4e424027a1180d7ebb6    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Feb 2015 00:18:54 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 Feb 2015 00:18:54 -0500    

The variable name isn't optional --- looks like a copy-and-paste-o from  
the \set command, where it is.  
  
Dilip Kumar  

commit   : 1de0702d92ed4288ae69c2b3587dddc023eb966f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 1 Feb 2015 23:18:42 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 1 Feb 2015 23:18:42 -0500    

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

commit   : 0ca8cc581e1fd097005bb31bfde516ce38c83d6e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 1 Feb 2015 22:36:44 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 1 Feb 2015 22:36:44 -0500    

The previous wording claimed that the file was always in /etc, but of  
course this varies with the installation layout.  Write instead that it  
can be found via `pg_config --sysconfdir`.  Even though this is still  
somewhat incorrect because it doesn't account of moved installations, it  
at least conveys that the location depends on the installation.  

commit   : e29bbb9c6eb66e67597d70db747f33c7bc365ac8    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 1 Feb 2015 16:53:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 1 Feb 2015 16:53:17 -0500    

commit   : 02d0937f6467604e52833555fd35c5900936021d    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 31 Jan 2015 18:35:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 31 Jan 2015 18:35:17 -0500    

"ECHO all" is ignored for interactive input, and has been for a very long  
time, though possibly not for as long as the documentation has claimed the  
opposite.  Fix that, and also note that empty lines aren't echoed, which  
while dubious is another longstanding behavior (it's embedded in our  
regression test files for one thing).  Per bug #12721 from Hans Ginzel.  
  
In HEAD, also improve the code comments in this area, and suppress an  
unnecessary fflush(stdout) when we're not echoing.  That would likely  
be safe to back-patch, but I'll not risk it mere hours before a release  
wrap.  

commit   : c2b06ab177577d05655ec57239d9a7f2c6e7d9cf    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 30 Jan 2015 22:45:44 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 30 Jan 2015 22:45:44 -0500    

DST law changes in Chile and Mexico (state of Quintana Roo).  
Historical changes for Iceland.  

commit   : 4cbf390d5f0339f9846d4492b15f98b41bfffe12    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 30 Jan 2015 14:44:49 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 30 Jan 2015 14:44:49 -0500    

We've been trying to support \u0000 in JSON values since commit  
78ed8e03c67d7333, and have introduced increasingly worse hacks to try to  
make it work, such as commit 0ad1a816320a2b53.  However, it fundamentally  
can't work in the way envisioned, because the stored representation looks  
the same as for \\u0000 which is not the same thing at all.  It's also  
entirely bogus to output \u0000 when de-escaped output is called for.  
  
The right way to do this would be to store an actual 0x00 byte, and then  
throw error only if asked to produce de-escaped textual output.  However,  
getting to that point seems likely to take considerable work and may well  
never be practical in the 9.4.x series.  
  
To preserve our options for better behavior while getting rid of the nasty  
side-effects of 0ad1a816320a2b53, revert that commit in toto and instead  
throw error if \u0000 is used in a context where it needs to be de-escaped.  
(These are the same contexts where non-ASCII Unicode escapes throw error  
if the database encoding isn't UTF8, so this behavior is by no means  
without precedent.)  
  
In passing, make both the \u0000 case and the non-ASCII Unicode case report  
ERRCODE_UNTRANSLATABLE_CHARACTER / "unsupported Unicode escape sequence"  
rather than claiming there's something wrong with the input syntax.  
  
Back-patch to 9.4, where we have to do something because 0ad1a816320a2b53  
broke things for many cases having nothing to do with \u0000.  9.3 also has  
bogus behavior, but only for that specific escape value, so given the lack  
of field complaints it seems better to leave 9.3 alone.  

commit   : 70da7aeba1f845d2f0bb864031e0bea21b384ca7    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 30 Jan 2015 13:04:59 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 30 Jan 2015 13:04:59 -0500    

Coverity points out that mdc_finish returns a pointer to a local buffer  
(which of course is gone as soon as the function returns), leaving open  
a risk of misbehaviors possibly as bad as a stack overwrite.  
  
In reality, the only possible call site is in process_data_packets()  
which does not examine the returned pointer at all.  So there's no  
live bug, but nonetheless the code is confusing and risky.  Refactor  
to avoid the issue by letting process_data_packets() call mdc_finish()  
directly instead of going through the pullf_read() API.  
  
Although this is only cosmetic, it seems good to back-patch so that  
the logic in pgp-decrypt.c stays in sync across all branches.  
  
Marko Kreen  

commit   : b6a164e5cb389a52b2187bbacdcdaab46e236418    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 30 Jan 2015 12:30:41 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 30 Jan 2015 12:30:41 -0500    

calc_rangesel() failed outright when comparing range variables to empty  
constant ranges with < or >=, as a result of missing cases in a switch.  
It also produced a bogus estimate for > comparison to an empty range.  
  
On top of that, the >= and > cases were mislabeled throughout.  For  
nonempty constant ranges, they managed to produce the right answers  
anyway as a result of counterbalancing typos.  
  
Also, default_range_selectivity() omitted cases for elem <@ range,  
range &< range, and range &> range, so that rather dubious defaults  
were applied for these operators.  
  
In passing, rearrange the code in rangesel() so that the elem <@ range  
case is handled in a less opaque fashion.  
  
Report and patch by Emre Hasegeli, some additional work by me  

commit   : dc40ca696313ee8f7e75bb7628990e6e138b0e01    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 30 Jan 2015 17:58:23 +0100    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 30 Jan 2015 17:58:23 +0100    

The requiredEntries / additionalEntries arrays were not freed in  
freeScanKeys() like other per-key stuff.  
  
It's not obvious, but startScanKey() was only ever called after the keys  
have been initialized with ginNewScanKey(). That's why it doesn't need to  
worry about freeing existing arrays. The ginIsNewKey() test in gingetbitmap  
was never true, because ginrescan free's the existing keys, and it's not OK  
to call gingetbitmap twice in a row without calling ginrescan in between.  
To make that clear, remove the unnecessary ginIsNewKey(). And just to be  
extra sure that nothing funny happens if there is an existing key after all,  
call freeScanKeys() to free it if it exists. This makes the code more  
straightforward.  
  
(I'm seeing other similar leaks in testing a query that rescans an GIN index  
scan, but that's a different issue. This just fixes the obvious leak with  
those two arrays.)  
  
Backpatch to 9.4, where GIN fast scan was added.  

commit   : cb0168528280fcf5ad5fc6f745603080b979511a    
  
author   : Kevin Grittner <[email protected]>    
date     : Fri, 30 Jan 2015 08:57:53 -0600    
  
committer: Kevin Grittner <[email protected]>    
date     : Fri, 30 Jan 2015 08:57:53 -0600    

Since 9.3, when the --jobs option was introduced, using it together  
with the --serializable-deferrable option generated multiple  
errors.  We can get correct behavior by allowing the connection  
which acquires the snapshot to use SERIALIZABLE, READ ONLY,  
DEFERRABLE and pass that to the workers running the other  
connections using REPEATABLE READ, READ ONLY.  This is a bit of a  
kluge since the SERIALIZABLE behavior is achieved by running some  
of the participating connections at a different isolation level,  
but it is a simple and safe change, suitable for back-patching.  
  
This will be followed by a proposal for a more invasive fix with  
some slight behavioral changes on just the master branch, based on  
suggestions from Andres Freund, but the kluge will be applied to  
master until something is agreed along those lines.  
  
Back-patched to 9.3, where the --jobs option was added.  
  
Based on report from Alexander Korotkov  

commit   : b1700055c2fb60292067a9e39554dedce68569f7    
  
author   : Stephen Frost <[email protected]>    
date     : Thu, 29 Jan 2015 21:59:43 -0500    
  
committer: Stephen Frost <[email protected]>    
date     : Thu, 29 Jan 2015 21:59:43 -0500    

In 804b6b6db4dcfc590a468e7be390738f9f7755fb we modified  
BuildIndexValueDescription to pay attention to which columns are visible  
to the user, but unfortunatley that commit neglected to consider indexes  
which are built on expressions.  
  
Handle error-reporting of violations of constraint indexes based on  
expressions by not returning any detail when the user does not have  
table-level SELECT rights.  
  
Backpatch to 9.0, as the prior commit was.  
  
Pointed out by Tom.  

commit   : 202621d0471b56c3355af1f2134cf868a6f9b4bd    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 29 Jan 2015 20:18:37 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 29 Jan 2015 20:18:37 -0500    

connectby() didn't adequately check that the constructed SQL query returns  
what it's expected to; in fact, since commit 08c33c426bfebb32 it wasn't  
checking that at all.  This could result in a null-pointer-dereference  
crash if the constructed query returns only one column instead of the  
expected two.  Less excitingly, it could also result in surprising data  
conversion failures if the constructed query returned values that were  
not I/O-conversion-compatible with the types specified by the query  
calling connectby().  
  
In all branches, insist that the query return at least two columns;  
this seems like a minimal sanity check that can't break any reasonable  
use-cases.  
  
In HEAD, insist that the constructed query return the types specified by  
the outer query, including checking for typmod incompatibility, which the  
code never did even before it got broken.  This is to hide the fact that  
the implementation does a conversion to text and back; someday we might  
want to improve that.  
  
In back branches, leave that alone, since adding a type check in a minor  
release is more likely to break things than make people happy.  Type  
inconsistencies will continue to work so long as the actual type and  
declared type are I/O representation compatible, and otherwise will fail  
the same way they used to.  
  
Also, in all branches, be on guard for NULL results from the constructed  
query, which formerly would cause null-pointer dereference crashes.  
We now print the row with the NULL but don't recurse down from it.  
  
In passing, get rid of the rather pointless idea that  
build_tuplestore_recursively() should return the same tuplestore that's  
passed to it.  
  
Michael Paquier, adjusted somewhat by me  

commit   : 76e962750f0b2557e6a356c35d7c66fe8fb263b0    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 29 Jan 2015 17:49:03 +0100    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 29 Jan 2015 17:49:03 +0100    

GetLockConflicts() has for a long time not properly terminated the  
returned array. During normal processing the returned array is zero  
initialized which, while not pretty, is sufficient to be recognized as  
a invalid virtual transaction id. But the HotStandby case is more than  
aesthetically broken: The allocated (and reused) array is neither  
zeroed upon allocation, nor reinitialized, nor terminated.  
  
Not having a terminating element means that the end of the array will  
not be recognized and that recovery conflict handling will thus read  
ahead into adjacent memory. Only terminating when hitting memory  
content that looks like a invalid virtual transaction id.  Luckily  
this seems so far not have caused significant problems, besides making  
recovery conflict more expensive.  
  
Discussion: [email protected]  
  
Backpatch into all supported branches.  

commit   : 28a37deab30b6946558de3cafe78daa4823e23c3    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 29 Jan 2015 19:35:55 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 29 Jan 2015 19:35:55 +0200    

When gin_fuzzy_search_limit was used, we could jump out of startScan()  
without calling startScanKey(). That was harmless in 9.3 and below, because  
startScanKey()() didn't do anything interesting, but in 9.4 it initializes  
information needed for skipping entries (aka GIN fast scans), and you  
readily get a segfault if it's not done. Nevertheless, it was clearly wrong  
all along, so backpatch all the way to 9.1 where the early return was  
introduced.  
  
(AFAICS startScanKey() did nothing useful in 9.3 and below, because the  
fields it initialized were already initialized in ginFillScanKey(), but I  
don't dare to change that in a minor release. ginFillScanKey() is always  
called in gingetbitmap() even though there's a check there to see if the  
scan keys have already been initialized, because they never are; ginrescan()  
free's them.)  
  
In the passing, remove unnecessary if-check from the second inner loop in  
startScan(). We already check in the first loop that the condition is true  
for all entries.  
  
Reported by Olaf Gawenda, bug #12694, Backpatch to 9.1 and above, although  
AFAICS it causes a live bug only in 9.4.  

commit   : b40fe42781f524c37073275e089edf795fbc3d66    
  
author   : Stephen Frost <[email protected]>    
date     : Wed, 28 Jan 2015 17:42:51 -0500    
  
committer: Stephen Frost <[email protected]>    
date     : Wed, 28 Jan 2015 17:42:51 -0500    

Commit 804b6b6db4dcfc590a468e7be390738f9f7755fb added the build of a  
range table in copy.c to initialize the EState es_range_table since it  
can be needed in error paths.  Unfortunately, that commit didn't  
appreciate that some code paths might end up not initializing the rte  
which is used to build the range table.  
  
Fix that and clean up a couple others things along the way- build it  
only once and don't explicitly set it on the !is_from path as it  
doesn't make any sense there (cstate is palloc0'd, so this isn't an  
issue from an initializing standpoint either).  
  
The prior commit went back to 9.0, but this only goes back to 9.1 as  
prior to that the range table build happens immediately after building  
the RTE and therefore doesn't suffer from this issue.  
  
Pointed out by Robert.  

commit   : 3cc74a3d61f26e6558ee662b6700f74962bd1d8b    
  
author   : Stephen Frost <[email protected]>    
date     : Mon, 12 Jan 2015 17:04:11 -0500    
  
committer: Stephen Frost <[email protected]>    
date     : Mon, 12 Jan 2015 17:04:11 -0500    

While building error messages to return to the user,  
BuildIndexValueDescription, ExecBuildSlotValueDescription and  
ri_ReportViolation would happily include the entire key or entire row in  
the result returned to the user, even if the user didn't have access to  
view all of the columns being included.  
  
Instead, include only those columns which the user is providing or which  
the user has select rights on.  If the user does not have any rights  
to view the table or any of the columns involved then no detail is  
provided and a NULL value is returned from BuildIndexValueDescription  
and ExecBuildSlotValueDescription.  Note that, for key cases, the user  
must have access to all of the columns for the key to be shown; a  
partial key will not be returned.  
  
Back-patch all the way, as column-level privileges are now in all  
supported versions.  
  
This has been assigned CVE-2014-8161, but since the issue and the patch  
have already been publicized on pgsql-hackers, there's no point in trying  
to hide this commit.  

commit   : 3d5e857ab1ed7dbac28e6c0aea580d1dfb9dc9ed    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 27 Jan 2015 12:06:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 27 Jan 2015 12:06:36 -0500    

Commit 145343534c153d1e6c3cff1fa1855787684d9a38 arranged to store numeric  
NaN values as short-header numerics, but the field access macros did not  
get the memo: they thought only "SHORT" numerics have short headers.  
  
Most of the time this makes no difference because we don't access the  
weight or dscale of a NaN; but numeric_send does that.  As pointed out  
by Andrew Gierth, this led to fetching uninitialized bytes.  
  
AFAICS this could not have any worse consequences than that; in particular,  
an unaligned stored numeric would have been detoasted by PG_GETARG_NUMERIC,  
so that there's no risk of a fetch off the end of memory.  Still, the code  
is wrong on its own terms, and it's not hard to foresee future changes that  
might expose us to real risks.  So back-patch to all affected branches.  

commit   : e4021a2ba647e61340b096d49b1a657eeafdc617    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 26 Jan 2015 15:17:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 26 Jan 2015 15:17:36 -0500    

Some fields of the sinfo struct are modified within PG_TRY and then  
referenced within PG_CATCH, so as with recent patch to async.c, "volatile"  
is necessary for strict POSIX compliance; and that propagates to a couple  
of subroutines as well as materializeQueryResult() itself.  I think the  
risk of actual issues here is probably higher than in async.c, because  
storeQueryResult() is likely to get inlined into materializeQueryResult(),  
leaving the compiler free to conclude that its stores into sinfo fields are  
dead code.  

commit   : dd9d78f595a124591eadb97d71813fc71fd767a5    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 26 Jan 2015 12:18:25 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 26 Jan 2015 12:18:25 -0500    

The "callargs" variable is modified within PG_TRY and then referenced  
within PG_CATCH, which is exactly the coding pattern we've now found  
to be unsafe.  Marking "callargs" volatile would be problematic because  
it is passed by reference to some Tcl functions, so fix the problem  
by not modifying it within PG_TRY.  We can just postpone the free()  
till we exit the PG_TRY construct, as is already done elsewhere in this  
same file.  
  
Also, fix failure to free(callargs) when exiting on too-many-arguments  
error.  This is only a minor memory leak, but a leak nonetheless.  
  
In passing, remove some unnecessary "volatile" markings in the same  
function.  Those doubtless are there because gcc 2.95.3 whinged about  
them, but we now know that its algorithm for complaining is many bricks  
shy of a load.  
  
This is certainly a live bug with compilers that optimize similarly  
to current gcc, so back-patch to all active branches.  

commit   : df923be03d1123bfbc701dd9cf85cd44e1e84335    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 26 Jan 2015 11:57:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 26 Jan 2015 11:57:36 -0500    

The "pos" variable is modified within PG_TRY and then referenced  
within PG_CATCH, so for strict POSIX conformance it must be marked  
volatile.  Superficially the code looked safe because pos's address  
was taken, which was sufficient to force it into memory ... but it's  
not sufficient to ensure that the compiler applies updates exactly  
where the program text says to.  The volatility marking has to extend  
into a couple of subroutines too, but I think that's probably a good  
thing because the risk of out-of-order updates is mostly in those  
subroutines not asyncQueueReadAllNotifications() itself.  In principle  
the compiler could have re-ordered operations such that an error could  
be thrown while "pos" had an incorrect value.  
  
It's unclear how real the risk is here, but for safety back-patch  
to all active branches.  

commit   : f86a8955e8aae4da854e65b87b588e37ecb45918    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 25 Jan 2015 22:49:59 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 25 Jan 2015 22:49:59 -0500    

On closer inspection, we can remove the "volatile" qualifier on  
"using_subtxn" so long as we initialize that before the PG_TRY block,  
which there's no particularly good reason not to do.  
Also, push the "change" variable inside the PG_TRY so as to remove  
all question of whether it needs "volatile", and remove useless  
early initializations of "snapshow_now" and "using_subtxn".  

commit   : 138a5c4a909dc96c0f3a95123639ee7e014c7f38    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 25 Jan 2015 20:19:07 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 25 Jan 2015 20:19:07 -0500    

Fix unsafe use of a non-volatile variable in PG_TRY/PG_CATCH in  
AlterSystemSetConfigFile().  While at it, clean up a bundle of other  
infelicities and outright bugs, including corner-case-incorrect linked list  
manipulation, a poorly designed and worse documented parse-and-validate  
function (which even included some randomly chosen hard-wired substitutes  
for the specified elevel in one code path ... wtf?), direct use of open()  
instead of fd.c's facilities, inadequate checking of write()'s return  
value, and generally poorly written commentary.  

commit   : 91964c3ed1c49d9a8670d3f85a660181cc541c7c    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 24 Jan 2015 13:25:22 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 24 Jan 2015 13:25:22 -0500    

"iterstate" must be marked volatile since it's changed inside the PG_TRY  
block and then used in the PG_CATCH stanza.  Noted by Mark Wilding of  
Salesforce.  (We really need to see if we can't get the C compiler to warn  
about this.)  
  
Also, reset iterstate to NULL after the mainline ReorderBufferIterTXNFinish  
call, to ensure the PG_CATCH block doesn't try to do that a second time.  

commit   : d51d4ff311d01de8521acedb0a6f7c242648a231    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 24 Jan 2015 13:05:45 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 24 Jan 2015 13:05:45 -0500    

strncpy() has a well-deserved reputation for being unsafe, so make an  
effort to get rid of nearly all occurrences in HEAD.  
  
A large fraction of the remaining uses were passing length less than or  
equal to the known strlen() of the source, in which case no null-padding  
can occur and the behavior is equivalent to memcpy(), though doubtless  
slower and certainly harder to reason about.  So just use memcpy() in  
these cases.  
  
In other cases, use either StrNCpy() or strlcpy() as appropriate (depending  
on whether padding to the full length of the destination buffer seems  
useful).  
  
I left a few strncpy() calls alone in the src/timezone/ code, to keep it  
in sync with upstream (the IANA tzcode distribution).  There are also a  
few such calls in ecpg that could possibly do with more analysis.  
  
AFAICT, none of these changes are more than cosmetic, except for the four  
occurrences in fe-secure-openssl.c, which are in fact buggy: an overlength  
source leads to a non-null-terminated destination buffer and ensuing  
misbehavior.  These don't seem like security issues, first because no stack  
clobber is possible and second because if your values of sslcert etc are  
coming from untrusted sources then you've got problems way worse than this.  
Still, it's undesirable to have unpredictable behavior for overlength  
inputs, so back-patch those four changes to all active branches.  

commit   : 3de9f22ace195e9fc1b7208a64290ab5e3404358    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 19 Jan 2015 23:44:22 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 19 Jan 2015 23:44:22 -0500    

This results in a very substantial reduction in disk space usage during  
"make check-world", since that sequence involves creation of numerous  
temporary installations.  It should also help a bit in the buildfarm, even  
though the buildfarm script doesn't create as many temp installations,  
because the current script misses deleting some of them; and anyway it  
seems better to do this once in one place rather than expecting that  
script to get it right every time.  
  
In 9.4 and HEAD, also undo the unwise choice in commit b1aebbb6a86e96d7  
to report strerror(errno) after a rmtree() failure.  rmtree has already  
reported that, possibly for multiple failures with distinct errnos; and  
what's more, by the time it returns there is no good reason to assume  
that errno still reflects the last reportable error.  So reporting errno  
here is at best redundant and at worst badly misleading.  
  
Back-patch to all supported branches, so that future revisions of the  
buildfarm script can rely on this behavior.  

commit   : 3387cbbcb2d1a63ed6e1b1dd778b11dac64be32d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 19 Jan 2015 23:01:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 19 Jan 2015 23:01:36 -0500    

Per discussion, change the log level of this message to be LOG not WARNING.  
The main point of this change is to avoid causing buildfarm run failures  
when the stats collector is exceptionally slow to respond, which it not  
infrequently is on some of the smaller/slower buildfarm members.  
  
This change does lose notice to an interactive user when his stats query  
is looking at out-of-date stats, but the majority opinion (not necessarily  
that of yours truly) is that WARNING messages would probably not get  
noticed anyway on heavily loaded production systems.  A LOG message at  
least ensures that the problem is recorded somewhere where bulk auditing  
for the issue is possible.  
  
Also, instead of an untranslated "pgstat wait timeout" message, provide  
a translatable and hopefully more understandable message "using stale  
statistics instead of current ones because stats collector is not  
responding".  The original text was written hastily under the assumption  
that it would never really happen in practice, which we now know to be  
unduly optimistic.  
  
Back-patch to all active branches, since we've seen the buildfarm issue  
in all branches.  

commit   : a2ac3b890dfcafcce78625c721bcda2a3ecef514    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 19 Jan 2015 12:43:58 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 19 Jan 2015 12:43:58 -0300    

Pointed out by Alan Mogi (bug #12571)  

commit   : 94bc1c58789440f248e65650c811abd4fd9a2886    
  
author   : Andres Freund <[email protected]>    
date     : Sun, 18 Jan 2015 15:57:55 +0100    
  
committer: Andres Freund <[email protected]>    
date     : Sun, 18 Jan 2015 15:57:55 +0100    

pg_dump.c:dumDatabase() called ArchiveEntry() with the results of a a  
query that was PQclear()ed a couple lines earlier.  
  
Backpatch to 9.2 where security labels for shared objects where  
introduced.  

commit   : 6bbf75192801c0965cec28c8d93c4ed5f2e68b20    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 6 Jan 2015 23:06:13 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 6 Jan 2015 23:06:13 -0500    

Previously, the xml value resulting from an xpath query would not have  
namespace declarations if the namespace declarations were attached to  
an ancestor element in the input xml value.  That means the output value  
was not correct XML.  Fix that by running the result value through  
xmlCopyNode(), which produces the correct namespace declarations.  
  
Author: Ali Akbar <[email protected]>  

commit   : 2049a7d82920e23c37f92ece0051835a5ba39eeb    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 16 Jan 2015 12:12:49 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 16 Jan 2015 12:12:49 +0200    

Previous fix mapped "Norwegian (Bokmål)" locale, which contains a non-ASCII  
character, to the pure ASCII alias "norwegian-bokmal". However, it turns  
out that more recent versions of the CRT library, in particular MSVCR110  
(Visual Studio 2012), changed the behaviour of setlocale() so that if  
you pass "norwegian-bokmal" to setlocale, it returns "Norwegian_Norway".  
  
That meant trouble, when setlocale(..., NULL) first returned  
"Norwegian (Bokmål)_Norway", which we mapped to "norwegian-bokmal_Norway",  
but another call to setlocale(..., "norwegian-bokmal_Norway") returned  
"Norwegian_Norway". That caused PostgreSQL to think that they are different  
locales, and therefore not compatible. That caused initdb to fail at  
CREATE DATABASE.  
  
Older CRT versions seem to accept "Norwegian_Norway" too, so change the  
mapping to return "Norwegian_Norway" instead of "norwegian-bokmal".  
  
Backpatch to 9.2 like the previous attempt. We haven't made a release that  
includes the previous fix yet, so we don't need to worry about changing the  
locale of existing clusters from "norwegian-bokmal" to "Norwegian_Norway".  
(Doing any mapping like this at all requires changing the locale of  
existing databases; the release notes need to include instructions for  
that).  

commit   : a10de352be874ae28ea87aca79be4a5a2f229bb6    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 16 Jan 2015 01:27:31 -0500    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 16 Jan 2015 01:27:31 -0500    

Commit 894459e59ffa5c7fee297b246c17e1f72564db1d revealed this option to  
be broken for NLS builds on Darwin, but "make -C contrib/unaccent check"  
and the buildfarm client rely on it.  Fix that configuration by  
redefining the option to imply LANG=C on Darwin.  In passing, use LANG=C  
instead of LANG=en on Windows; since only postmaster startup uses that  
value, testers are unlikely to notice the change.  Back-patch to 9.0,  
like the predecessor commit.  

commit   : b75d18bd4f7906e1a89174d6ec4aca8548fffd8d    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 15 Jan 2015 18:52:25 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 15 Jan 2015 18:52:25 -0500    

Up to now, the "child" executor state trees generated for EvalPlanQual  
rechecks have simply shared the ResultRelInfo arrays used for the original  
execution tree.  However, this leads to dangling-pointer problems, because  
ExecInitModifyTable() is all too willing to scribble on some fields of the  
ResultRelInfo(s) even when it's being run in one of those child trees.  
This trashes those fields from the perspective of the parent tree, because  
even if the generated subtree is logically identical to what was in use in  
the parent, it's in a memory context that will go away when we're done  
with the child state tree.  
  
We do however want to share information in the direction from the parent  
down to the children; in particular, fields such as es_instrument *must*  
be shared or we'll lose the stats arising from execution of the children.  
So the simplest fix is to make a copy of the parent's ResultRelInfo array,  
but not copy any fields back at end of child execution.  
  
Per report from Manuel Kniep.  The added isolation test is based on his  
example.  In an unpatched memory-clobber-enabled build it will reliably  
fail with "ctid is NULL" errors in all branches back to 9.1, as a  
consequence of junkfilter->jf_junkAttNo being overwritten with $7f7f.  
This test cannot be run as-is before that for lack of WITH syntax; but  
I have no doubt that some variant of this problem can arise in older  
branches, so apply the code change all the way back.  

commit   : b337d9657b4dbb72cfbb1012c15a01c5c74ff533    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 15 Jan 2015 20:48:48 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 15 Jan 2015 20:48:48 +0200    

The flag is supposed to be copied from the record. Same issue with  
track_commit_timestamps, but that's master-only.  
  
Report and fix by Petr Jalinek. Backpatch to 9.4, where wal_log_hints was  
added.  

commit   : d25192892d61419278fbb216e695cb070c332092    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 15 Jan 2015 13:18:16 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 15 Jan 2015 13:18:16 -0500    

As of 9.3, ruleutils.c goes to some lengths to ensure that table and column  
aliases used in its output are unique.  Of course this takes more time than  
was required before, which in itself isn't fatal.  However, EXPLAIN was set  
up so that recalculation of the unique aliases was repeated for each  
subexpression printed in a plan.  That results in O(N^2) time and memory  
consumption for large plan trees, which did not happen in older branches.  
  
Fortunately, the expensive work is the same across a whole plan tree,  
so there is no need to repeat it; we can do most of the initialization  
just once per query and re-use it for each subexpression.  This buys  
back most (not all) of the performance loss since 9.2.  
  
We need an extra ExplainState field to hold the precalculated deparse  
context.  That's no problem in HEAD, but in the back branches, expanding  
sizeof(ExplainState) seems risky because third-party extensions might  
have local variables of that struct type.  So, in 9.4 and 9.3, introduce  
an auxiliary struct to keep sizeof(ExplainState) the same.  We should  
refactor the APIs to avoid such local variables in future, but that's  
material for a separate HEAD-only commit.  
  
Per gripe from Alexey Bashtanov.  Back-patch to 9.3 where the issue  
was introduced.  

commit   : 7b65f194e9ef098e519bb6d4f792af71a4ab5778    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 15 Jan 2015 09:26:03 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 15 Jan 2015 09:26:03 -0500    

Previously, read() might have returned a length equal to the buffer  
length, and then the subsequent store to buf[len] would write a  
zero-byte one byte past the end.  This doesn't seem likely to be  
a security issue, but there's some chance it could result in  
pg_standby misbehaving.  
  
Spotted by Coverity; patch by Michael Paquier, reviewed by me.  

commit   : adb355106891ff318ca284f0cae3a993eef96185    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 14 Jan 2015 11:08:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 14 Jan 2015 11:08:17 -0500    

Previously, configure would add any switches that it chose of its own  
accord to the end of the user-specified CFLAGS string.  Since most  
compilers process these left-to-right, this meant that configure's choices  
would override the user-specified flags in case of conflicts.  We'd rather  
that worked the other way around, so adjust the logic to put the user's  
string at the end not the beginning.  
  
There does not seem to be a need for a similar behavior change for CPPFLAGS  
or LDFLAGS: in those, the earlier switches tend to win (think -I or -L  
behavior) so putting the user's string at the front is fine.  
  
Backpatch to 9.4 but not earlier.  I'm not planning to run buildfarm member  
guar on older branches, and it seems a bit risky to change this behavior  
in long-stable branches.  

commit   : 045c7d3ebd413c501904233664825df5c1d955d7    
  
author   : Andres Freund <[email protected]>    
date     : Tue, 13 Jan 2015 21:02:47 +0100    
  
committer: Andres Freund <[email protected]>    
date     : Tue, 13 Jan 2015 21:02:47 +0100    

Commit b94ce6e80 reordered postmaster's startup sequence so that the  
tempfile directory is only cleaned up after all the necessary state  
for pg_ctl is collected.  Unfortunately the chosen location is after  
the syslogger has been started; which normally is fine, except for  
!WIN32 EXEC_BACKEND builds, which pass information to children via  
files in the temp directory.  
  
Move the call to RemovePgTempFiles() to just before the syslogger has  
started. That's the first child we fork.  
  
Luckily EXEC_BACKEND is pretty much only used by endusers on windows,  
which has a separate method to pass information to children. That  
means the real world impact of this bug is very small.  
  
Discussion: [email protected]  
  
Backpatch to 9.1, just as the previous commit was.  

commit   : 4ebb3494e9e05308737d27ee422b2283631f43a2    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 13 Jan 2015 14:29:36 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 13 Jan 2015 14:29:36 +0200    

Similar warnings from backend were silenced earlier by commit c8315930,  
but there were a few more contrib/hstore.  
  
Michael Paquier  

commit   : 450d9f2d6669e3c97544de9878611ee2964db29d    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 12 Jan 2015 16:08:46 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 12 Jan 2015 16:08:46 -0500    

Per testing with a compiler that whines about this.  

commit   : 4072d91f24681d8d9f0cbdfd58c50ce30f4f1331    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 12 Jan 2015 15:13:31 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 12 Jan 2015 15:13:31 -0500    

I noticed the "vacuum" regression test taking really significantly longer  
than it used to on a slow machine.  Investigation pointed the finger at  
commit e415b469b33ba328765e39fd62edcd28f30d9c3c, which added creation of  
an index using an extremely expensive index function.  That function was  
evidently meant to be applied only twice ... but the test re-used an  
existing test table, which up till a couple lines before that had had over  
two thousand rows.  Depending on timing of the concurrent regression tests,  
the intervening VACUUMs might have been unable to remove those  
recently-dead rows, and then the index build would need to create index  
entries for them too, leading to the wrap_do_analyze() function being  
executed 2000+ times not twice.  Avoid this by using a different table  
that is guaranteed to have only the intended two rows in it.  
  
Back-patch to 9.0, like the commit that created the problem.  

commit   : 8f2d99be8f273bfdb69d1b87a38e9c6a734850e0    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 12 Jan 2015 12:40:12 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 12 Jan 2015 12:40:12 -0500    

The mechanism added in commit dbdf9679d7d61b03a3bf73af9b095831b7010eb5  
for associating the correct translation domain with errcontext strings  
potentially fails in cases where errcontext() is used within an ereport()  
macro.  Such usage was not originally envisioned for errcontext(), but we  
do have a few places that do it.  In this situation, the intended comma  
expression becomes just a couple of arguments to errfinish(), which the  
compiler might choose to evaluate right-to-left.  
  
Fortunately, in such cases the textdomain for the errcontext string must  
be the same as for the surrounding ereport.  So we can fix this by letting  
errstart initialize context_domain along with domain; then it will have  
the correct value no matter which order the calls occur in.  (Note that  
error stack callback functions are not invoked until errfinish, so normal  
usage of errcontext won't affect what happens for errcontext calls within  
the ereport macro.)  
  
In passing, make sure that errcontext calls within the main backend set  
context_domain to something non-NULL.  This isn't a live bug because  
NULL would select the current textdomain() setting which should be the  
right thing anyway --- but it seems better to handle this completely  
consistently with the regular domain field.  
  
Per report from Dmitry Voronin.  Backpatch to 9.3; before that, there  
wasn't any attempt to ensure that errcontext strings were translated  
in an appropriate domain.  

commit   : ff58dcb51f26e10d847637c3a95afc63e1deefab    
  
author   : Stephen Frost <[email protected]>    
date     : Mon, 12 Jan 2015 10:13:18 -0500    
  
committer: Stephen Frost <[email protected]>    
date     : Mon, 12 Jan 2015 10:13:18 -0500    

Back in ed0b409, PGPROC was split and moved to static variables in  
procarray.c, with procs in ProcArrayStruct replaced by an array of  
integers representing process numbers (pgprocnos), with -1 indicating a  
dead process which has yet to be removed.  Access to procArray is  
generally done under ProcArrayLock and therefore most code does not have  
to concern itself with -1 entries.  
  
However, MinimumActiveBackends intentionally does not take  
ProcArrayLock, which means it has to be extra careful when accessing  
procArray.  Prior to ed0b409, this was handled by checking for a NULL  
in the pointer array, but that check was no longer valid after the  
split.  Coverity pointed out that the check could never happen and so  
it was removed in 5592eba.  That didn't make anything worse, but it  
didn't fix the issue either.  
  
The correct fix is to check for pgprocno == -1 and skip over that entry  
if it is encountered.  
  
Back-patch to 9.2, since there can be attempts to access the arrays  
prior to their start otherwise.  Note that the changes prior to 9.4 will  
look a bit different due to the change in 5592eba.  
  
Note that MinimumActiveBackends only returns a bool for heuristic  
purposes and any pre-array accesses are strictly read-only and so there  
is no security implication and the lack of fields complaints indicates  
it's very unlikely to run into issues due to this.  
  
Pointed out by Noah.  

commit   : 733728ff372059556caadb37ff1cc5a8c6975eec    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 11 Jan 2015 12:35:47 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 11 Jan 2015 12:35:47 -0500    

Some users run their applications in chroot environments that lack an  
/etc/passwd file.  This means that the current UID's user name and home  
directory are not obtainable.  libpq used to be all right with that,  
so long as the database role name to use was specified explicitly.  
But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by  
causing any failure of pg_fe_getauthname() to be treated as a hard error.  
In any case it did little to advance its nominal goal of causing errors  
in pg_fe_getauthname() to be reported better.  So revert that and instead  
put some real error-reporting code in place.  This requires changes to the  
APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had  
departed from the POSIX-specified API of getpwuid_r() in a way that made  
it impossible to distinguish actual lookup errors from "no such user".  
  
To allow such failures to be reported, while not failing if the caller  
supplies a role name, add a second call of pg_fe_getauthname() in  
connectOptions2().  This is a tad ugly, and could perhaps be avoided with  
some refactoring of PQsetdbLogin(), but I'll leave that idea for later.  
(Note that the complained-of misbehavior only occurs in PQsetdbLogin,  
not when using the PQconnect functions, because in the latter we will  
never bother to call pg_fe_getauthname() if the user gives a role name.)  
  
In passing also clean up the Windows-side usage of GetUserName(): the  
recommended buffer size is 257 bytes, the passed buffer length should  
be the buffer size not buffer size less 1, and any error is reported  
by GetLastError() not errno.  
  
Per report from Christoph Berg.  Back-patch to 9.4 where the chroot  
failure case was introduced.  The generally poor reporting of errors  
here is of very long standing, of course, but given the lack of field  
complaints about it we won't risk changing these APIs further back  
(even though they're theoretically internal to libpq).  

commit   : 3819d4e77b2d7c8933a8610ae10dc6c01e8190f1    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 9 Jan 2015 12:34:25 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 9 Jan 2015 12:34:25 -0300    

For some reason I overlooked in GETTEXT_TRIGGERS that the right argument  
be read by gettext in 7fcbf6a405ffc12a4546a25b98592ee6733783fc.  This  
will drop the translation percentages for the backend all the way back  
to 9.3 ...  
  
Problem reported by Heikki.  

commit   : ed5b0f79512aa37fc92d2097bc9a0b93a27eaee2    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 8 Jan 2015 13:35:04 +0100    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 8 Jan 2015 13:35:04 +0100    

logical.c's StartupDecodingContext() forgot to check whether  
XLogReaderAllocate() returns NULL indicating a memory allocation  
failure.  This could lead, although quite unlikely, lead to a NULL  
pointer dereference.  
  
This only applies to 9.4 as earlier versions don't do logical  
decoding, and later versions don't return NULL after allocation  
failures in XLogReaderAllocate().  
  
Michael Paquier, with minor changes by me.  

commit   : 83fb1ca5cf393f3a12930bd9275a711cd858c823    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 7 Jan 2015 22:35:44 -0500    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 7 Jan 2015 22:35:44 -0500    

Darwin --enable-nls builds use a substitute setlocale() that may start a  
thread.  Buildfarm member orangutan experienced BackendList corruption  
on account of different postmaster threads executing signal handlers  
simultaneously.  Furthermore, a multithreaded postmaster risks undefined  
behavior from sigprocmask() and fork().  Emit LOG messages about the  
problem and its workaround.  Back-patch to 9.0 (all supported versions).  

commit   : e8f82b4163edc806ecefdcfa6dfed092678218c9    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 7 Jan 2015 22:34:57 -0500    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 7 Jan 2015 22:34:57 -0500    

Typical server invocations already achieved that.  Invalid locale  
settings in the initial postmaster environment interfered, as could  
malloc() failure.  Setting "LC_MESSAGES=pt_BR.utf8 LC_ALL=invalid" in  
the postmaster environment will now choose C-locale messages, not  
Brazilian Portuguese messages.  Most localized programs, including all  
PostgreSQL frontend executables, do likewise.  Users are unlikely to  
observe changes involving locale categories other than LC_MESSAGES.  
CheckMyDatabase() ensures that we successfully set LC_COLLATE and  
LC_CTYPE; main() sets the remaining three categories to locale "C",  
which almost cannot fail.  Back-patch to 9.0 (all supported versions).  

commit   : fa042abddfad054b6872a2e2451868b08a230a2a    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 7 Jan 2015 22:33:58 -0500    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 7 Jan 2015 22:33:58 -0500    

vacuum()'s static variable handling makes it non-reentrant; an ensuing  
null pointer deference crashed the backend.  Back-patch to 9.0 (all  
supported versions).  

commit   : 7da1021542411130b66812e875c944c5aebf91d0    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 7 Jan 2015 00:10:19 +0100    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 7 Jan 2015 00:10:19 +0100    

When using a historic snapshot for logical decoding it can validly  
happen that a relation that's in the relcache isn't visible to that  
historic snapshot.  E.g. if a newly created relation is referenced in  
the query that uses the SQL interface for logical decoding and a  
sinval reset occurs.  
  
The earlier commit that fixed the error handling for that corner case  
already improves the situation as a ERROR is better than hitting an  
assertion... But it's obviously not good enough.  So additionally  
allow that case without an error if a historic snapshot is set up -  
that won't allow an invalid entry to stay in the cache because it's a)  
already marked invalid and will thus be rebuilt during the next access  
b) the syscaches will be reset at the end of decoding.  
  
There might be prettier solutions to handle this case, but all that we  
could think of so far end up being much more complex than this quite  
simple fix.  
  
This fixes the assertion failures reported by the buildfarm (markhor,  
tick, leech) after the introduction of new regression tests in  
89fd41b390a4. The failure there weren't actually directly caused by  
CLOBBER_CACHE_ALWAYS but the extraordinary long runtimes due to it  
lead to sinval resets triggering the behaviour.  
  
Discussion: [email protected]  
  
Backpatch to 9.4 where logical decoding was introduced.  

commit   : 84911ff51dec1b66f712ee966a84c1c434e8f875    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 7 Jan 2015 00:10:18 +0100    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 7 Jan 2015 00:10:18 +0100    

The corner case where a relcache invalidation tried to rebuild the  
entry for a referenced relation but couldn't find it in the catalog  
wasn't correct.  
  
The code tried to RelationCacheDelete/RelationDestroyRelation the  
entry. That didn't work when assertions are enabled because the latter  
contains an assertion ensuring the refcount is zero. It's also more  
generally a bad idea, because by virtue of being referenced somebody  
might actually look at the entry, which is possible if the error is  
trapped and handled via a subtransaction abort.  
  
Instead just error out, without deleting the entry. As the entry is  
marked invalid, the worst that can happen is that the invalid (and at  
some point unused) entry lingers in the relcache.  
  
Discussion: [email protected]  
  
There should be no way to hit this case < 9.4 where logical decoding  
introduced a bug that can hit this. But since the code for handling  
the corner case is there it should do something halfway sane, so  
backpatch all the the way back.  The logical decoding bug will be  
handled in a separate commit.  

commit   : 0cc6cef5a6e9f3af98c793d70173ac9e048009be    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 6 Jan 2015 15:16:29 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 6 Jan 2015 15:16:29 -0300    

commit   : 0e52f5b507f4e27540291efa8dc25476fec42bed    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 6 Jan 2015 11:43:46 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 6 Jan 2015 11:43:46 -0500    

Backpatch certain files through 9.0  

commit   : c99e41f686bae0e35eafe92a970e77cbdb1db17c    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Jan 2015 19:27:06 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Jan 2015 19:27:06 -0500    

This never worked, I think.  Per report from Marc Munro.  
  
In passing, fix funny spacing in the COMMENT ON command as a result of  
excess space in the "label" string.  

commit   : 51742063be4fd8d58fb8571e559fe8ca0abbbb57    
  
author   : Alvaro Herrera <[email protected]>    
date     : Sun, 4 Jan 2015 15:48:29 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Sun, 4 Jan 2015 15:48:29 -0300    

Commit 0e5680f4737a9c6aa94aa9e77543e5de60411322 contained a thinko  
mixing LOCKMODE with LockTupleMode.  This caused misbehavior in the case  
where a tuple is marked with a multixact with at most a FOR SHARE lock,  
and another transaction tries to acquire a FOR NO KEY EXCLUSIVE lock;  
this case should block but doesn't.  
  
Include a new isolation tester spec file to explicitely try all the  
tuple lock combinations; without the fix it shows the problem:  
  
    starting permutation: s1_begin s1_lcksvpt s1_tuplock2 s2_tuplock3 s1_commit  
    step s1_begin: BEGIN;  
    step s1_lcksvpt: SELECT * FROM multixact_conflict FOR KEY SHARE; SAVEPOINT foo;  
    a  
  
    1  
    step s1_tuplock2: SELECT * FROM multixact_conflict FOR SHARE;  
    a  
  
    1  
    step s2_tuplock3: SELECT * FROM multixact_conflict FOR NO KEY UPDATE;  
    a  
  
    1  
    step s1_commit: COMMIT;  
  
With the fixed code, step s2_tuplock3 blocks until session 1 commits,  
which is the correct behavior.  
  
All other cases behave correctly.  
  
Backpatch to 9.3, like the commit that introduced the problem.  

commit   : 7ced1b6c52b0e933813af7389c6ff77cf699f564    
  
author   : Andres Freund <[email protected]>    
date     : Sun, 4 Jan 2015 15:44:49 +0100    
  
committer: Andres Freund <[email protected]>    
date     : Sun, 4 Jan 2015 15:44:49 +0100    

Previously the computation of the total test duration, measured in  
microseconds, accidentally overflowed due to accidentally using signed  
32bit arithmetic.  As the only consequence is that pg_test_timing  
invocations with such, overly large, durations never finished the  
practical consequences of this bug are minor.  
  
Pointed out by Coverity.  
  
Backpatch to 9.2 where pg_test_timing was added.  

commit   : 835a48702e550b6c9958bb053aa6c458971536d0    
  
author   : Andres Freund <[email protected]>    
date     : Sun, 4 Jan 2015 15:35:46 +0100    
  
committer: Andres Freund <[email protected]>    
date     : Sun, 4 Jan 2015 15:35:46 +0100    

In the unlikely case of stdin (fd 0) being closed, the off-by-one  
would lead to pg_xlogdump failing to open files.  
  
Spotted by Coverity.  
  
Backpatch to 9.3 where pg_xlogdump was introduced.  

commit   : 2d8411a0a08d2c24607dc179cb35385e623327c7    
  
author   : Andres Freund <[email protected]>    
date     : Sun, 4 Jan 2015 15:35:46 +0100    
  
committer: Andres Freund <[email protected]>    
date     : Sun, 4 Jan 2015 15:35:46 +0100    

Pointed out by Coverity.  
  
Backpatch to all supported branches, the code has been that way for a  
long while.  

commit   : ff7d46b8572ce566230c53e3c937412b3d19d8cf    
  
author   : Andres Freund <[email protected]>    
date     : Sun, 4 Jan 2015 14:36:21 +0100    
  
committer: Andres Freund <[email protected]>    
date     : Sun, 4 Jan 2015 14:36:21 +0100    

As every error in mark_file_as_archived() will lead to a failure of  
pg_basebackup the FD leak couldn't ever lead to a real problem.  It  
seems better to fix the leak anyway though, rather than silence  
Coverity, as the usage of the function might get extended or copied at  
some point in the future.  
  
Pointed out by Coverity.  
  
Backpatch to 9.2, like the relevant part of the previous patch.  

commit   : 90e4a2bf9b131f45fd4d80815b2b3505bb98c0a6    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 3 Jan 2015 20:51:52 +0100    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 3 Jan 2015 20:51:52 +0100    

WAL (and timeline history) files created by pg_basebackup did not  
maintain the new base backup's archive status. That's currently not a  
problem if the new node is used as a standby - but if that node is  
promoted all still existing files can get archived again.  With a high  
wal_keep_segment settings that can happen a significant time later -  
which is quite confusing.  
  
Change both the backend (for the -x/-X fetch case) and pg_basebackup  
(for -X stream) itself to always mark WAL/timeline files included in  
the base backup as .done. That's in line with walreceiver.c doing so.  
  
The verbosity of the pg_basebackup changes show pretty clearly that it  
needs some refactoring, but that'd result in not be backpatchable  
changes.  
  
Backpatch to 9.1 where pg_basebackup was introduced.  
  
Discussion: [email protected]  

commit   : 70e36adb0d4b7f4656a06a5396a4cf65fc863323    
  
author   : Andres Freund <[email protected]>    
date     : Sat, 3 Jan 2015 20:51:52 +0100    
  
committer: Andres Freund <[email protected]>    
date     : Sat, 3 Jan 2015 20:51:52 +0100    

Backpatch to 9.3 where src/common was introduce, because a bugfix that  
needs to be backpatched, requires the function. Earlier branches will  
have to duplicate the code.  

commit   : e7c1188756c9a57068e6be0c4cf2c448addb8b0c    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 3 Jan 2015 13:14:03 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 3 Jan 2015 13:14:03 -0500    

At one point in the development of this feature, it was claimed that  
allowing negative values would be useful to compensate for timezone  
differences between master and slave servers.  That was based on a mistaken  
assumption that commit timestamps are recorded in local time; but of course  
they're in UTC.  Nor is a negative apply delay likely to be a sane way of  
coping with server clock skew.  However, the committed patch still treated  
negative delays as doing something, and the timezone misapprehension  
survived in the user documentation as well.  
  
If recovery_min_apply_delay were a proper GUC we'd just set the minimum  
allowed value to be zero; but for the moment it seems better to treat  
negative settings as if they were zero.  
  
In passing do some extra wordsmithing on the parameter's documentation,  
including correcting a second misstatement that the parameter affects  
processing of Restore Point records.  
  
Issue noted by Michael Paquier, who also provided the code patch; doc  
changes by me.  Back-patch to 9.4 where the feature was introduced.  

commit   : 01a162ea762a565f28188b5ee3db79b9cc90d37e    
  
author   : Magnus Hagander <[email protected]>    
date     : Sat, 3 Jan 2015 13:18:54 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Sat, 3 Jan 2015 13:18:54 +0100    

The system file is always in the absolute path /etc/, not relative.  
  
David Fetter  

commit   : a5f2f027951902074c465fc1bddc249d30e4c188    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 31 Dec 2014 16:42:45 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 31 Dec 2014 16:42:45 -0500    

Use the phraseology "ISO 8601 week-numbering year" in place of just  
"ISO year", and make related adjustments to other terminology.  
  
The point of this change is that it seems some people see "ISO year"  
and think "standard year", whereupon they're surprised when constructs  
like to_char(..., "IYYY-MM-DD") produce nonsensical results.  Perhaps  
hanging a few more adjectives on it will discourage them from jumping  
to false conclusions.  I put in an explicit warning against that  
specific usage, too, though the main point is to discourage people  
who haven't read this far down the page.  
  
In passing fix some nearby markup and terminology inconsistencies.  

commit   : 5517cfd552c4090f4caff2b8294d56681786d258    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 31 Dec 2014 14:18:56 -0500    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 31 Dec 2014 14:18:56 -0500    

commit   : c35249939b3addf8dc2f57d9213e8aeadc7bccd1    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 31 Dec 2014 12:16:57 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 31 Dec 2014 12:16:57 -0500    

For simple boolean variables such as ON_ERROR_STOP, psql has for a long  
time recognized variant spellings of "on" and "off" (such as "1"/"0"),  
and it also made a point of warning you if you'd misspelled the setting.  
But these conveniences did not exist for other keyword-valued variables.  
In particular, though ECHO_HIDDEN and ON_ERROR_ROLLBACK include "on" and  
"off" as possible values, none of the alternative spellings for those were  
recognized; and to make matters worse the code would just silently assume  
"on" was meant for any unrecognized spelling.  Several people have reported  
getting bitten by this, so let's fix it.  In detail, this patch:  
  
* Allows all spellings recognized by ParseVariableBool() for ECHO_HIDDEN  
and ON_ERROR_ROLLBACK.  
  
* Reports a warning for unrecognized values for COMP_KEYWORD_CASE, ECHO,  
ECHO_HIDDEN, HISTCONTROL, ON_ERROR_ROLLBACK, and VERBOSITY.  
  
* Recognizes all values for all these variables case-insensitively;  
previously there was a mishmash of case-sensitive and case-insensitive  
behaviors.  
  
Back-patch to all supported branches.  There is a small risk of breaking  
existing scripts that were accidentally failing to malfunction; but the  
consensus is that the chance of detecting real problems and preventing  
future mistakes outweighs this.  

commit   : 4e241f7cdf21c293701946cc7f060c8ea5fbcda1    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 30 Dec 2014 14:29:20 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 30 Dec 2014 14:29:20 +0200    

Commit 36a35c55 changed the divisor from 3 to 6, for no apparent reason.  
Reducing GinMaxItemSize like that created a dump/reload hazard: loading a  
9.3 database to 9.4 might fail with "index row size XXX exceeds maximum 1352  
for index ..." error. Revert the change.  
  
While we're at it, make the calculation slightly more accurate. It used to  
divide the available space on page by three, then subtract  
sizeof(ItemIdData), and finally round down. That's not totally accurate; the  
item pointers for the three items are packed tight right after the page  
header, but there is alignment padding after the item pointers. Change the  
calculation to reflect that, like BTMaxItemSize does. I tested this with  
different block sizes on systems with 4- and 8-byte alignment, and the value  
after the final MAXALIGN_DOWN was the same with both methods on all  
configurations. So this does not make any difference currently, but let's be  
tidy.  
  
Also add a comment explaining what the macro does.  
  
This fixes bug #12292 reported by Robert Thaler. Backpatch to 9.4, where the  
bug was introduced.  

commit   : 458e8bc653ab7f25de432762c89272540abfeaeb    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Tue, 30 Dec 2014 20:19:50 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Tue, 30 Dec 2014 20:19:50 +0900    

commit   : 1f35d93843108680e51a35424591c28fc3fbe5fe    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 29 Dec 2014 21:25:23 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 29 Dec 2014 21:25:23 -0500    

Backpatch a9c22d1480aa8e6d97a000292d05ef2b31bbde4e to make future  
backpatching easier.  
  
Backpatch through 9.0  

commit   : 964edb59c1ba2c55bab813aa40b96a52f1b8b653    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 29 Dec 2014 14:20:56 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 29 Dec 2014 14:20:56 -0500    

Document the long forms of \H \i \ir \o \p \r \w ... apparently, we have  
a long and dishonorable history of leaving out the unabbreviated names of  
psql backslash commands.  
  
Avoid saying "Unix shell"; we can just say "shell" with equal clarity,  
and not leave Windows users wondering whether the feature works for them.  
  
Improve consistency of documentation of \g \o \w metacommands.  There's  
no reason to use slightly different wording or markup for each one.  

commit   : 0e3a1f71dfb31527c07a80ccba815b2928d70d8f    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 26 Dec 2014 13:52:27 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 26 Dec 2014 13:52:27 -0300    

We were trying to acquire the lock even when we were subsequently  
not sleeping in some other transaction, which opens us up unnecessarily  
to deadlocks.  In particular, this is troublesome if an update tries to  
lock an updated version of a tuple and finds itself doing EvalPlanQual  
update chain walking; more than two sessions doing this concurrently  
will find themselves sleeping on each other because the HW tuple lock  
acquisition in heap_lock_tuple called from EvalPlanQualFetch races with  
the same tuple lock being acquired in heap_update -- one of these  
sessions sleeps on the other one to finish while holding the tuple lock,  
and the other one sleeps on the tuple lock.  
  
Per trouble report from Andrew Sackville-West in  
http://www.postgresql.org/message-id/20140731233051.GN17765@andrew-ThinkPad-X230  
  
His scenario can be simplified down to a relatively simple  
isolationtester spec file which I don't include in this commit; the  
reason is that the current isolationtester is not able to deal with more  
than one blocked session concurrently and it blocks instead of raising  
the expected deadlock.  In the future, if we improve isolationtester, it  
would be good to include the spec file in the isolation schedule.  I  
posted it in  
http://www.postgresql.org/message-id/[email protected]  
  
Hat tip to Mark Kirkwood, who helped diagnose the trouble.  

commit   : a472b55f3bde0330f5dfe625040c688391484e70    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 25 Dec 2014 13:52:03 -0500    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 25 Dec 2014 13:52:03 -0500    

Windows versions later than Windows Server 2003 map "localhost" to ::1.  
Account for that in the generated pg_hba.conf, fixing another oversight  
in commit f6dc6dd5ba54d52c0733aaafc50da2fbaeabb8b0.  Back-patch to 9.0,  
like that commit.  
  
David Rowley and Noah Misch  

commit   : 6ac1c52e472a1734d0f6bdc41b4ab871e21f7b92    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 25 Dec 2014 22:47:53 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 25 Dec 2014 22:47:53 +0900    

Back-patch to 9.4, where this problem was added.  

commit   : 0680247192ebd7bed0e00053ed907618ca969d00    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 24 Dec 2014 16:35:23 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 24 Dec 2014 16:35:23 -0500    

For some reason this seems to have been missed when the lists in  
src/timezone/tznames/ were first constructed.  We can't put it in Default  
because of the conflict with US CST, but we should certainly list it among  
the alternative entries in Asia.txt.  (I checked for other oversights, but  
all the other abbreviations that are in current use according to the IANA  
files seem to be accounted for.)  Noted while responding to bug #12326.  

commit   : 233ce6e413eba8a74c6400041dcd4c10856ba435    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 24 Dec 2014 10:31:36 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 24 Dec 2014 10:31:36 -0500    

commit   : 2a4ee7bbcf8461a12a8477596e8b08349fe2e742    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 22 Dec 2014 18:31:25 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 22 Dec 2014 18:31:25 -0500    

commit   : 302bed04b2e2c6074cccc3b63aa1962c5a4461dd    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 22 Dec 2014 14:20:19 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 22 Dec 2014 14:20:19 -0500    

json_agg was originally designed to aggregate records. However, it soon  
became clear that it is useful for aggregating all kinds of values and  
that's what we have on 9.3 and 9.4, and in head for it and jsonb_agg.  
The documentation suggested otherwise, so this fixes it.  

commit   : 7ac0aff2b83e88edf5e7dcd4c4b425319d9537d6    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 21 Dec 2014 15:30:39 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 21 Dec 2014 15:30:39 -0500    

Explain that you have to use "VARIADIC ARRAY[]" to pass an empty array  
to a variadic parameter position.  This was already implicit in the text  
but it seems better to spell it out.  
  
Per a suggestion from David Johnston, though I didn't use his proposed  
wording.  Back-patch to all supported branches.  

commit   : 306b9918b2dd2fb93ea5a0fb62904a05c73fd87a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 19 Dec 2014 17:00:21 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 19 Dec 2014 17:00:21 +0200    

We used time(null) to set a TimestampTz field, which gave bogus results.  
Noticed while looking at pg_xlogdump output.  
  
Backpatch to 9.3 and above, where the fast promotion was introduced.  

commit   : 4c853646ae063d6290fc535e3aa80bc0ac69f012    
  
author   : Andres Freund <[email protected]>    
date     : Fri, 19 Dec 2014 14:29:52 +0100    
  
committer: Andres Freund <[email protected]>    
date     : Fri, 19 Dec 2014 14:29:52 +0100    

In LWLockRelease() (and in 9.4+ LWLockUpdateVar()) we release enqueued  
waiters using PGSemaphoreUnlock(). As there are other sources of such  
unlocks backends only wake up if MyProc->lwWaiting is set to false;  
which is only done in the aforementioned functions.  
  
Before this commit there were dangers because the store to lwWaitLink  
could become visible before the store to lwWaitLink. This could both  
happen due to compiler reordering (on most compilers) and on some  
platforms due to the CPU reordering stores.  
  
The possible consequence of this is that a backend stops waiting  
before lwWaitLink is set to NULL. If that backend then tries to  
acquire another lock and has to wait there the list could become  
corrupted once the lwWaitLink store is finally performed.  
  
Add a write memory barrier to prevent that issue.  
  
Unfortunately the barrier support has been only added in 9.2. Given  
that the issue has not knowingly been observed in praxis it seems  
sufficient to prohibit compiler reordering using volatile for 9.0 and  
9.1. Actual problems due to compiler reordering are more likely  
anyway.  
  
Discussion: [email protected]  

commit   : 2b8f74d79722ecf7c27445f088d0e50bcb81ed06    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 18 Dec 2014 16:38:55 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 18 Dec 2014 16:38:55 -0500    

The possibility that constant subexpressions of a CASE might be evaluated  
at planning time was touched on in 9.17.1 (CASE expressions), but it really  
ought to be explained in 4.2.14 (Expression Evaluation Rules) which is the  
primary discussion of such topics.  Add text and an example there, and  
revise the <note> under CASE to link there.  
  
Back-patch to all supported branches, since it's acted like this for a  
long time (though 9.2+ is probably worse because of its more aggressive  
use of constant-folding via replanning of nominally-prepared statements).  
Pre-9.4, also back-patch text added in commit 0ce627d4 about CASE versus  
aggregate functions.  
  
Tom Lane and David Johnston, per discussion of bug #12273.  

commit   : 4a48b4cb390656471ddf52f469ecb56d4e399df1    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 18 Dec 2014 03:55:17 -0500    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 18 Dec 2014 03:55:17 -0500    

Back-patch to 9.0 (all supported versions).  This is mere  
future-proofing in the context of the master branch, but commit  
f6dc6dd5ba54d52c0733aaafc50da2fbaeabb8b0 requires it of older branches.  

commit   : ce083254919d08043fc5c8b060f322f6bc84d1c0    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 18 Dec 2014 08:35:27 +0100    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 18 Dec 2014 08:35:27 +0100    

When starting up from a basebackup taken off a standby extra logic has  
to be applied to compute the point where the data directory is  
consistent. Normal base backups use a WAL record for that purpose, but  
that isn't possible on a standby.  
  
That logic had a error check ensuring that the cluster's control file  
indicates being in recovery. Unfortunately that check was too strict,  
disregarding the fact that the control file could also indicate that  
the cluster was shut down while in recovery.  
  
That's possible when the a cluster starting from a basebackup is shut  
down before the backup label has been removed. When everything goes  
well that's a short window, but when either restore_command or  
primary_conninfo isn't configured correctly the window can get much  
wider. That's because inbetween reading and unlinking the label we  
restore the last checkpoint from WAL which can need additional WAL.  
  
To fix simply also allow starting when the control file indicates  
"shutdown in recovery". There's nicer fixes imaginable, but they'd be  
more invasive.  
  
Backpatch to 9.2 where support for taking basebackups from standbys  
was added.  

commit   : e35e76a8f486aa397cd27f7e5104e7f0eedda877    
  
author   : Noah Misch <[email protected]>    
date     : Thu, 18 Dec 2014 01:24:57 -0500    
  
committer: Noah Misch <[email protected]>    
date     : Thu, 18 Dec 2014 01:24:57 -0500    

Per buildfarm member crake.  Back-patch to 9.4, where the TAP suites  
were introduced.  

commit   : 6b87d423dc6188a0fed4331bc5c8e4c9c88263d1    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 17 Dec 2014 22:48:40 -0500    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 17 Dec 2014 22:48:40 -0500    

Use SSPI authentication to allow connections exclusively from the OS  
user that launched the test suite.  This closes on Windows the  
vulnerability that commit be76a6d39e2832d4b88c0e1cc381aa44a7f86881  
closed on other platforms.  Users of "make installcheck" or custom test  
harnesses can run "pg_regress --config-auth=DATADIR" to activate the  
same authentication configuration that "make check" would use.  
Back-patch to 9.0 (all supported versions).  
  
Security: CVE-2014-0067  

commit   : 3f63b38fb252c54a2c40910dee47c2dc46cc7097    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 17 Dec 2014 13:22:07 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 17 Dec 2014 13:22:07 -0500    

Spotted by Álvaro Herrera.  

commit   : 022d954925d73490f9771cdded16af3e94f27ec0    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 17 Dec 2014 13:14:57 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 17 Dec 2014 13:14:57 -0500    

Adam Brightwell, per report from Martín Marqués.  

commit   : bf1c1f70c8904f87f791da9efa87643c16f2d159    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 17 Dec 2014 11:55:22 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 17 Dec 2014 11:55:22 +0100    

Add Windows versions of generated scripts, and make sure we only  
ignore the scripts int he root directory.  
  
Michael Paquier  

commit   : ba220850bd3be2ea6f9aee35666d5a124b8a7c38    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 17 Dec 2014 11:14:34 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 17 Dec 2014 11:14:34 +0100    

Michael Paquier  

commit   : 9bc93a89b0ff0a95018a84deed088e68f3cc75fb    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 17 Dec 2014 09:59:21 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 17 Dec 2014 09:59:21 +0100    

Spotted by David Johnston  

commit   : 383d224a02a4c481b20c20a0d36e390011d835b7    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 16 Dec 2014 15:35:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 16 Dec 2014 15:35:36 -0500    

MapArrayTypeName would copy up to NAMEDATALEN-1 bytes of the base type  
name, which of course is wrong: after prepending '_' there is only room for  
NAMEDATALEN-2 bytes.  Aside from being the wrong result, this case would  
lead to overrunning the statically allocated work buffer.  This would be a  
security bug if the function were ever used outside bootstrap mode, but it  
isn't, at least not in any currently supported branches.  
  
Aside from fixing the off-by-one loop logic, this patch gets rid of the  
static work buffer by having MapArrayTypeName pstrdup its result; the sole  
caller was already doing that, so this just requires moving the pstrdup  
call.  This saves a few bytes but mainly it makes the API a lot cleaner.  
  
Back-patch on the off chance that there is some third-party code using  
MapArrayTypeName with less-secure input.  Pushing pstrdup into the function  
should not cause any serious problems for such hypothetical code; at worst  
there might be a short term memory leak.  
  
Per Coverity scanning.  

commit   : f2a3cdb6dbe4984c7b5461ed4ece789eab2faf4a    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 16 Dec 2014 14:53:58 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 16 Dec 2014 14:53:58 -0500    

Code added in 9.4 would attempt to divide by zero in such cases.  
Noted while testing fix for missing-pclose problem.  

commit   : 6c75384eed8770b11f01378b37dc4bd07a5710f1    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 16 Dec 2014 13:31:42 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 16 Dec 2014 13:31:42 -0500    

If the called command fails to return data, runShellCommand forgot to  
pclose() the pipe before returning.  This is fairly harmless in the current  
code, because pgbench would then abandon further processing of that client  
thread; so no more than nclients descriptors could be leaked this way.  But  
it's not hard to imagine future improvements whereby that wouldn't be true.  
In any case, it's sloppy coding, so patch all branches.  Found by Coverity.  

commit   : ce864d3276a29fc39155348e6e5ca282d1e51d2d    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 16 Dec 2014 16:34:56 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 16 Dec 2014 16:34:56 +0200    

Backpatch the applicable parts, just to make backpatching future patches  
easier.