Stamp 9.2.1.
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
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc
Update release notes for 9.2.1, 9.1.6, 9.0.10, 8.4.14, 8.3.21.
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
M doc/src/sgml/release-8.3.sgml
M doc/src/sgml/release-8.4.sgml
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
Put back AcceptInvalidationMessages calls in heap_openrv(_extended).
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.
M src/backend/access/heap/heapam.c
Update time zone data files to tzdata release 2012f.
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.
M src/timezone/data/australasia
Translation updates
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
M src/bin/scripts/po/fr.po
pg_upgrade: Remove check for pg_config
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
M contrib/pg_upgrade/exec.c
Fix planning of btree index scans using ScalarArrayOpExpr quals.
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.
M src/backend/optimizer/path/indxpath.c
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Fix array_typanalyze to work for domains over arrays.
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.
M src/backend/utils/adt/array_typanalyze.c
Provide adequate documentation of the "table_name *" notation.
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.
M doc/src/sgml/config.sgml
M doc/src/sgml/ddl.sgml
M doc/src/sgml/queries.sgml
M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/ref/delete.sgml
M doc/src/sgml/ref/lock.sgml
M doc/src/sgml/ref/select.sgml
M doc/src/sgml/ref/truncate.sgml
M doc/src/sgml/ref/update.sgml
Rethink heuristics for choosing index quals for parameterized paths.
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.)
M src/backend/optimizer/path/indxpath.c
M src/test/regress/expected/join.out
Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown checkpoint. Recovery code documents clearly that a shutdown checkpoint is executed at end of recovery - a shutdown checkpoint WAL record is written but the buffer manager had been altered to treat end of recovery as a normal checkpoint. This bug exacerbates the bufmgr relpersistence bug.
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.
M src/backend/storage/buffer/bufmgr.c
Fix documentation reference to maximum allowed for autovacuum_freeze_max_age.
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.
M doc/src/sgml/maintenance.sgml
Back-patch fix and test case for bug #7516.
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.)
M src/pl/plperl/expected/plperl_elog.out
M src/pl/plperl/plperl.c
M src/pl/plperl/sql/plperl_elog.sql
Properly set relpersistence for fake relcache entries.
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.
M src/backend/access/transam/xlogutils.c
M src/backend/storage/buffer/bufmgr.c
Fix case of window function + aggregate + GROUP BY expression.
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.
M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/window.out
M src/test/regress/sql/window.sql
Fix typo in comment for pclose_check() function.
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
M src/port/exec.c
Fix a couple other leftover uses of 'conisonly' terminology.
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
M src/backend/commands/typecmds.c
M src/include/catalog/pg_constraint.h
Fix catalog docs to reflect connoinherit change in 09ff76f.
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.
M doc/src/sgml/catalogs.sgml
Fix typo: lexemes misspelled in full text search docs.
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
M doc/src/sgml/textsearch.sgml
Fix logical errors in tsquery selectivity estimation for prefix queries.
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.
M src/backend/tsearch/ts_selfuncs.c
Add vcregress.pl target for checking pg_upgrade.
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.
M src/tools/msvc/Install.pm
M src/tools/msvc/vcregress.pl
Make plperl safe against functions that are redefined while running.
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.
M src/pl/plperl/expected/plperl.out
M src/pl/plperl/plperl.c
M src/pl/plperl/sql/plperl.sql
Use .NOTPARALLEL in ecpg/Makefile to avoid a gmake parallelism bug.
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.
M src/interfaces/ecpg/Makefile
Adjust PL/Python regression tests some more for Python 3.3.
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.
M src/pl/plpython/expected/plpython_trigger.out
M src/pl/plpython/sql/plpython_trigger.sql
Fix PARAM_EXEC assignment mechanism to be safe in the presence of WITH.
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.
M src/backend/nodes/outfuncs.c
M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/plan/subselect.c
M src/backend/optimizer/prep/prepjointree.c
M src/backend/optimizer/prep/prepunion.c
M src/include/nodes/relation.h
M src/test/regress/expected/with.out
M src/test/regress/sql/with.sql