PostgreSQL 9.2.1 commit log

commit   : e0327d103013c41c83f41a05187b90956b38c5b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2012 17:47:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Sep 2012 17:47:58 -0400    

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

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

These calls were removed in commit 4240e429d0c2d889d0cda23c618f94e12c13ade7  
as part of a general refactoring and improvement of DDL locking.  However,  
there's a problem not solved by the rewrite, which is that GRANT/REVOKE  
update pg_class.relacl without taking any particular lock on the target  
table as such.  If another backend fails to do AcceptInvalidationMessages,  
it won't notice a recently-committed change in ACLs.  Bug #7557 from Piotr  
Czachur demonstrates that there's at least one code path in 9.2.0 in which  
a command fails to do any AcceptInvalidationMessages calls at all, if the  
current transaction already holds all the locks it will need.  
  
Since we're hard up against the release deadline for 9.2.1, fix this by  
putting back the AcceptInvalidationMessages calls in heap_openrv and  
heap_openrv_extended, thereby restoring the historical behavior in this  
area.  We ought to look for a more elegant and perhaps more bulletproof  
solution, but there's no time for that right now.  

commit   : 67641fb880e8d41ece7ee9513a428ad10b17ddc5    
  
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   : 1ff194fd681df0d0df3487dcf5480b2db55a7c0e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 19 Sep 2012 00:03:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 19 Sep 2012 00:03:00 -0400    

commit   : c6e158873dadd6c78bc97efe9f180ed78dd22308    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 18 Sep 2012 21:53:34 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 18 Sep 2012 21:53:34 -0400    

It is no longer used, but was still being checked for.  
  
bug #7548 from Reinhard Max  

commit   : 3cccc6990b66265ad7c4bfbe5789ce571a39d876    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Sep 2012 12:20:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Sep 2012 12:20:43 -0400    

In commit 9e8da0f75731aaa7605cf4656c21ea09e84d2eb1, I improved btree  
to handle ScalarArrayOpExpr quals natively, so that constructs like  
"indexedcol IN (list)" could be supported by index-only scans.  Using  
such a qual results in multiple scans of the index, under-the-hood.  
I went to some lengths to ensure that this still produces rows in index  
order ... but I failed to recognize that if a higher-order index column  
is lacking an equality constraint, rescans can produce out-of-order  
data from that column.  Tweak the planner to not expect sorted output  
in that case.  Per trouble report from Robert McGehee.  

commit   : 66762ce5fa9f2e82003208e4deba465f438e8505    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Sep 2012 00:31:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Sep 2012 00:31:45 -0400    

Not sure how we missed this case, but we did.  Per bug #7551 from  
Diego de Lima.  

commit   : 634d80ab2a61d8c29ce763018bd8790dffcb2bd6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2012 14:59:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Sep 2012 14:59:35 -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   : 4e54ae66a5a4ff3b3cdd2a2642a0180d6f8226a0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Sep 2012 17:57:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Sep 2012 17:57:26 -0400    

Some experimentation with examples similar to bug #7539 has convinced me  
that indxpath.c's original implementation of parameterized-path generation  
was several bricks shy of a load.  In general, if we are relying on a  
particular outer rel or set of outer rels for a parameterized path, the  
path should use every indexable join clause that's available from that rel  
or rels.  Any join clauses that get left out of the indexqual will end up  
getting applied as plain filter quals (qpquals), and that's generally a  
significant loser compared to having the index AM enforce them.  (This is  
particularly true with btree, which can skip the index scan entirely if  
it can see that the given indexquals are mutually contradictory.)  The  
original heuristics failed to ensure this, though, and were overly  
complicated anyway.  Rewrite to make the code explicitly identify each  
useful set of outer rels and then select all applicable join clauses for  
each one.  The one plan that changes in the regression tests is in fact  
for the better according to the planner's cost estimates.  
  
(Note: this is not a correctness issue but just a matter of plan quality.  
I don't yet know what is going on in bug #7539, but I don't expect this  
change to fix that.)  

commit   : 9c855045809362f2cdabc110afd6ab8a4b250507    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sun, 16 Sep 2012 19:54:34 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sun, 16 Sep 2012 19:54:34 +0100    

Bug spotted by Andres Freund, patch by me.  

commit   : fa41f294f6c93af78e08b3cbb976586a6804c8f4    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 16 Sep 2012 12:19:37 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 16 Sep 2012 12:19:37 -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   : 97d8ad170f7a118ed1237b00e6140ec892c11c89    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Sep 2012 11:50:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Sep 2012 11:50:02 -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   : eb6e9b5ea4a5e733da705c053906f3aff47c9bf5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 14 Sep 2012 09:35:07 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 14 Sep 2012 09:35:07 -0400    

This can result in buffers failing to be properly flushed at  
checkpoint time, leading to data loss.  
  
Report, diagnosis, and patch by Jeff Davis.  

commit   : 269dbaf7076c96b3301abb7571fde42e183bf363    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Sep 2012 11:31:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Sep 2012 11:31:47 -0400    

In commit 1bc16a946008a7cbb33a9a06a7c6765a807d7f59 I added a minor  
optimization to drop the component variables of a GROUP BY expression from  
the target list computed at the aggregation level of a query, if those Vars  
weren't referenced elsewhere in the tlist.  However, I overlooked that the  
window-function planning code would deconstruct such expressions and thus  
need to have access to their component variables.  Fix it to not do that.  
  
While at it, I removed the distinction between volatile and nonvolatile  
window partition/order expressions: the code now computes all of them  
at the aggregation level.  This saves a relatively expensive check for  
volatility, and it's unclear that the resulting plan isn't better anyway.  
  
Per bug #7535 from Louis-David Mitterrand.  Back-patch to 9.2.  

commit   : adff00ad06c60419bb3cf282190d94ddf78d6db1    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 12 Sep 2012 22:33:30 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 12 Sep 2012 22:33:30 -0500    

Backpatch to 9.2.  
  
Etsuro Fujit  

commit   : 819c4129ca39a478700eb1db3c1fb6f2aaedab79    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Sep 2012 15:12:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Sep 2012 15:12:24 -0400    

commit   : 1bfd760c4fa973e54060b4cb0a0f31444300b5ca    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 12 Sep 2012 14:28:10 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 12 Sep 2012 14:28:10 -0400    

Backpatch to 9.2.  

commit   : 8a93fb0a852d6962b9e51bee22c2d7ff8f2b9e0b    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 12 Sep 2012 07:39:07 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 12 Sep 2012 07:39:07 -0500    

Dan Scott  
  
Backpatch original commit 4bc0d2e2cfa8ac523524dccf6f849989c6739083  
to 9.1  

commit   : 31f1b2090fc08f923e56e2421086ef60d6b89c1e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Sep 2012 21:23:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Sep 2012 21:23:20 -0400    

I made multiple errors in commit 97532f7c29468010b87e40a04f8daa3eb097f654,  
stemming mostly from failure to think about the available frequency data  
as being element frequencies not value frequencies (so that occurrences of  
different elements are not mutually exclusive).  This led to sillinesses  
such as estimating that "word" would match more rows than "word:*".  
  
The choice to clamp to a minimum estimate of DEFAULT_TS_MATCH_SEL also  
seems pretty ill-considered in hindsight, as it would frequently result in  
an estimate much larger than the available data suggests.  We do need some  
sort of clamp, since a pattern not matching any of the MCELEMs probably  
still needs a selectivity estimate of more than zero.  I chose instead to  
clamp to at least what a non-MCELEM word would be estimated as, preserving  
the property that "word:*" doesn't get an estimate less than plain "word",  
whether or not the word appears in MCELEM.  
  
Per investigation of a gripe from Bill Martin, though I suspect that his  
example case actually isn't even reaching the erroneous code.  
  
Back-patch to 9.1 where this code was introduced.  

commit   : 4c25df55fdf4f0be071d0974e0e5732580807881    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 10 Sep 2012 12:51:24 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 10 Sep 2012 12:51:24 -0400    

This follows recent addition of Windows/Mingw testing.  
Backpatch to Release 9.2 so we can get some buildfarm testing  
going.  

commit   : 81ead89ee152e5381aec0cf7352e5fa131a6c336    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Sep 2012 20:32:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Sep 2012 20:32:59 -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   : af3de2d19ec65216737192b8cdd948331c3f2e80    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Sep 2012 15:08:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Sep 2012 15:08:32 -0400    

Investigation shows that some intermittent build failures in ecpg are the  
result of a gmake bug that was reported quite some time ago:  
http://savannah.gnu.org/bugs/?30653  
  
Preventing parallel builds of the ecpg subdirectories seems to dodge the  
bug.  Per yesterday's pgsql-hackers discussion, there are some other things  
in the subdirectory makefiles that seem rather unsafe for parallel builds  
too, but there's little point in fixing them as long as we have to work  
around a make bug.  
  
Back-patch to 9.1; parallel builds weren't very well supported before  
that anyway.  

commit   : 770556d6c69c4edf219d4ace2e4fb29a1f2c35df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 Sep 2012 17:39:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 8 Sep 2012 17:39:02 -0400    

Commit 2cfb1c6f77734db81b6e74bcae630f93b94f69be fixed some issues caused  
by Python 3.3 choosing to iterate through dict entries in a different order  
than before.  But here's another one: the test cases adjusted here made two  
bad entries in a dict and expected the one complained of would always be  
the same.  
  
Possibly this should be back-patched further than 9.2, but there seems  
little point unless the earlier fix is too.  

commit   : 6c8656409bdded1d549bcd544a1c5c5e99701351    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2012 20:38:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Sep 2012 20:38:28 -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.