PostgreSQL 9.0.18 commit log

commit   : 391aa8aac11fe78f3b2f5743b56e78b0ad6a5d84    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Jul 2014 15:16:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Jul 2014 15:16:01 -0400    

commit   : 11602754aa485c029f125658c62ba1d6502488b0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Jul 2014 14:59:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Jul 2014 14:59:39 -0400    

commit   : 0cee418222d457e39f359aa458c56f3526d65d9c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Jul 2014 00:56:23 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Jul 2014 00:56:23 -0400    

commit   : 7659b6913e927d577e75963c17da6c9ab9180be4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Jul 2014 15:00:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Jul 2014 15:00:50 -0400    

DST law changes in Crimea, Egypt, Morocco.  New zone Antarctica/Troll  
for Norwegian base in Queen Maud Land.  

commit   : ec66f1adbf01a1961836c7af42de415b017f4416    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 18 Jul 2014 16:05:17 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 18 Jul 2014 16:05:17 -0400    

~/.pgpass is a sound choice everywhere, and "peer" authentication is  
safe on every platform it supports.  Cease to recommend "trust"  
authentication, the safety of which is deeply configuration-specific.  
Back-patch to 9.0, where pg_upgrade was introduced.  

commit   : b8c24f7ab8f50efd0b55f39cb10d4df7df9ff94b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jul 2014 13:00:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jul 2014 13:00:27 -0400    

If pg_regcomp failed after having invoked markst/cleanst, it would leak any  
"struct subre" nodes it had created.  (We've already detected all regex  
syntax errors at that point, so the only likely causes of later failure  
would be query cancel or out-of-memory.)  To fix, make sure freesrnode  
knows the difference between the pre-cleanst and post-cleanst cleanup  
procedures.  Add some documentation of this less-than-obvious point.  
  
Also, newlacon did the wrong thing with an out-of-memory failure from  
realloc(), so that the previously allocated array would be leaked.  
  
Both of these are pretty low-probability scenarios, but a bug is a bug,  
so patch all the way back.  
  
Per bug #10976 from Arthur O'Dwyer.  

commit   : bf08864b8d193b1d49f1c7719e5c968e7127cbd2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 15 Jul 2014 13:24:07 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 15 Jul 2014 13:24:07 -0400    

Trying to reassign objects owned by a user that had text search  
dictionaries or configurations used to fail with:  
ERROR:  unexpected classid 3600  
or  
ERROR:  unexpected classid 3602  
  
Fix by adding cases for those object types in a switch in pg_shdepend.c.  
  
Both REASSIGN OWNED and text search objects go back all the way to 8.1,  
so backpatch to all supported branches.  In 9.3 the alter-owner code was  
made generic, so the required change in recent branches is pretty  
simple; however, for 9.2 and older ones we need some additional  
reshuffling to enable specifying objects by OID rather than name.  
  
Text search templates and parsers are not owned objects, so there's no  
change required for them.  
  
Per bug #9749 reported by Michal Novotný  

commit   : 8b300ce87dd56a83bdd97197d93a2edefaeba66a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 14 Jul 2014 20:37:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 14 Jul 2014 20:37:00 -0400    

From: Josh Kupershmidt <schmiddy@gmail.com>  

commit   : 2006bf8104c5686c3696f192b19ba5b657b79b6a    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sat, 12 Jul 2014 14:19:57 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sat, 12 Jul 2014 14:19:57 +0200    

Adds support for autocomplete of LC_COLLATE and LC_CTYPE to  
the CREATE DATABASE command in psql.  

commit   : cd8ba91a055e7ac8471addf28fa4412db8d2e529    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jul 2014 19:12:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jul 2014 19:12:51 -0400    

ExecEvalWholeRowVar incorrectly supposed that it could "bless" the source  
TupleTableSlot just once per query.  But if the input is coming from an  
Append (or, perhaps, other cases?) more than one slot might be returned  
over the query run.  This led to "record type has not been registered"  
errors when a composite datum was extracted from a non-blessed slot.  
  
This bug has been there a long time; I guess it escaped notice because when  
dealing with subqueries the planner tends to expand whole-row Vars into  
RowExprs, which don't have the same problem.  It is possible to trigger  
the problem in all active branches, though, as illustrated by the added  
regression test.  

commit   : 2865d5952d6d89c1006701cb94bc40b146ead880    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jul 2014 14:03:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jul 2014 14:03:30 -0400    

While the x output of "select x from t group by x" can be presumed unique,  
this does not hold for "select x, generate_series(1,10) from t group by x",  
because we may expand the set-returning function after the grouping step.  
(Perhaps that should be re-thought; but considering all the other oddities  
involved with SRFs in targetlists, it seems unlikely we'll change it.)  
Put a check in query_is_distinct_for() so it's not fooled by such cases.  
  
Back-patch to all supported branches.  
  
David Rowley  

commit   : d0091e3c03eb87b746f3ba9188a9d6f6c27b8c10    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jul 2014 14:20:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jul 2014 14:20:47 -0400    

This function wasn't originally thought to be really user-facing,  
because converting a table to a view isn't something we expect people  
to do manually.  So not all that much effort was spent on the error  
messages; in particular, while the code will complain that you got  
the column types wrong it won't say exactly what they are.  But since  
we repurposed the code to also check compatibility of rule RETURNING  
lists, it's definitely user-facing.  It now seems worthwhile to add  
errdetail messages showing exactly what the conflict is when there's  
a mismatch of column names or types.  This is prompted by bug #10836  
from Matthias Raffelsieper, which might have been forestalled if the  
error message had reported the wrong column type as being "record".  
  
Per Alvaro's advice, back-patch to branches before 9.4, but resist  
the temptation to rephrase any existing strings there.  Adding new  
strings is not really a translation degradation; anyway having the  
info presented in English is better than not having it at all.  

commit   : c6b3fb4c53e6a4b04421d5dc00655e4bc11de8f9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jul 2014 11:23:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jul 2014 11:23:01 -0400    

The output buffer size in unaccent_lexize() was calculated as input string  
length times pg_database_encoding_max_length(), which effectively assumes  
that replacement strings aren't more than one character.  While that was  
all that we previously documented it to support, the code actually has  
always allowed replacement strings of arbitrary length; so if you tried  
to make use of longer strings, you were at risk of buffer overrun.  To fix,  
use an expansible StringInfo buffer instead of trying to determine the  
maximum space needed a-priori.  
  
This would be a security issue if unaccent rules files could be installed  
by unprivileged users; but fortunately they can't, so in the back branches  
the problem can be labeled as improper configuration by a superuser.  
Nonetheless, a memory stomp isn't a nice way of reacting to improper  
configuration, so let's back-patch the fix.  

commit   : d51a6004d00b2013591d466cdac9eba13e25aee3    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 26 Jun 2014 14:27:27 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 26 Jun 2014 14:27:27 +0900    

7380b63 changed log_filename so that epoch was not appended to it  
when no format specifier is given. But the example of CSV log file name  
with epoch still left in log_filename document. This commit removes  
such obsolete example.  
  
This commit also documents the defaults of log_directory and  
log_filename.  
  
Backpatch to all supported versions.  
  
Christoph Berg  

commit   : 83131e63484c0c408f532e90132cc704f5a04161    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jun 2014 22:13:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jun 2014 22:13:58 -0400    

ExecMakeTableFunctionResult evaluated the arguments for a function-in-FROM  
in the query-lifespan memory context.  This is insignificant in simple  
cases where the function relation is scanned only once; but if the function  
is in a sub-SELECT or is on the inside of a nested loop, any memory  
consumed during argument evaluation can add up quickly.  (The potential for  
trouble here had been foreseen long ago, per existing comments; but we'd  
not previously seen a complaint from the field about it.)  To fix, create  
an additional temporary context just for this purpose.  
  
Per an example from MauMau.  Back-patch to all active branches.  

commit   : b5c9a3bc1024f51533eaa5d682ae7d7bf8d2fb9b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Jun 2014 10:52:25 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Jun 2014 10:52:25 -0400    

Commit 453a5d91d49e4d35054f92785d830df4067e10c1 made it available to the  
src/test/regress build of pg_regress, but all pg_regress builds need the  
same treatment.  Patch 9.2 through 8.4; in 9.3 and later, pg_regress  
gets pqsignal() via libpgport.  

commit   : 5f09c583c014bdc7c7330b18c74e24f63d164ced    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Jun 2014 09:41:13 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Jun 2014 09:41:13 -0400    

Any OS user able to access the socket can connect as the bootstrap  
superuser and proceed to execute arbitrary code as the OS user running  
the test.  Protect against that by placing the socket in a temporary,  
mode-0700 subdirectory of /tmp.  The pg_regress-based test suites and  
the pg_upgrade test suite were vulnerable; the $(prove_check)-based test  
suites were already secure.  Back-patch to 8.4 (all supported versions).  
The hazard remains wherever the temporary cluster accepts TCP  
connections, notably on Windows.  
  
As a convenient side effect, this lets testing proceed smoothly in  
builds that override DEFAULT_PGSOCKET_DIR.  Popular non-default values  
like /var/run/postgresql are often unwritable to the build user.  
  
Security: CVE-2014-0067  

commit   : 52c37346aa51f2aa186b7e2d0f5d6f4104377b07    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Jun 2014 09:41:13 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Jun 2014 09:41:13 -0400    

This function is pervasive on free software operating systems; import  
NetBSD's implementation.  Back-patch to 8.4, like the commit that will  
harness it.  

commit   : 3fec825f9f8049e4e27aa1904d8c2581d73a08e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 20:14:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 20:14:52 -0400    

Prior to 9.0, pg_dump handled comments on large objects by dumping a bunch  
of COMMENT commands into a single BLOB COMMENTS archive object.  With  
sufficiently many such comments, some of the commands would likely get  
split across bufferloads when restoring, causing failures in  
direct-to-database restores (though no problem would be evident in text  
output).  This is the same type of issue we have with table data dumped as  
INSERT commands, and it can be fixed in the same way, by using a mini SQL  
lexer to figure out where the command boundaries are.  Fortunately, the  
COMMENT commands are no more complex to lex than INSERTs, so we can just  
re-use the existing lexer for INSERTs.  
  
Per bug #10611 from Jacek Zalewski.  Back-patch to all active branches.  

commit   : 637264641fd970b8f86c98d8728894a82708fdb2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 16:51:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 16:51:20 -0400    

Robert Frost is no longer with us, but his copyrights still are, so  
let's stop using "Stopping by Woods on a Snowy Evening" as test data  
before somebody decides to sue us.  Wordsworth is more safely dead.  

commit   : 4d5ea42904095cc596a1baa2eb0e41bda667b580    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Jun 2014 22:48:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Jun 2014 22:48:16 -0400    

When we grabbed this file off the Snowball project's website, we mistakenly  
supposed that it was in LATIN1 encoding, but evidently it was actually in  
LATIN2.  This resulted in ő (o-double-acute, U+0151, which is code 0xF5 in  
LATIN2) being misconverted into õ (o-tilde, U+00F5), as complained of in  
bug #10589 from Zoltán Sörös.  We'd have messed up u-double-acute too,  
but there aren't any of those in the file.  Other characters used in the  
file have the same codes in LATIN1 and LATIN2, which no doubt helped hide  
the problem for so long.  
  
The error is not only ours: the Snowball project also was confused about  
which encoding is required for Hungarian.  But dealing with that will  
require source-code changes that I'm not at all sure we'll wish to  
back-patch.  Fixing the stopword file seems reasonably safe to back-patch  
however.  

commit   : 8940970c0c32432400323e556e76ead1a0996995    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 6 Jun 2014 19:11:18 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 6 Jun 2014 19:11:18 +0900    

This fix is a part of commit e2f02ed64e5e953d60315b19509f697b073f840d  
which fixed the same problem on 9.3, 9.2 and 9.1.  

commit   : c9f4618e5b0cee1b125e59b947c9f4b3fe1887d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jun 2014 11:31:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jun 2014 11:31:22 -0400    

It's critical that the backend's idea of LOBLKSIZE match the way data has  
actually been divided up in pg_largeobject.  While we don't provide any  
direct way to adjust that value, doing so is a one-line source code change  
and various people have expressed interest recently in changing it.  So,  
just as with TOAST_MAX_CHUNK_SIZE, it seems prudent to record the value in  
pg_control and cross-check that the backend's compiled-in setting matches  
the on-disk data.  
  
Also tweak the code in inv_api.c so that fetches from pg_largeobject  
explicitly verify that the length of the data field is not more than  
LOBLKSIZE.  Formerly we just had Asserts() for that, which is no protection  
at all in production builds.  In some of the call sites an overlength data  
value would translate directly to a security-relevant stack clobber, so it  
seems worth one extra runtime comparison to be sure.  
  
In the back branches, we can't change the contents of pg_control; but we  
can still make the extra checks in inv_api.c, which will offer some amount  
of protection against running with the wrong value of LOBLKSIZE.  

commit   : 037c6fb9f011032259f83a90a9fed3ea8b709be1    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 4 Jun 2014 23:27:10 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 4 Jun 2014 23:27:10 +0200    

HeapTupleSatisfiesVacuum() didn't properly discern between  
DELETE_IN_PROGRESS and INSERT_IN_PROGRESS for rows that have been  
inserted in the current transaction and deleted in a aborted  
subtransaction of the current backend. At the very least that caused  
problems for CLUSTER and CREATE INDEX in transactions that had  
aborting subtransactions producing rows, leading to warnings like:  
WARNING:  concurrent delete in progress within table "..."  
possibly in an endless, uninterruptible, loop.  
  
Instead of treating *InProgress xmins the same as *IsCurrent ones,  
treat them as being distinct like the other visibility routines. As  
implemented this separatation can cause a behaviour change for rows  
that have been inserted and deleted in another, still running,  
transaction. HTSV will now return INSERT_IN_PROGRESS instead of  
DELETE_IN_PROGRESS for those. That's both, more in line with the other  
visibility routines and arguably more correct. The latter because a  
INSERT_IN_PROGRESS will make callers look at/wait for xmin, instead of  
xmax.  
The only current caller where that's possibly worse than the old  
behaviour is heap_prune_chain() which now won't mark the page as  
prunable if a row has concurrently been inserted and deleted. That's  
harmless enough.  
  
As a cautionary measure also insert a interrupt check before the gotos  
in IndexBuildHeapScan() that lead to the uninterruptible loop. There  
are other possible causes, like a row that several sessions try to  
update and all fail, for repeated loops and the cost of doing so in  
the retry case is low.  
  
As this bug goes back all the way to the introduction of  
subtransactions in 573a71a5da backpatch to all supported releases.  
  
Reported-By: Sandro Santilli  

commit   : 4f725bbc4e6938b4c8ce960d59791f4675f4a3d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 May 2014 18:18:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 May 2014 18:18:28 -0400    

As of Xcode 5.0, Apple isn't including the Python framework as part of the  
SDK-level files, which means that linking to it might fail depending on  
whether Xcode thinks you've selected a specific SDK version.  According to  
their Tech Note 2328, they've basically deprecated the framework method of  
linking to libpython and are telling people to link to the shared library  
normally.  (I'm pretty sure this is in direct contradiction to the advice  
they were giving a few years ago, but whatever.)  Testing says that this  
approach works fine at least as far back as OS X 10.4.11, so let's just  
rip out the framework special case entirely.  We do still need a special  
case to decide that OS X provides a shared library at all, unfortunately  
(I wonder why the distutils check doesn't work ...).  But this is still  
less of a special case than before, so it's fine.  
  
Back-patch to all supported branches, since we'll doubtless be hearing  
about this more as more people update to recent Xcode.  

commit   : b2f6754d2195dda8d7a1ec767ba3c2568458b524    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 May 2014 13:51:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 May 2014 13:51:15 -0400    

The original coding in contrib/uuid-ossp created and destroyed a uuid_t  
object (or, in some cases, even two of them) each time it was called.  
This is not the intended usage: you're supposed to keep the uuid_t object  
around so that the library can cache its state across uses.  (Other UUID  
libraries seem to keep equivalent state behind-the-scenes in static  
variables, but OSSP chose differently.)  Aside from being quite inefficient,  
creating a new uuid_t loses knowledge of the previously generated UUID,  
which in theory could result in duplicate V1-style UUIDs being created  
on sufficiently fast machines.  
  
On at least some platforms, creating a new uuid_t also draws some entropy  
from /dev/urandom, leaving less for the rest of the system.  This seems  
sufficiently unpleasant to justify back-patching this change.  

commit   : 534cce2fc834c71a64fda72d4a8ec4e5f669683e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 19:29:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 19:29:53 -0400    

This reverts commit a670f5ed1ad0a472c4981b821bfcfc2c9dd0c2fd.  
  
It turns out that the %name-prefix syntax without "=" does not work  
at all in pre-2.4 Bison.  We are not prepared to make such a large  
jump in minimum required Bison version just to suppress a warning  
message in a version hardly any developers are using yet.  
When 3.0 gets more popular, we'll figure out a way to deal with this.  
In the meantime, BISONFLAGS=-Wno-deprecated is recommendable for  
anyone using 3.0 who doesn't want to see the warning.  

commit   : a670f5ed1ad0a472c4981b821bfcfc2c9dd0c2fd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 15:42:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 15:42:04 -0400    

%name-prefix doesn't use an "=" sign according to the Bison docs, but it  
silently accepted one anyway, until Bison 3.0.  This was originally a  
typo of mine in commit 012abebab1bc72043f3f670bf32e91ae4ee04bd2, and we  
seem to have slavishly copied the error into all the other grammar files.  
  
Per report from Vik Fearing; analysis by Peter Eisentraut.  
  
Back-patch to all active branches, since somebody might try to build  
a back branch with up-to-date tools.  

commit   : c8186b3c223e2abaf51808f7e74e6c03a2511938    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 May 2014 22:23:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 May 2014 22:23:42 -0400    

On Mingw, it seems that scanf() doesn't necessarily accept the same format  
codes that printf() does, and in particular it may fail to recognize %llu  
even though printf() does.  Since configure only probes printf() behavior  
while setting up the INT64_FORMAT macros, this means it's unsafe to use  
those macros with scanf().  We had only one instance of such a coding  
pattern, in contrib/pg_stat_statements, so change that code to avoid  
the problem.  
  
Per buildfarm warnings.  Back-patch to 9.0 where the troublesome code  
was introduced.  
  
Michael Paquier  

commit   : 42279b291a2de8e4bd5ecaf4f8214337e4b0c936    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 May 2014 13:21:59 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 May 2014 13:21:59 +0300    

The macros and functions that work with backup blocks in the redo function  
use 0-based numbering, so let's use that consistently in the function that  
generates the records too. Makes it so much easier to compare the  
generation and replay functions.  
  
Backpatch to 9.0, where we switched from 1-based to 0-based numbering.  

commit   : 0fc94340753f19da8acca5fc53039adbf2fa3632    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 May 2014 09:47:50 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 May 2014 09:47:50 +0300    

Commit dd428c79 added dbId and tsId to the xl_xact_commit struct but missed  
that prepared transaction commits reuse that struct. Fix that.  
  
Because those fields were left unitialized, replaying a commit prepared WAL  
record in a hot standby node would fail to remove the relcache init file.  
That can lead to "could not open file" errors on the standby. Relcache init  
file only needs to be removed when a system table/index is rewritten in the  
transaction using two phase commit, so that should be rare in practice. In  
HEAD, the incorrect dbId/tsId values are also used for filtering in logical  
replication code, causing the transaction to always be filtered out.  
  
Analysis and fix by Andres Freund. Backpatch to 9.0 where hot standby was  
introduced.  

commit   : 9fb8cd25fd98a17f6038d788b14dbb1b92f01e1b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 May 2014 15:58:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 May 2014 15:58:09 -0400    

In yesterday's commit 2dc4f011fd61501cce507be78c39a2677690d44b, I tried  
to force buffering of stdout/stderr in initdb to be what it is by  
default when the program is run interactively on Unix (since that's how  
most manual testing is done).  This tripped over the fact that Windows  
doesn't support _IOLBF mode.  We dealt with that a long time ago in  
syslogger.c by falling back to unbuffered mode on Windows.  Export that  
solution in port.h and use it in initdb.  
  
Back-patch to 8.4, like the previous commit.  

commit   : f1f3bcb7c4d4613246b940e966162130997c84e2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 May 2014 18:29:20 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 May 2014 18:29:20 +0300    

The proc array can contain duplicate XIDs, when a transaction is just being  
prepared for two-phase commit. To cope, remove any duplicates in  
txid_current_snapshot(). Also ignore duplicates in the input functions, so  
that if e.g. you have an old pg_dump file that already contains duplicates,  
it will be accepted.  
  
Report and fix by Jan Wieck. Backpatch to all supported versions.  

commit   : 82a83ec6841dc598af5a47a45989fd969e3099a5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 May 2014 16:37:50 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 May 2014 16:37:50 +0300    

To lock a prepared transaction's shared memory entry, we used to mark it  
with the XID of the backend. When the XID was no longer active according  
to the proc array, the entry was implicitly considered as not locked  
anymore. However, when preparing a transaction, the backend's proc array  
entry was cleared before transfering the locks (and some other state) to  
the prepared transaction's dummy PGPROC entry, so there was a window where  
another backend could finish the transaction before it was in fact fully  
prepared.  
  
To fix, rewrite the locking mechanism of global transaction entries. Instead  
of an XID, just have simple locked-or-not flag in each entry (we store the  
locking backend's backend id rather than a simple boolean, but that's just  
for debugging purposes). The backend is responsible for explicitly unlocking  
the entry, and to make sure that that happens, install a callback to unlock  
it on abort or process exit.  
  
Backpatch to all supported versions.  

commit   : 5e798475cc4f23ac2a68d254a5db2e57995a870e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 May 2014 21:14:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 May 2014 21:14:06 -0400    

Since this program may print to either stdout or stderr, the relative  
ordering of its messages depends on the buffering behavior of those files.  
Force stdout to be line-buffered and stderr to be unbuffered, ensuring  
that the behavior will match standard Unix interactive behavior, even  
when stdout and stderr are rerouted to a file.  
  
Per complaint from Tomas Vondra.  The particular case he pointed out is  
new in HEAD, but issues of the same sort could arise in any branch with  
other error messages, so back-patch to all branches.  
  
I'm unsure whether we might not want to do this in other client programs  
as well.  For the moment, just fix initdb.  

commit   : c87c43f087c569b7ceaa3fc25021dd897e4ca7c4    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 13 May 2014 14:16:28 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 13 May 2014 14:16:28 +0300    

The code expands a varbit gist leaf key to a node key by copying the bit  
data twice in a varlen datum, as both the lower and upper key. The lower key  
was expanded to INTALIGN size, but the padding bytes were not initialized.  
That's a problem because when the lower/upper keys are compared, the padding  
bytes are used compared too, when the values are otherwise equal. That could  
lead to incorrect query results.  
  
REINDEX is advised for any btree_gist indexes on bit or bit varying data  
type, to fix any garbage padding bytes on disk.  
  
Per Valgrind, reported by Andres Freund. Backpatch to all supported  
versions.  

commit   : 9cb9d75246afa443d500dc74563d61956e8deaa9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 May 2014 14:24:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 May 2014 14:24:18 -0400    

config.pl and buildenv.pl can be used to customize build settings when  
using MSVC.  They should never get committed into the common source tree.  
  
Back-patch to 9.0; it looks like the rules were different in 8.4.  
  
Michael Paquier  

commit   : d23bf2e6c8ef030e05455ee961ff2cefc00c8e5f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 May 2014 10:48:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 May 2014 10:48:14 -0400    

Usually the search would find plain "tclsh" without any trouble,  
but some installations might only have the version-numbered flavor  
of that program.  
  
No compatibility problems have been reported with 8.6, so we might  
as well back-patch this to all active branches.  
  
Christoph Berg  

commit   : 6b2a1445ec8a631060c4cbff3f172bf31d3379b9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 May 2014 21:45:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 May 2014 21:45:02 -0400    

Back in 8.3, we installed permissions checks in these functions (see  
commits 8bc225e7990a and cc26599b7206).  But we forgot to document that  
anywhere in the user-facing docs; it did get mentioned in the 8.3 release  
notes, but nobody's looking at that any more.  Per gripe from Suya Huang.  

commit   : f483b15f1a18221565b08fe4f27af208d0cb1c0f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 8 May 2014 19:29:02 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 8 May 2014 19:29:02 -0400    

Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b broke it.  The change in  
sub-second precision at extreme dates is normal.  The inconsistent  
truncation vs. rounding is essentially a bug, albeit a longstanding one.  
Back-patch to 8.4, like the causative commit.  

commit   : 8b4efe1f3a4373c9442a710fb01b14c445749d6a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 8 May 2014 14:43:04 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 8 May 2014 14:43:04 +0300    

To-be-deleted list pages contain no useful information, as they are being  
deleted, but we must still protect the writes from being torn by a crash  
after a partial write. To do that, re-initialize the pages on WAL replay.  
  
Jeff Janes caught this with a test program to test partial writes.  
Backpatch to all supported versions.  

commit   : 77e66282769b4e6df181210cc24ab2073f123eb7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 May 2014 21:38:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 May 2014 21:38:47 -0400    

If the server sends a long stream of data, and the server + network are  
consistently fast enough to force the recv() loop in pqReadData() to  
iterate until libpq's input buffer is full, then upon processing the last  
incomplete message in each bufferload we'd usually double the buffer size,  
due to supposing that we didn't have enough room in the buffer to finish  
collecting that message.  After filling the newly-enlarged buffer, the  
cycle repeats, eventually resulting in an out-of-memory situation (which  
would be reported misleadingly as "lost synchronization with server").  
Of course, we should not enlarge the buffer unless we still need room  
after discarding already-processed messages.  
  
This bug dates back quite a long time: pqParseInput3 has had the behavior  
since perhaps 2003, getCopyDataMessage at least since commit 70066eb1a1ad  
in 2008.  Probably the reason it's not been isolated before is that in  
common environments the recv() loop would always be faster than the server  
(if on the same machine) or faster than the network (if not); or at least  
it wouldn't be slower consistently enough to let the buffer ramp up to a  
problematic size.  The reported cases involve Windows, which perhaps has  
different timing behavior than other platforms.  
  
Per bug #7914 from Shin-ichi Morita, though this is different from his  
proposed solution.  Back-patch to all supported branches.  

commit   : 7f66ade71a59a8da58a43514ca851ab5e96dd209    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 May 2014 14:25:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 May 2014 14:25:25 -0400    

ActiveSnapshot needs to be set when we call ExecutorRewind because some  
plan node types may execute user-defined functions during their ReScan  
calls (nodeLimit.c does so, at least).  The wisdom of that is somewhat  
debatable, perhaps, but for now the simplest fix is to make sure the  
required context is valid.  Failure to do this typically led to a  
null-pointer-dereference core dump, though it's possible that in more  
complex cases a function could be executed with the wrong snapshot  
leading to very subtle misbehavior.  
  
Per report from Leif Jensen.  It's been broken for a long time, so  
back-patch to all active branches.  

commit   : 8398f3736c44cc050ad61856e0b403dcbcb5254d    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 6 May 2014 19:35:24 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 6 May 2014 19:35:24 -0700    

Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b introduced a test that  
couldn't be made consistent between integer and floating-point  
timestamps.  
  
It was designed to test the longest possible interval output length,  
so removing four zeros from the number of hours, as this patch does,  
is not ideal. But the test still has some utility for its original  
purpose, and there aren't a lot of other good options.  
  
Noah Misch suggested a different approach where we test that the  
output either matches what we expect from integer timestamps or what  
we expect from floating-point timestamps. That seemed to obscure an  
otherwise simple test, however.  
  
Reviewed by Tom Lane and Noah Misch.  

commit   : 1d033d30540c036d3ead1e0a42a16a2c761f9582    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2014 11:26:25 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2014 11:26:25 -0400    

This was not changed in HEAD, but will be done later as part of a  
pgindent run.  Future pgindent runs will also do this.  
  
Report by Tom Lane  
  
Backpatch through all supported branches, but not HEAD  

commit   : d65ecdf4110bb352527dd2f6de31421d5b769258    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 6 May 2014 15:14:51 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 6 May 2014 15:14:51 +0300    

Found via valgrind. The bug exists since the introduction of the walsender,  
so backpatch to 9.0.  
  
Andres Freund  

commit   : 91c8c106facadc868308e90dbaca3ac6017be5f0    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Tue, 6 May 2014 13:04:30 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Tue, 6 May 2014 13:04:30 +0200    

When array of char * was used as target for a FETCH statement returning more  
than one row, it tried to store all the result in the first element. Instead it  
should dump array of char pointers with right offset, use the address instead  
of the value of the C variable while reading the array and treat such variable  
as char **, instead of char * for pointer arithmetic.  
  
Patch by Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>  

commit   : 7d5b6862180b3e2ef4c34d5f0d397ae5825acd71    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 May 2014 14:43:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 May 2014 14:43:52 -0400    

Commit fad153ec45299bd4d4f29dec8d9e04e2f1c08148 modified sinval.c to reduce  
the number of calls into sinvaladt.c (which require taking a shared lock)  
by keeping a local buffer of collected-but-not-yet-processed messages.  
However, if processing of the last message in a batch resulted in a  
recursive call to ReceiveSharedInvalidMessages, we could overwrite that  
message with a new one while the outer invalidation function was still  
working on it.  This would be likely to lead to invalidation of the wrong  
cache entry, allowing subsequent processing to use stale cache data.  
The fix is just to make a local copy of each message while we're processing  
it.  
  
Spotted by Andres Freund.  Back-patch to 8.4 where the bug was introduced.  

commit   : 9174c77f86755494d1b3845fffb7f30db0ba2ec1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 May 2014 15:30:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 2 May 2014 15:30:44 -0400    

This test used to just define an unused static inline function and check  
whether that causes a warning.  But newer clang versions warn about  
unused static inline functions when defined inside a .c file, but not  
when defined in an included header, which is the case we care about.  
Change the test to cope.  
  
Andres Freund  

commit   : 7a4f114f3d30201ac39184e3cc9191a996a04dd9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 May 2014 15:19:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 May 2014 15:19:20 -0400    

If we have an array of records stored on disk, the individual record fields  
cannot contain out-of-line TOAST pointers: the tuptoaster.c mechanisms are  
only prepared to deal with TOAST pointers appearing in top-level fields of  
a stored row.  The same applies for ranges over composite types, nested  
composites, etc.  However, the existing code only took care of expanding  
sub-field TOAST pointers for the case of nested composites, not for other  
structured types containing composites.  For example, given a command such  
as  
  
UPDATE tab SET arraycol = ARRAY[(ROW(x,42)::mycompositetype] ...  
  
where x is a direct reference to a field of an on-disk tuple, if that field  
is long enough to be toasted out-of-line then the TOAST pointer would be  
inserted as-is into the array column.  If the source record for x is later  
deleted, the array field value would become a dangling pointer, leading  
to errors along the line of "missing chunk number 0 for toast value ..."  
when the value is referenced.  A reproducible test case for this was  
provided by Jan Pecek, but it seems likely that some of the "missing chunk  
number" reports we've heard in the past were caused by similar issues.  
  
Code-wise, the problem is that PG_DETOAST_DATUM() is not adequate to  
produce a self-contained Datum value if the Datum is of composite type.  
Seen in this light, the problem is not just confined to arrays and ranges,  
but could also affect some other places where detoasting is done in that  
way, for example form_index_tuple().  
  
I tried teaching the array code to apply toast_flatten_tuple_attribute()  
along with PG_DETOAST_DATUM() when the array element type is composite,  
but this was messy and imposed extra cache lookup costs whether or not any  
TOAST pointers were present, indeed sometimes when the array element type  
isn't even composite (since sometimes it takes a typcache lookup to find  
that out).  The idea of extending that approach to all the places that  
currently use PG_DETOAST_DATUM() wasn't attractive at all.  
  
This patch instead solves the problem by decreeing that composite Datum  
values must not contain any out-of-line TOAST pointers in the first place;  
that is, we expand out-of-line fields at the point of constructing a  
composite Datum, not at the point where we're about to insert it into a  
larger tuple.  This rule is applied only to true composite Datums, not  
to tuples that are being passed around the system as tuples, so it's not  
as invasive as it might sound at first.  With this approach, the amount  
of code that has to be touched for a full solution is greatly reduced,  
and added cache lookup costs are avoided except when there actually is  
a TOAST pointer that needs to be inlined.  
  
The main drawback of this approach is that we might sometimes dereference  
a TOAST pointer that will never actually be used by the query, imposing a  
rather large cost that wasn't there before.  On the other side of the coin,  
if the field value is used multiple times then we'll come out ahead by  
avoiding repeat detoastings.  Experimentation suggests that common SQL  
coding patterns are unaffected either way, though.  Applications that are  
very negatively affected could be advised to modify their code to not fetch  
columns they won't be using.  
  
In future, we might consider reverting this solution in favor of detoasting  
only at the point where data is about to be stored to disk, using some  
method that can drill down into multiple levels of nested structured types.  
That will require defining new APIs for structured types, though, so it  
doesn't seem feasible as a back-patchable fix.  
  
Note that this patch changes HeapTupleGetDatum() from a macro to a function  
call; this means that any third-party code using that macro will not get  
protection against creating TOAST-pointer-containing Datums until it's  
recompiled.  The same applies to any uses of PG_RETURN_HEAPTUPLEHEADER().  
It seems likely that this is not a big problem in practice: most of the  
tuple-returning functions in core and contrib produce outputs that could  
not possibly be toasted anyway, and the same probably holds for third-party  
extensions.  
  
This bug has existed since TOAST was invented, so back-patch to all  
supported branches.  

commit   : c4252ec43cd95b20b278f023c3616eb39dcd2b8b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Apr 2014 13:46:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Apr 2014 13:46:25 -0400    

Since ruleutils.c recurses, it could be driven to stack overflow by  
deeply nested constructs.  Very large queries might also take long  
enough to deparse that a check for interrupts seems like a good idea.  
Stick appropriate tests into a couple of key places.  
  
Noted by Greg Stark.  Back-patch to all supported branches.  

commit   : c06b7219a0a497c9257cf2dee419f56d7f0622d5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 30 Apr 2014 10:34:15 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 30 Apr 2014 10:34:15 +0300    

Some popen() calls were missing SYSTEMQUOTEs, which caused initdb and  
pg_upgrade to fail on Windows, if the installation path contained both  
spaces and @ signs.  
  
Patch by Nikhil Deshpande. Backpatch to all supported versions.  

commit   : 62eff5af1973a4ffa2a69a574fae3f3bff208b5b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 28 Apr 2014 16:12:45 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 28 Apr 2014 16:12:45 +0300    

In writeListPage, never take a full-page image of the page, because we  
have all the information required to re-initialize in the WAL record  
anyway. Before this fix, a full-page image was always generated, unless  
full_page_writes=off, because when the page is initialized its LSN is  
always 0. In stable-branches, keep the code to restore the backup blocks  
if they exist, in case that the WAL is generated with an older minor  
version, but in master Assert that there are no full-page images.  
  
In the redo routine, add missing "off++". Otherwise the tuples are added  
to the page in reverse order. That happens to be harmless because we  
always scan and remove all the tuples together, but it was clearly wrong.  
Also, it was masked by the first bug unless full_page_writes=off, because  
the page was always restored from a full-page image.  
  
Backpatch to all supported versions.  

commit   : b7a3e1173991a147a43dcd3f67b98be051153b4b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Apr 2014 13:29:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 24 Apr 2014 13:29:48 -0400    

Once we've completed a PREPARE, our session is not running a transaction,  
so its entry in pg_stat_activity should show xact_start as null, rather  
than leaving the value as the start time of the now-prepared transaction.  
  
I think possibly this oversight was triggered by faulty extrapolation  
from the adjacent comment that says PrepareTransaction should not call  
AtEOXact_PgStat, so tweak the wording of that comment.  
  
Noted by Andres Freund while considering bug #10123 from Maxim Boguk,  
although this error doesn't seem to explain that report.  
  
Back-patch to all active branches.  

commit   : 757ade42d0ea1a3542115dc873805f8027800a16    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Apr 2014 16:12:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 17 Apr 2014 16:12:24 -0400    

Introduced in 585bca39: msgid is not used in the Windows code path.  
  
Also adjust comments a tad (mostly to keep pgindent from messing it up).  
  
David Rowley  

commit   : a1b9c46300e2a24478f480c63ec2c53c3e53acef    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 17 Apr 2014 12:37:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 17 Apr 2014 12:37:53 -0400    

Specifically, on-stack memset() might be removed, so:  
  
	* Replace memset() with px_memset()  
	* Add px_memset to copy_crlf()  
	* Add px_memset to pgp-s2k.c  
  
Patch by Marko Kreen  
  
Report by PVS-Studio  
  
Backpatch through 8.4.  

commit   : 234283ecd30a184448b93ca82ec1ae270e44f703    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Apr 2014 13:21:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 16 Apr 2014 13:21:06 -0400    

According to the Single Unix Spec and assorted man pages, you're supposed  
to use the constants named AF_xxx when setting ai_family for a getaddrinfo  
call.  In a few places we were using PF_xxx instead.  Use of PF_xxx  
appears to be an ancient BSD convention that was not adopted by later  
standardization.  On BSD and most later Unixen, it doesn't matter much  
because those constants have equivalent values anyway; but nonetheless  
this code is not per spec.  
  
In the same vein, replace PF_INET by AF_INET in one socket() call, which  
wasn't even consistent with the other socket() call in the same function  
let alone the remainder of our code.  
  
Per investigation of a Cygwin trouble report from Marco Atzeri.  It's  
probably a long shot that this will fix his issue, but it's wrong in  
any case.  

commit   : 96752b02dc9811d3e823da847792919fa76f3cda    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 16 Apr 2014 17:18:02 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 16 Apr 2014 17:18:02 +0200    

Bind attempts to an LDAP server should time out after two seconds,  
allowing additional lines in the service control file to be parsed  
(which provide a fall back to a secondary LDAP server or default options).  
The existing code failed to enforce that timeout during TCP connect,  
resulting in a hang far longer than two seconds if the LDAP server  
does not respond.  
  
Laurenz Albe  

commit   : a86b2dafff7c2061e0d3c9019734afcb5d0d3b7e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 16 Apr 2014 10:45:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 16 Apr 2014 10:45:48 -0400    

Previously, in some places, socket creation errors were checked for  
negative values, which is not true for Windows because sockets are  
unsigned.  This masked socket creation errors on Windows.  
  
Backpatch through 9.0.  8.4 doesn't have the infrastructure to fix this.  

commit   : 79eb0ebd1287a29af186c0c6077da295f7622d4d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 16 Apr 2014 10:21:09 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 16 Apr 2014 10:21:09 +0300    

I mixed up BLCKSZ and XLOG_BLCKSZ when I changed the way the buffer is  
allocated a couple of weeks ago. With the default settings, they are both  
8k, but they can be changed at compile-time.  

commit   : 0c2eb989ea93f3e0ccbbbf39853bcd3e23879603    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Wed, 9 Apr 2014 11:21:46 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Wed, 9 Apr 2014 11:21:46 +0200    

Patches by Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>  
  
Conflicts:  
	src/interfaces/ecpg/test/expected/preproc-outofscope.c  

commit   : d034e9b3be3f9a2a2b85a4cb67f24c246d37f117    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 8 Apr 2014 14:47:24 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 8 Apr 2014 14:47:24 +0300    

Don't reset the rightlink of a page when replaying a page update record.  
This was a leftover from pre-hot standby days, when it was not possible to  
have scans concurrent with WAL replay. Resetting the right-link was not  
necessary back then either, but it was done for the sake of tidiness. But  
with hot standby, it's wrong, because a concurrent scan might still need it.  
  
Backpatch all versions with hot standby, 9.0 and above.  

commit   : 5c26ab659c9a01b86bd40a3f442ac73e999184c5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Apr 2014 18:16:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Apr 2014 18:16:20 -0400    

Formerly, we set up the postmaster's signal handling only when we were  
about to start launching subprocesses.  This is a bad idea though, as  
it means that for example a SIGINT arriving before that will kill the  
postmaster instantly, perhaps leaving lockfiles, socket files, shared  
memory, etc laying about.  We'd rather that such a signal caused orderly  
postmaster termination including releasing of those resources.  A simple  
fix is to move the PostmasterMain stanza that initializes signal handling  
to an earlier point, before we've created any such resources.  Then, an  
early-arriving signal will be blocked until we're ready to deal with it  
in the usual way.  (The only part that really needs to be moved up is  
blocking of signals, but it seems best to keep the signal handler  
installation calls together with that; for one thing this ensures the  
kernel won't drop any signals we wished to get.  The handlers won't get  
invoked in any case until we unblock signals in ServerLoop.)  
  
Per a report from MauMau.  He proposed changing the way "pg_ctl stop"  
works to deal with this, but that'd just be masking one symptom not  
fixing the core issue.  
  
It's been like this since forever, so back-patch to all supported branches.  

commit   : 9500d8f897dbaf6b25374fa45103ebea1325069a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Apr 2014 12:41:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Apr 2014 12:41:38 -0400    

EXEC_BACKEND builds (i.e., Windows) failed to absorb values of PGC_BACKEND  
parameters if they'd been changed post-startup via the config file.  This  
for example prevented log_connections from working if it were turned on  
post-startup.  The mechanism for handling this case has always been a bit  
of a kluge, and it wasn't revisited when we implemented EXEC_BACKEND.  
While in a normal forking environment new backends will inherit the  
postmaster's value of such settings, EXEC_BACKEND backends have to read  
the settings from the CONFIG_EXEC_PARAMS file, and they were mistakenly  
rejecting them.  So this case has always been broken in the Windows port;  
so back-patch to all supported branches.  
  
Amit Kapila  

commit   : 634056567aa7db0b183e9bbb072679bb958c426e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Apr 2014 23:09:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Apr 2014 23:09:49 -0400    

The code segment that removes the old symlink (if present) wasn't clued  
into the fact that on Windows, symlinks are junction points which have  
to be removed with rmdir().  
  
Backpatch to 9.0, where the failing code was introduced.  
  
MauMau, reviewed by Muhammad Asif Naeem and Amit Kapila  

commit   : af7004ed6c0e5b052daee1760bf12179d40166d8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 4 Apr 2014 13:12:38 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 4 Apr 2014 13:12:38 +0300    

If a palloc in a critical section fails, it becomes a PANIC.  

commit   : 0de9963b0b4e692e6c712a7bb1ee0faf61afa9f0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Apr 2014 14:18:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Apr 2014 14:18:45 -0400    

The advice to join to pg_prepared_xacts via the transaction column was not  
updated when the transaction column was replaced by virtualtransaction.  
Since it's not quite obvious how to do that join, give an explicit example.  
For consistency also give an example for the adjacent case of joining to  
pg_stat_activity.  And link-ify the view references too, just because we  
can.  Per bug #9840 from Alexey Bashtanov.  
  
Michael Paquier and Tom Lane  

commit   : 640c0d20a17a0fcfc634b07319841727135b383a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Apr 2014 11:05:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Apr 2014 11:05:55 -0400    

It's been 16 bytes, not 12, for ages.  This was fixed in passing in HEAD  
(commit 146604ec), but as a factual error it should have been back-patched.  
Per gripe from Tatsuhito Kasahara.  

commit   : a8365a2d2f6461350f3986c184bfec6d94901c9d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 29 Mar 2014 03:12:00 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 29 Mar 2014 03:12:00 -0400    

About half of the buildfarm members use too-long directory names,  
strongly suggesting that this approach is a dead end.  

commit   : 8cade31dc590a93ce0a34fa1fe143ca00ff3ebbd    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 29 Mar 2014 00:52:56 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 29 Mar 2014 00:52:56 -0400    

Any OS user able to access the socket can connect as the bootstrap  
superuser and in turn execute arbitrary code as the OS user running the  
test.  Protect against that by placing the socket in the temporary data  
directory, which has mode 0700 thanks to initdb.  Back-patch to 8.4 (all  
supported versions).  The hazard remains wherever the temporary cluster  
accepts TCP connections, notably on Windows.  
  
Attempts to run "make check" from a directory with a long name will now  
fail.  An alternative not sharing that problem was to place the socket  
in a subdirectory of /tmp, but that is only secure if /tmp is sticky.  
The PG_REGRESS_SOCK_DIR environment variable is available as a  
workaround when testing from long directory paths.  
  
As a convenient side effect, this lets testing proceed smoothly in  
builds that override DEFAULT_PGSOCKET_DIR.  Popular non-default values  
like /var/run/postgresql are often unwritable to the build user.  
  
Security: CVE-2014-0067  

commit   : 2fa4243b44416e4de8617ff82d4cbc50e115a3c6    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 29 Mar 2014 00:52:31 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 29 Mar 2014 00:52:31 -0400    

Back-patch to 8.4 (all supported versions).  

commit   : 5b668ac7bef08d67e5cd78ec8854e67f42b49392    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 26 Mar 2014 16:41:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 26 Mar 2014 16:41:44 -0400    

We must increment the refcount on "plntup" as soon as we have the  
reference, not sometime later.  Otherwise, if an error is thrown in  
between, the Py_XDECREF(plntup) call in the PG_CATCH block removes a  
refcount we didn't add, allowing the object to be freed even though  
it's still part of the plpython function's parsetree.  
  
This appears to be the cause of crashes seen on buildfarm member  
prairiedog.  It's a bit surprising that we've not seen it fail repeatably  
before, considering that the regression tests have been exercising the  
faulty code path since 2009.  
  
The real-world impact is probably minimal, since it's unlikely anyone would  
be provoking the "TD["new"] is not a dictionary" error in production, and  
that's the only case that is actually wrong.  Still, it's a bug affecting  
the regression tests, so patch all supported branches.  
  
In passing, remove dead variable "plstr", and demote "platt" to a local  
variable inside the PG_TRY block, since we don't need to clean it up  
in the PG_CATCH path.  

commit   : 0af5fd82e0ca4f61875f5e02aa868b4cea43ae40    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 26 Mar 2014 02:12:39 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 26 Mar 2014 02:12:39 +0900    

Backpatch to 9.0 where XLOG_PARAMETER_CHANGE record was instroduced.  

commit   : 4859a710ea9b26e38a9637301f1259f6123e4de7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Mar 2014 13:45:11 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 21 Mar 2014 13:45:11 -0400    

Clear errno before calling readdir() and handle old MinGW errno bug  
while adding full test coverage for readdir/closedir failures.  
  
Backpatch through 8.4.