PostgreSQL 9.0.3 commit log

Tag 9.0.3

  
commit   : 2fb64d857003c91378ba86b03d753a63ebee95b2    
  
author   : Marc G. Fournier <scrappy@hub.org>    
date     : Thu, 27 Jan 2011 22:21:31 -0400    
  
committer: Marc G. Fournier <scrappy@hub.org>    
date     : Thu, 27 Jan 2011 22:21:31 -0400    

Click here for diff

  
  

Update release notes.

  
commit   : aefb8d9198926e9f7717d6420b802ae4b6352293    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jan 2011 17:45:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jan 2011 17:45:42 -0500    

Click here for diff

  
Security: CVE-2010-4015  
  

Prevent buffer overrun while parsing an integer in a “query_int” value.

  
commit   : d6d145673f8df3bd05939b1781e99acead9daae5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jan 2011 17:41:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jan 2011 17:41:46 -0500    

Click here for diff

  
contrib/intarray's gettoken() uses a fixed-size buffer to collect an  
integer's digits, and did not guard against overrunning the buffer.  
This is at least a backend crash risk, and in principle might allow  
arbitrary code execution.  The code didn't check for overflow of the  
integer value either, which while not presenting a crash risk was still  
bad.  
  
Thanks to Apple Inc's security team for reporting this issue and supplying  
the fix.  
  
Security: CVE-2010-4015  
  

Don’t include unnecessarily.

  
commit   : 67dbe720f6ba18393cd85574718aa2683b77a212    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jan 2011 16:27:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jan 2011 16:27:27 -0500    

Click here for diff

  
We only need that header when compiling with icc, since the gcc variant of  
ia64_get_bsp() uses in-line assembly code.  Per report from Frank Brendel,  
the header doesn't exist on all IA64 platforms; so don't include it unless  
we need it.  
  

Translation updates for release 9.0.3

  
commit   : 7f2d75408b63fab9cc613b3d60d057f6d3ec3adc    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 27 Jan 2011 21:25:25 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 27 Jan 2011 21:25:25 +0200    

Click here for diff

  
  

Update release notes for releases 9.0.3, 8.4.7, 8.3.14, and 8.2.20.

  
commit   : af9e2ed29b51e08e5cc597ddc8d58cde05d83212    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jan 2011 16:09:51 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jan 2011 16:09:51 -0500    

Click here for diff

  
  

Correct ALTER TYPE -> SET DATA TYPE in ALTER TABLE documentation.

  
commit   : 2c3e29299842f6de74ff96d35ecaa1cc98fbcd5d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 25 Jan 2011 18:50:35 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 25 Jan 2011 18:50:35 -0500    

Click here for diff

  
The latter is the correct name of the operation to change the data type  
of a column.  
  
Noah Misch  
  

Make ALTER TABLE revalidate uniqueness and exclusion constraints.

  
commit   : 39b5e5f3370258cae843e8cc83eccd59ddb532dd    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 20 Jan 2011 22:44:10 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 20 Jan 2011 22:44:10 -0500    

Click here for diff

  
Failure to do so can lead to constraint violations.  This was broken by  
commit 1ddc2703a936d03953657f43345460b9242bbed1 on 2010-02-07, so  
back-patch to 9.0.  
  
Noah Misch.  Regression test by me.  
  

Document that WITH queries are also called Common Table Expressions.

  
commit   : ba3afc88d2b81fc609cda8504ee7b54c54b379d7    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 19 Jan 2011 21:21:33 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 19 Jan 2011 21:21:33 -0500    

Click here for diff

  
Peter Geoghegan, reviewed by Stephen Frost  
  

Fix miscalculation of itemsafter in array_set_slice().

  
commit   : d8b0495f9637636b8a89e3b98208beb0a2d64fd0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Jan 2011 12:38:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Jan 2011 12:38:52 -0500    

Click here for diff

  
If the slice to be assigned to was before the existing array lower bound  
(requiring at least one null element to spring into existence to fill the  
gap), the code miscalculated how many entries needed to be copied from  
the old array's null bitmap.  This could result in trashing the array's  
data area (as seen in bug #5840 from Karsten Loesing), or worse.  
  
This has been broken since we first allowed the behavior of assigning to  
non-adjacent slices, in 8.2.  Back-patch to all affected versions.  
  

Increment Py_None refcount for NULL array elements

  
commit   : 051096d06ece0c553e8ed85bfe45129f488a806d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 17 Jan 2011 13:01:04 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 17 Jan 2011 13:01:04 -0300    

Click here for diff

  
Per bug #5835 by Julien Demoor  
Author: Alex Hunsaker  
  

Before exiting walreceiver, fsync() all the WAL received.

  
commit   : 1435a8554cd514d668a46c4f6b1e4a1e3bd30fd5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 17 Jan 2011 12:22:24 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 17 Jan 2011 12:22:24 +0200    

Click here for diff

  
Otherwise WAL recovery will replay the un-flushed WAL after walreceiver has  
exited, which can lead to a non-recoverable standby if the system crashes hard  
at that point.  
  

Fix the logic in libpqrcv_receive() to determine if there’s any incoming data that can be read without blocking. It used to conclude that there isn’t, even though there was data in the socket receive buffer. That lead walreceiver to flush the WAL after every received chunk, potentially causing big performance issues.

  
commit   : a08363d70cb51f361c9525384e9f46a252fcd92e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 13 Jan 2011 17:51:28 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 13 Jan 2011 17:51:28 +0200    

Click here for diff

  
Backpatch to 9.0, because the performance impact can be very significant.  
  

Fix PlanRowMark/ExecRowMark structures to handle inheritance correctly.

  
commit   : fed8dcdb84d255088d22efa3156a193f3399e792    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jan 2011 20:47:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Jan 2011 20:47:09 -0500    

Click here for diff

  
In an inherited UPDATE/DELETE, each target table has its own subplan,  
because it might have a column set different from other targets.  This  
means that the resjunk columns we add to support EvalPlanQual might be  
at different physical column numbers in each subplan.  The EvalPlanQual  
rewrite I did for 9.0 failed to account for this, resulting in possible  
misbehavior or even crashes during concurrent updates to the same row,  
as seen in a recent report from Gordon Shannon.  Revise the data structure  
so that we track resjunk column numbers separately for each subplan.  
  
I also chose to move responsibility for identifying the physical column  
numbers back to executor startup, instead of assuming that numbers derived  
during preprocess_targetlist would stay valid throughout subsequent  
massaging of the plan.  That's a bit slower, so we might want to consider  
undoing it someday; but it would complicate the patch considerably and  
didn't seem justifiable in a bug fix that has to be back-patched to 9.0.  
  

Typo fix

  
commit   : a1ed4cf6ca6ee2115d9f618ed7930a97842042a8    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 11 Jan 2011 10:45:16 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 11 Jan 2011 10:45:16 +0100    

Click here for diff

  
Josh Kupershmidt  
  

Ensure the directory for gram.h is created on win32

  
commit   : 628a6b75645d790579ec565f29f94484e92d52bf    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 9 Jan 2011 17:01:15 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 9 Jan 2011 17:01:15 +0100    

Click here for diff

  
Result of bad testing of my last commit.  
  

Properly install gram.h on MSVC builds

  
commit   : 763072ba8fd48dc3b16a14b14220988a8fe07e0e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 9 Jan 2011 15:31:48 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 9 Jan 2011 15:31:48 +0100    

Click here for diff

  
This file is now needed by pgAdmin builds, which started  
failing since it was missing in the installer builds.  
  

In ecpg’s parser removed a fixed length limit for constants defining an array dimension.

  
commit   : 1b2b96c4231f11313f14ded55e25640fb239de31    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Sat, 8 Jan 2011 18:35:37 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Sat, 8 Jan 2011 18:35:37 +0100    

Click here for diff

  
  

Remove bogus claims regarding createuser defaults.

  
commit   : e445f9f8b5509198abe3a27fe2cd92ba3a22379a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Sat, 8 Jan 2011 06:12:05 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Sat, 8 Jan 2011 06:12:05 -0500    

Click here for diff

  
Josh Kupershmidt  
  

Update documentation to say that \lo_import sets :LASTOID, not lo_insert.

  
commit   : 8b3790916dca2455fc915c1923bbc61aa4d87753    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Jan 2011 21:32:13 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 5 Jan 2011 21:32:13 -0500    

Click here for diff

  
  

In pg_upgrade, copy pg_largeobject_metadata and its index for 9.0+ servers because, like pg_largeobject, it is a system table whose contents are not dumped by pg_dump –schema-only.

  
commit   : 9a22ea242b276c9bc1f3eb94f0ce9ffad94e270e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 4 Jan 2011 23:35:52 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 4 Jan 2011 23:35:52 -0500    

Click here for diff

  
  

  
commit   : 845626f506df0518829fe519977f42e02d9c8438    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 4 Jan 2011 21:33:37 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 4 Jan 2011 21:33:37 -0500    

Click here for diff

  
  

Improve pg_upgrade’s checks for required executables.

  
commit   : ee718c23105d7ede1a55e6ac9832b8a54a496ed6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Dec 2010 13:43:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Dec 2010 13:43:58 -0500    

Click here for diff

  
Don't insist on pg_dumpall and psql being present in the old cluster,  
since they are not needed.  Do insist on pg_resetxlog being present  
(in both old and new), since we need it.  Also check for pg_config,  
but only in the new cluster.  Remove the useless attempt to call  
pg_config in the old cluster; we don't need to know the old value of  
--pkglibdir.  (In the case of a stripped-down migration installation  
there might be nothing there to look at anyway, so any future change  
that might reintroduce that need would have to be considered carefully.)  
  
Per my attempts to build a minimal previous-version installation to support  
pg_upgrade.  
  

Avoid unexpected conversion overflow in planner for distant date values.

  
commit   : 0fdf735d977de99551dd4d7910bdc4d75a08608d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Dec 2010 22:49:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Dec 2010 22:49:57 -0500    

Click here for diff

  
The "date" type supports a wider range of dates than int64 timestamps do.  
However, there is pre-int64-timestamp code in the planner that assumes that  
all date values can be converted to timestamp with impunity.  Fortunately,  
what we really need out of the conversion is always a double (float8)  
value; so even when the date is out of timestamp's range it's possible to  
produce a sane answer.  All we need is a code path that doesn't try to  
force the result into int64.  Per trouble report from David Rericha.  
  
Back-patch to all supported versions.  Although this is surely a corner  
case, there's not much point in advertising a date range wider than  
timestamp's if we will choke on such values in unexpected places.  
  

Correct spelling: longjump() -> longjmp().

  
commit   : a45e2e141d5002866f60b6f28f14d00317c106d1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Dec 2010 22:21:50 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Dec 2010 22:21:50 -0500    

Click here for diff

  
  

Fix grammar

  
commit   : 3bb1800b55c8c90e7ef2ed92a5f201e3a85e3036    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 24 Dec 2010 22:08:15 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 24 Dec 2010 22:08:15 +0200    

Click here for diff

  
  

Allow vpath builds and regression tests to succeed on Mingw. Backpatch to release 8.4 - earlier releases would require more changes and it’s not worth the trouble.

  
commit   : 66b133d2b8a09fb468d59c174f9eae689bfc77a5    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 24 Dec 2010 13:31:48 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 24 Dec 2010 13:31:48 -0500    

Click here for diff

  
  

Backpatch to 9.0 a doc mention that a BBU does not prevent partial page writes.

  
commit   : c47458529533bc88e34778818a4ce7d5c309d7a8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 24 Dec 2010 11:32:52 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 24 Dec 2010 11:32:52 -0500    

Click here for diff

  
  

Fix up handling of simple-form CASE with constant test expression.

  
commit   : 554b00cdaba5aac12e53f41214dad4d8a95fc6d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Dec 2010 15:30:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Dec 2010 15:30:44 -0500    

Click here for diff

  
eval_const_expressions() can replace CaseTestExprs with constants when  
the surrounding CASE's test expression is a constant.  This confuses  
ruleutils.c's heuristic for deparsing simple-form CASEs, leading to  
Assert failures or "unexpected CASE WHEN clause" errors.  I had put in  
a hack solution for that years ago (see commit  
514ce7a331c5bea8e55b106d624e55732a002295 of 2006-10-01), but bug #5794  
from Peter Speck shows that that solution failed to cover all cases.  
  
Fortunately, there's a much better way, which came to me upon reflecting  
that Peter's "CASE TRUE WHEN" seemed pretty redundant: we can "simplify"  
the simple-form CASE to the general form of CASE, by simply omitting the  
constant test expression from the rebuilt CASE construct.  This is  
intuitively valid because there is no need for the executor to evaluate  
the test expression at runtime; it will never be referenced, because any  
CaseTestExprs that would have referenced it are now replaced by constants.  
This won't save a whole lot of cycles, since evaluating a Const is pretty  
cheap, but a cycle saved is a cycle earned.  In any case it beats kluging  
ruleutils.c still further.  So this patch improves const-simplification  
and reverts the previous change in ruleutils.c.  
  
Back-patch to all supported branches.  The bug exists in 8.1 too, but it's  
out of warranty.  
  

Fix erroneous parsing of tsquery input “… & !(subexpression) | …”

  
commit   : aebddf00d2a11ed05a9eaadf3823a2e39bfaede1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Dec 2010 12:48:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Dec 2010 12:48:41 -0500    

Click here for diff

  
After parsing a parenthesized subexpression, we must pop all pending  
ANDs and NOTs off the stack, just like the case for a simple operand.  
Per bug #5793.  
  
Also fix clones of this routine in contrib/intarray and contrib/ltree,  
where input of types query_int and ltxtquery had the same problem.  
  
Back-patch to all supported versions.  
  

Document unavailable parameters in some configurations

  
commit   : 8b4d3d44dc7d64aaafd2269d3da8d2873137c691    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sat, 18 Dec 2010 16:30:00 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sat, 18 Dec 2010 16:30:00 +0100    

Click here for diff

  
Add a note to user-facing parameters that can be removed completely  
(and not just empty) by #ifdef's depending on build configuration.  
  

Remove optreset from src/port/ implementations of getopt and getopt_long.

  
commit   : 77451164e9936ac70ffdaca7e7f2c5eb7e148850    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Dec 2010 16:22:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Dec 2010 16:22:12 -0500    

Click here for diff

  
We don't actually need optreset, because we can easily fix the code to  
ensure that it's cleanly restartable after having completed a scan over the  
argv array; which is the only case we need to restart in.  Getting rid of  
it avoids a class of interactions with the system libraries and allows  
reversion of my change of yesterday in postmaster.c and postgres.c.  
  
Back-patch to 8.4.  Before that the getopt code was a bit different anyway.  
  

Fix up getopt() reset management so it works on recent mingw.

  
commit   : 770bddc1b4b59338395185966100056d90e6dcf9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Dec 2010 23:50:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Dec 2010 23:50:49 -0500    

Click here for diff

  
The mingw people don't appear to care about compatibility with non-GNU  
versions of getopt, so force use of our own copy of getopt on Windows.  
Also, ensure that we make use of optreset when using our own copy.  
  
Per report from Andrew Dunstan.  Back-patch to all versions supported  
on Windows.  
  

Fix contrib/seg’s GiST picksplit method.

  
commit   : d45f163251e290c66c144c347482538bdde9d895    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Dec 2010 21:22:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Dec 2010 21:22:38 -0500    

Click here for diff

  
Fix the same size_alpha versus size_beta typo that was recently fixed  
in contrib/cube.  Noted by Alexander Korotkov.  
  
Back-patch to all supported branches (there is a more invasive fix in  
HEAD).