PostgreSQL 9.0.10 commit log

commit   : 22cdae947b8af9624ee4571ef4b1b726a774d128    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2012 17:53:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2012 17:53:08 -0400    

commit   : 605172a7223be2683505992157dae49ce98f3d05    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2012 17:38:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2012 17:38:57 -0400    

commit   : 7a7fe679c5c37156d212afe452b9c34623fe219e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2012 10:44:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2012 10:44:45 -0400    

DST law changes in Fiji.  

commit   : 3682c1cf7c419f2f6aaf831a2d95d76dc7621ec5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 19 Sep 2012 00:05:39 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 19 Sep 2012 00:05:39 -0400    

commit   : b853f33bcbfa3313d003b65d24946dfb04a8ff43    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2012 14:59:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2012 14:59:42 -0400    

Somewhere along the line, somebody decided to remove all trace of this  
notation from the documentation text.  It was still in the command syntax  
synopses, or at least some of them, but with no indication what it meant.  
This will not do, as evidenced by the confusion apparent in bug #7543;  
even if the notation is now unnecessary, people will find it in legacy  
SQL code and need to know what it does.  

commit   : 17ddb7d65b49422a6b6bc153896b4e2350dbda75    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 16 Sep 2012 12:21:12 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 16 Sep 2012 12:21:12 -0500    

The documentation mentioned setting autovacuum_freeze_max_age to  
"its maximum allowed value of a little less than two billion".  
This led to a post asking about the exact maximum allowed value,  
which is precisely two billion, not "a little less".  
  
Based on question by Radovan Jablonovsky.  Backpatch to 8.3.  

commit   : 3d3218aa3d4aa3ef833f60b16548d1e209c778e7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Sep 2012 11:50:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Sep 2012 11:50:10 -0400    

Back-patch commits 9afc6481117d2dd936e752da0424a2b6b05f6459 and  
b8fbbcf37f22c5e8361da939ad0fc4be18a34ca9.  The first of these is really  
a minor code cleanup to save a few cycles, but it turns out to provide  
a workaround for the misoptimization problem described in bug #7516.  
The second commit adds a regression test case.  
  
Back-patch the fix to all active branches.  The test case only works  
as far back as 9.0, because it relies on plpgsql which isn't installed  
by default before that.  (I didn't have success modifying it into an  
all-plperl form that still provoked a crash, though this may just reflect  
my lack of Perl-fu.)  

commit   : 0952811c86ad64d016d91ced0d8f2a78ce3acda2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Sep 2012 20:33:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Sep 2012 20:33:06 -0400    

validate_plperl_function() supposed that it could free an old  
plperl_proc_desc struct immediately upon detecting that it was stale.  
However, if a plperl function is called recursively, this could result  
in deleting the struct out from under an outer invocation, leading to  
misbehavior or crashes.  Add a simple reference-count mechanism to  
ensure that such structs are freed only when the last reference goes  
away.  
  
Per investigation of bug #7516 from Marko Tiikkaja.  I am not certain  
that this error explains his report, because he says he didn't have  
any recursive calls --- but it's hard to see how else it could have  
crashed right there.  In any case, this definitely fixes some problems  
in the area.  
  
Back-patch to all active branches.  

commit   : 25b6df1e35190270b2cd04fd3beec7fed8441829    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2012 20:38:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2012 20:38:42 -0400    

The planner previously assumed that parameter Vars having the same absolute  
query level, varno, and varattno could safely be assigned the same runtime  
PARAM_EXEC slot, even though they might be different Vars appearing in  
different subqueries.  This was (probably) safe before the introduction of  
CTEs, but the lazy-evalution mechanism used for CTEs means that a CTE can  
be executed during execution of some other subquery, causing the lifespan  
of Params at the same syntactic nesting level as the CTE to overlap with  
use of the same slots inside the CTE.  In 9.1 we created additional hazards  
by using the same parameter-assignment technology for nestloop inner scan  
parameters, but it was broken before that, as illustrated by the added  
regression test.  
  
To fix, restructure the planner's management of PlannerParamItems so that  
items having different semantic lifespans are kept rigorously separated.  
This will probably result in complex queries using more runtime PARAM_EXEC  
slots than before, but the slots are cheap enough that this hardly matters.  
Also, stop generating PlannerParamItems containing Params for subquery  
outputs: all we really need to do is reserve the PARAM_EXEC slot number,  
and that now only takes incrementing a counter.  The planning code is  
simpler and probably faster than before, as well as being more correct.  
  
Per report from Vik Reykja.  
  
Back-patch of commit 46c508fbcf98ac334f1e831d21021d731c882fbb into all  
branches that support WITH.  

commit   : 83f2584f15d9450834f3b3d5e4a2edaa7c00dc60    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 6 Sep 2012 15:43:46 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 6 Sep 2012 15:43:46 -0400    

This affects initdb, clusterdb, reindexdb, and vacuumdb in master  
and 9.2; in earlier branches, only initdb is affected.  

commit   : 987277f402a31ba91ea647d115785e5a4f7850fa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 21:49:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 21:49:18 -0400    

Give the correct name of the GUC parameter being complained of.  
Also, emit a more suitable SQLSTATE (INVALID_PARAMETER_VALUE,  
not the default INTERNAL_ERROR).  
  
Gurjeet Singh, errcode adjustment by me  

commit   : f7b13e48375a5a8ea2a8b157622a9310512f4e27    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 5 Sep 2012 17:49:30 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 5 Sep 2012 17:49:30 -0400    

pg_upgrade opened the output from pg_dumpall in text mode and  
wrote the split files in text mode. This caused unwanted eating  
of intended carriage returns on input and production of spurious  
carriage returns on output. To avoid this, open all these files  
in binary mode. On non-Windows platforms, this change has no  
effect.  
  
Backpatch to 9.0. On 9.0 and 9.1, we also switch from redirecting  
pg_dumpall's output to using pg_dumpall's -f switch, for the same  
reason.  

commit   : a05fa36ccf0dc7d6846564096d05b7c9bb86df45    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 16:43:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Sep 2012 16:43:48 -0400    

Perl, for some unaccountable reason, believes it's a good idea to reset  
SIGFPE handling to SIG_IGN.  Which wouldn't be a good idea even if it  
worked; but on some platforms (Linux at least) it doesn't work at all,  
instead resulting in forced process termination if the signal occurs.  
Given the lack of other complaints, it seems safe to assume that Perl  
never actually provokes SIGFPE and so there is no value in the setting  
anyway.  Hence, reset it to our normal handler after initializing Perl.  
  
Report, analysis and patch by Andres Freund.  

commit   : e62ad18663f0fcc37f9b4628bd244398b61aee67    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 22:51:13 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 22:51:13 -0400    

commit   : 4397c51816cbb918fc3aebc474dd53bc231502b9    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 18:14:06 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Sep 2012 18:14:06 -0400    

pg_upgrade produces a platform-specific script to remove the old  
directory, but on Windows it has not been making sure that the  
paths it writes as arguments for rmdir and del use the backslash  
path separator, which will cause these scripts to fail.  
  
The fix is backpatched to Release 9.0.  

commit   : 1da2a610d7e791e93fcf835855badaeb11196bdd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Aug 2012 23:48:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Aug 2012 23:48:01 -0400    

This back-ports commits c8ba697a4bdb934f0c51424c654e8db6133ea255 and  
e5db11c5582b469c04a11f217a0f32c827da5dd7, which fix one definite and one  
speculative bug in gistchoose, and make the code a lot more intelligible as  
well.  In 9.2 only, this also affects the largely-copied-and-pasted logic  
in gistRelocateBuildBuffersOnSplit.  
  
The impact of the bugs was that the functions might make poor decisions  
as to which index tree branch to push a new entry down into, resulting in  
GiST index bloat and poor performance.  The fixes rectify these decisions  
for future insertions, but a REINDEX would be needed to clean up any  
existing index bloat.  
  
Alexander Korotkov, Robert Haas, Tom Lane  

commit   : 4fb505dff4fbf3b4661f20ec9cf00812b8ee9a2e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Aug 2012 14:14:22 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Aug 2012 14:14:22 -0400    

The existing documentation in Linux Memory Overcommit seemed to  
assume that PostgreSQL itself could never be the problem, or at  
least it didn't tell you what to do about it.  
  
Per discussion with Craig Ringer and Kevin Grittner.  

commit   : 841ea92cba59bea8b8c9eda35960a673851dde98    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Aug 2012 13:26:45 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Aug 2012 13:26:45 -0400    

Per note from Peter Eisentraut.  

commit   : bf3b85c6bed2e6b2c104c21d18e78bdb3bcdfb06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Aug 2012 17:25:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Aug 2012 17:25:28 -0400    

If we revoke a grant option from some role X, but X still holds the option  
via another grant, we should not recursively revoke the privilege from  
role(s) Y that X had granted it to.  This was supposedly fixed as one  
aspect of commit 4b2dafcc0b1a579ef5daaa2728223006d1ff98e9, but I must not  
have tested it, because in fact that code never worked: it forgot to shift  
the grant-option bits back over when masking the bits being revoked.  
  
Per bug #6728 from Daniel German.  Back-patch to all active branches,  
since this has been wrong since 8.0.  

commit   : d17cf76bed16029bc930fbf4094d8e8112e22aa7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2012 19:01:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Aug 2012 19:01:34 -0400    

The previous coding essentially assumed that nodes would be rescanned in  
the same order they were initialized in; or at least that the "leader" of  
a group of CTEscans would be rescanned before any others were required to  
execute.  Unfortunately, that isn't even a little bit true.  It's possible  
to devise queries in which the leader isn't rescanned until other CTEscans  
on the same CTE have run to completion, or even in which the leader never  
gets a rescan call at all.  
  
The fix makes the leader specially responsible only for initial creation  
and final destruction of the tuplestore; rescan resets are now a  
symmetrically shared responsibility.  This means that we might reset the  
tuplestore multiple times when restarting a plan subtree containing  
multiple CTEscans; but resetting an already-empty tuplestore is cheap  
enough that that doesn't seem like a problem.  
  
Per report from Adam Mackler; the new regression test cases are based on  
his example query.  
  
Back-patch to 8.4 where CTE scans were introduced.