PostgreSQL 9.1.0 commit log

commit   : 1f43001424a9da624a89b213d0be606a8212a50a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Sep 2011 17:13:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Sep 2011 17:13:27 -0400    

commit   : bd6db68f714d8e4609c0b22425590ab632a14812    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Sep 2011 23:10:40 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Sep 2011 23:10:40 +0300    

commit   : ba7ef09a3bb49e38fda0b872bf85e46421c251d3    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Sep 2011 22:09:08 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Sep 2011 22:09:08 +0300    

commit   : c7d60312fb661cdb212c63924249d623bd9d87c6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Sep 2011 00:53:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 Sep 2011 00:53:11 -0400    

Also set the documented release date to 2011-09-12.  

commit   : 5df20a6e4f5eee5eef1b28760ceca604f57d535b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Sep 2011 17:06:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Sep 2011 17:06:19 -0400    

Trailing-zero stripping applied by the FM specifier could strip zeroes  
to the left of the decimal point, for a format with no digit positions  
after the decimal point (such as "FM999.").  
  
Reported and diagnosed by Marti Raudsepp, though I didn't use his patch.  

commit   : 60765d86c3a91bf2fdf796ee66672120fd599d02    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Sep 2011 15:43:52 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Sep 2011 15:43:52 -0400    

Backpatch to 9.1.  
  
By Hiroshi Saito  

commit   : 8cdd62068d2b6913902741f2fbc74d51042c3d3e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Sep 2011 14:42:36 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Sep 2011 14:42:36 -0400    

Backpatch to 9.0 and 9.1.  
  
Report by depesz, diagnosis by Tom.  

commit   : 673dfe9690a54889bdb434321552f227806209fa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Sep 2011 13:29:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Sep 2011 13:29:26 -0400    

Per Euler Taveira de Oliveira.  

commit   : 90398132417232cb56dcda53a4cb66ed2d579681    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Sep 2011 13:01:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Sep 2011 13:01:15 -0400    

With 9.1's use of Params to pass down values from NestLoop join nodes  
to their inner plans, it is possible for a Param to have type RECORD, in  
which case the set of fields comprising the value isn't determinable by  
inspection of the Param alone.  However, just as with a Var of type RECORD,  
we can find out what we need to know if we can locate the expression that  
the Param represents.  We already knew how to do this in get_parameter(),  
but I'd overlooked the need to be able to cope in get_name_for_var_field(),  
which led to EXPLAIN failing with "record type has not been registered".  
  
To fix, refactor the search code in get_parameter() so it can be used by  
both functions.  
  
Per report from Marti Raudsepp.  

commit   : d5d94e16011a4fbb52de13a3d1ca326ad0c4ff36    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Sep 2011 09:24:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 7 Sep 2011 09:24:02 -0400    

Backpatch to 9.0 and 9.1.  
  
Patch from Josh Kupershmidt.  

commit   : e4d59f35366964298b0c9d4847f0a7efd3ddf830    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Sep 2011 22:54:18 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Sep 2011 22:54:18 -0400    

Backpatch to 9.0 and 9.1.  
  
Report from Pavel Stehule, patch from Josh Kupershmidt  

commit   : 6117526b5bf17dc22812ca8aa958a40c8edfc8a2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Sep 2011 19:42:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Sep 2011 19:42:48 -0400    

Per Peter.  

commit   : 2b3e86d4756ac5480058e71caaed9fa58a644d35    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Sep 2011 17:32:16 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Sep 2011 17:32:16 -0400    

Backpatch to 9.1.  

commit   : 3430ab5986e5d402f7ada7c672a51f679b60c95c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Sep 2011 15:20:16 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Sep 2011 15:20:16 -0400    

Backpatch to 9.0 and 9.1.  

commit   : 8b81b99b89de186aeda9baabf4e1b6bd792d54b9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Sep 2011 14:50:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Sep 2011 14:50:28 -0400    

The code in shift_jis_20042euc_jis_2004() would fetch two bytes even when  
only one remained in the string.  Since conversion functions aren't  
supposed to assume null-terminated input, this poses a small risk of  
fetching past the end of memory and incurring SIGSEGV.  No such crash has  
been identified in the field, but we've certainly seen the equivalent  
happen in other code paths, so patch this one all the way back.  
  
Report and patch by Noah Misch.  

commit   : 460bfd07b38f6495314c01499fca49f5f4a68a38    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Sep 2011 14:35:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Sep 2011 14:35:27 -0400    

Since the last couple of columns of pg_type are often NULL,  
sizeof(FormData_pg_type) can be an overestimate of the actual size of the  
tuple data part.  Therefore memcpy'ing that much out of the catalog cache,  
as analyze.c was doing, poses a small risk of copying past the end of  
memory and incurring SIGSEGV.  No such crash has been identified in the  
field, but we've certainly seen the equivalent happen in other code paths,  
so patch this one all the way back.  
  
Per valgrind testing by Noah Misch, though this is not his proposed patch.  
I chose to use SearchSysCacheCopy1 rather than inventing special-purpose  
infrastructure for copying only the minimal part of a pg_type tuple.  

commit   : 94bf47db8ffc13005d9b14ec3331f6db94a91d46    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Sep 2011 13:41:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Sep 2011 13:41:30 -0400    

Backpatch to 9.0 and 9.1.  
  
Report from depstein@alliedtesting.com.  

commit   : a3850a5f7582ebe328d2506873e31aac2b01d51b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Sep 2011 12:36:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Sep 2011 12:36:40 -0400    

We've now seen more than one gripe from somebody who didn't get the memo  
about how to install contrib modules in 9.1.  Try to make it a little more  
prominent that you aren't supposed to call the scripts directly anymore.  

commit   : 95a07c1ebe78444177b15cf77b80fbaa8380bb56    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Sep 2011 12:14:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Sep 2011 12:14:51 -0400    

This example wasn't updated when we changed the behavior of bpcharlen()  
in 8.0, nor when we changed the number of parameters taken by the bpchar()  
cast function in 7.3.  Per report from lsliang.  

commit   : f85adb65bf2842c258e4c2d2930569e3b702c7d6    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Sep 2011 11:08:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Sep 2011 11:08:34 -0400    

Backpatch to 9.1 and 9.0.  
  
Submitted by Anton Yuzhaninov, confirmed by Robert Haas  

commit   : 0603ba3415f2fa6182248a6b96973224507543d3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Sep 2011 22:58:13 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Sep 2011 22:58:13 -0400    

commit   : 7dc956fee3284170db50c343bad9f52cf767894b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 5 Sep 2011 18:52:49 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 5 Sep 2011 18:52:49 -0300    

commit   : c729082da46c615e663e7c7f996baff1c4c3d560    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 5 Sep 2011 17:47:18 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 5 Sep 2011 17:47:18 -0300    

commit   : 082befb5162920d64ef4c1e905489a625dff2d5a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Sep 2011 15:38:00 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Sep 2011 15:38:00 -0400    

Backpatch to 9.1.  

commit   : 33c371b4f5ac3b3975e57beaf7481f736e53c031    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Sep 2011 14:46:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Sep 2011 14:46:31 -0400    

DST law changes in Canada, Egypt, Russia, Samoa, South Sudan.  

commit   : 2c62b5bb636f5f13bd25777ee1f4c8e557accecd    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Sep 2011 13:24:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Sep 2011 13:24:46 -0400    

Backpatch to 9.0 and 9.1.  

commit   : eed7dcfceedeb314d17695f014754ac0f3e8f892    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Sep 2011 20:07:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Sep 2011 20:07:38 -0400    

The $(PERL) macro will be set by configure if it finds perl at all,  
but $(perl_privlibexp) isn't configured unless you said --with-perl.  
This results in confusing error messages if someone cd's into  
src/pl/plperl and tries to build there despite the configure omission,  
as reported by Tomas Vondra in bug #6198.  Add simple checks to  
provide a more useful report, while not disabling other use of the  
makefile such as "make clean".  
  
Back-patch to 9.0, which is as far as the patch applies easily.  

commit   : 1ae019f04b95771293f9a649c298aaeb0d3155a2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Sep 2011 19:10:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Sep 2011 19:10:09 -0400    

Remove unnecessary and circular #include of syncrep.h from proc.h.  
Add htup.h to tablecmds.h so it will compile without prerequisites.  

commit   : b6cfede8b630db61afa7dd158adde93ba669f429    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Sep 2011 16:17:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Sep 2011 16:17:39 -0400    

">" should be ">>".  This typo results in failure to use all of the bits  
of the provided seed.  
  
This might rise to the level of a security bug if we were relying on  
srand48 for any security-critical purposes, but we are not --- in fact,  
it's not used at all unless the platform lacks srandom(), which is  
improbable.  Even on such a platform the exposure seems minimal.  
  
Reported privately by Andres Freund.  

commit   : 7c0e1a28ac4596e9ea4d942f213114bd70026d6a    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Fri, 2 Sep 2011 09:45:11 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Fri, 2 Sep 2011 09:45:11 +0200    

commit   : 8027e4d4be11e19784908671bf5cee0c6472fb14    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Sep 2011 19:59:09 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Sep 2011 19:59:09 +0300    

commit   : 4fcceef0de221ba98d3f273b6d69ef0d17e43e74    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Sep 2011 18:58:50 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Sep 2011 18:58:50 +0300    

commit   : 5ad0e899f08136a00f56bf224a6b9729b2f4c69f    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Thu, 1 Sep 2011 15:27:38 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Thu, 1 Sep 2011 15:27:38 +0200    

commit   : 6952071450befb74ee0bc3c76c17de816cddfc43    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Sep 2011 14:02:40 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Sep 2011 14:02:40 +0300    

commit   : 83748f3a4e0a6bf3ea3d3da53dc507be038b3d1f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Sep 2011 11:08:32 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Sep 2011 11:08:32 +0300    

To work around that, move the locale name mapping from initdb to a wrapper  
around setlocale(), so that the mapping is invoked on every setlocale() call.  
  
Also, add a few checks for failed setlocale() calls in the backend. These  
calls shouldn't fail, and if they do there isn't much we can do about it,  
but at least you'll get a warning.  
  
Backpatch to 9.1, where the initdb hack was introduced. The Windows bug  
affects older versions too if you set locale manually to one of the aliases,  
but given the lack of complaints from the field, I'm hesitent to backpatch.  

commit   : 116b67f3add43b750c73e30727a58922080067bf    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Sep 2011 09:13:37 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 1 Sep 2011 09:13:37 +0300    

commit   : f759ef139ea3d1b2c74c8b6275ca959d7320f4a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Sep 2011 00:18:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Sep 2011 00:18:34 -0400    

Examination of examples provided by Mark Kirkwood and others has convinced  
me that actually commit 7f3eba30c9d622d1981b1368f2d79ba0999cdff2 was quite  
a few bricks shy of a load.  The useful part of that patch was clamping  
ndistinct for the inner side of a semi or anti join, and the reason why  
that's needed is that it's the only way that restriction clauses  
eliminating rows from the inner relation can affect the estimated size of  
the join result.  I had not clearly understood why the clamping was  
appropriate, and so mis-extrapolated to conclude that we should clamp  
ndistinct for the outer side too, as well as for both sides of regular  
joins.  These latter actions were all wrong, and are reverted with this  
patch.  In addition, the clamping logic is now made to affect the behavior  
of both paths in eqjoinsel_semi, with or without MCV lists to compare.  
When we have MCVs, we suppose that the most common values are the ones  
that are most likely to survive the decimation resulting from a lower  
restriction clause, so we think of the clamping as eliminating non-MCV  
values, or potentially even the least-common MCVs for the inner relation.  
  
Back-patch to 8.4, same as previous fixes in this area.  

commit   : dbb8d4769cff7387c4419aa53b2dae96b0a601d7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2011 21:49:59 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2011 21:49:59 -0400    

This fixes a pg_upgrade bug that could lead to query errors when  
clog files are improperly removed.  
  
Backpatch to 8.4, 9.0, 9.1.  

commit   : ca4f70ca779013599ec4c31c54944c2c7a584e92    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Aug 2011 16:04:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Aug 2011 16:04:53 -0400    

This patch fixes an oversight in my commit  
7f3eba30c9d622d1981b1368f2d79ba0999cdff2 of 2008-10-23.  That patch  
accounted for baserel restriction clauses that reduced the number of rows  
coming out of a table (and hence the number of possibly-distinct values of  
a join variable), but not for join restriction clauses that might have been  
applied at a lower level of join.  To account for the latter, look up the  
sizes of the min_lefthand and min_righthand inputs of the current join,  
and clamp with those in the same way as for the base relations.  
  
Noted while investigating a complaint from Ben Chobot, although this in  
itself doesn't seem to explain his report.  
  
Back-patch to 8.4; previous versions used different estimation methods  
for which this heuristic isn't relevant.  

commit   : edf4edae5799e5f7b7d9822d2932170341ba5472    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 31 Aug 2011 12:37:37 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 31 Aug 2011 12:37:37 +0300    

Fujii Masao  

commit   : 333eb32081d261ede946935379b66e6ac192629d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Aug 2011 17:15:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Aug 2011 17:15:00 -0400    

There's no reason for this test to use the undocumented pg_prepared_xact()  
function, when it can use the stable API pg_prepared_xacts instead.  
Fixes breakage against 8.3, as reported by Justin Arnold.  

commit   : 030cdaf7fb90decfd7f959aa0d67d19b5669f458    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Aug 2011 14:49:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Aug 2011 14:49:52 -0400    

It is possible for VACUUM to scan no pages at all, if the visibility map  
shows that all pages are all-visible.  In this situation VACUUM has no new  
information to report about the relation's tuple density, so it wasn't  
changing pg_class.reltuples ... but it updated pg_class.relpages anyway.  
That's wrong in general, since there is no evidence to justify changing the  
density ratio reltuples/relpages, but it's particularly bad if the previous  
state was relpages=reltuples=0, which means "unknown tuple density".  
We just replaced "unknown" with "zero".  ANALYZE would eventually recover  
from this, but it could take a lot of repetitions of ANALYZE to do so if  
the relation size is much larger than the maximum number of pages ANALYZE  
will scan, because of the moving-average behavior introduced by commit  
b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8.  
  
The only known situation where we could have relpages=reltuples=0 and yet  
the visibility map asserts everything's visible is immediately following  
a pg_upgrade.  It might be advisable for pg_upgrade to try to preserve the  
relpages/reltuples statistics; but in any case this code is wrong on its  
own terms, so fix it.  Per report from Sergey Koposov.  
  
Back-patch to 8.4, where the visibility map was introduced, same as the  
previous change.  

commit   : 579577320ef449442f804043a67ce5c13d679679    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Aug 2011 15:20:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Aug 2011 15:20:57 -0400    

Per bug #6181 from Itagaki Takahiro.  Also do some marginal code cleanup  
and improve error handling.  

commit   : 4fa37702a041a90355f693e10cad0751ef700658    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Aug 2011 22:27:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Aug 2011 22:27:48 -0400    

On closer inspection, whining in restore_toc_entries_parallel is really  
much too late for any user-facing error case.  The right place to do it  
is at the start of RestoreArchive(), before we've done anything interesting  
(suh as trying to DROP all the targets ...)  
  
Back-patch to 8.4, where parallel restore was introduced.  

commit   : 76d8bd8b906ddc27e4aee4b92b3f82e896b7e926    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Aug 2011 21:48:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Aug 2011 21:48:58 -0400    

If we are unable to do a parallel restore because the input file is stdin  
or is otherwise unseekable, we should complain and fail immediately, not  
after having done some of the restore.  Complaining once per thread isn't  
so cool either, and the messages should be worded to make it clear this is  
an unsupported case not some weird race-condition bug.  Per complaint from  
Lonni Friedman.  
  
Back-patch to 8.4, where parallel restore was introduced.  

commit   : 5f81cf34e3e45ae4d464618c0b61914a60282aba    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Aug 2011 16:37:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Aug 2011 16:37:02 -0400    

These days, such a response is far more likely to signify a server-side  
problem, such as fork failure.  Reporting "server does not support SSL"  
(in sslmode=require) could be quite misleading.  But the results could  
be even worse in sslmode=prefer: if the problem was transient and the  
next connection attempt succeeds, we'll have silently fallen back to  
protocol version 2.0, possibly disabling features the user needs.  
  
Hence, it seems best to just eliminate the assumption that backing off  
to non-SSL/2.0 protocol is the way to recover from an "E" response, and  
instead treat the server error the same as we would in non-SSL cases.  
  
I tested this change against a pre-7.0 server, and found that there  
was a second logic bug in the "prefer" path: the test to decide whether  
to make a fallback connection attempt assumed that we must have opened  
conn->ssl, which in fact does not happen given an "E" response.  After  
fixing that, the code does indeed connect successfully to pre-7.0,  
as long as you didn't set sslmode=require.  (If you did, you get  
"Unsupported frontend protocol", which isn't completely off base  
given the server certainly doesn't support SSL.)  
  
Since there seems no reason to believe that pre-7.0 servers exist anymore  
in the wild, back-patch to all supported branches.  

commit   : ef3455f190d3c12de71c06316109bb5ffbffe462    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Aug 2011 14:16:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Aug 2011 14:16:19 -0400    

There are assorted situations wherein PQconnectPoll() will abandon a  
connection attempt and try again with different parameters (eg, SSL versus  
not SSL).  However, the code forgot to discard any pending data in libpq's  
I/O buffers when doing this.  In at least one case (server returns E  
message during SSL negotiation), there is unread input data which bollixes  
the next connection attempt.  I have not checked to see whether this is  
possible in the other cases where we close the socket and retry, but it  
seems like a matter of good defensive programming to add explicit  
buffer-flushing code to all of them.  
  
This is one of several issues exposed by Daniel Farina's report of  
misbehavior after a server-side fork failure.  
  
This has been wrong since forever, so back-patch to all supported branches.  

commit   : 814a7f50c6c53883b0b753458c9912b0e6bc2519    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 27 Aug 2011 08:07:58 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 27 Aug 2011 08:07:58 +0300    

commit   : 93809ad5eb8f0dbd704b2f713f707d8cf684fd57    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Aug 2011 16:51:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Aug 2011 16:51:39 -0400    

tsvector_concat() allocated its result workspace using the "conservative"  
estimate of the sum of the two input tsvectors' sizes.  Unfortunately that  
wasn't so conservative as all that, because it supposed that the number of  
pad bytes required could not grow.  Which it can, as per test case from  
Jesper Krogh, if there's a mix of lexemes with positions and lexemes  
without them in the input data.  The fix is to assume that we might add  
a not-previously-present pad byte for each and every lexeme in the two  
inputs; which really is conservative, but it doesn't seem worthwhile to  
try to be more precise.  
  
This is an aboriginal bug in tsvector_concat, so back-patch to all  
versions containing it.  

commit   : 39a713ea059a8ad3d07e3ea4d2c9b5da1fe3fa25    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 26 Aug 2011 00:12:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 26 Aug 2011 00:12:34 -0400    

Backpatch to 9.0 and 9.1.  

commit   : 0b298bd7a1782fca621068a5e17681be207f5635    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Aug 2011 17:35:57 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Aug 2011 17:35:57 -0300    

This was deemed unnecessary initially but in later discussion it was  
agreed otherwise.  
  
Original file from Kevin Grittner, allegedly from Dan Ports.  
I had to clean up whitespace a bit per changes from Heikki.  

commit   : be93200c76911047dcb94ddb696441ecdef9a3cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Aug 2011 14:33:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Aug 2011 14:33:08 -0400    

Per previous experimentation, backtracking slows down lexing performance  
significantly (by about a third).  It's usually pretty easy to avoid, just  
need to have rules that accept an incomplete construct and do whatever the  
lexer would have done otherwise.  
  
The backtracking was introduced by the patch that added quoted variable  
substitution.  Back-patch to 9.0 where that was added.  

commit   : de632180ed51b8a6ff275a5f81198521e8b30e12    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 25 Aug 2011 12:37:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 25 Aug 2011 12:37:32 -0400    

Shigeru Hanada  

commit   : e1f0820b0d252ace738d7c337eb348eb4dab42d8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 25 Aug 2011 09:41:00 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 25 Aug 2011 09:41:00 -0400    

This reverts commit 1bde67c0b9adce8b7ed2a2d1fcb2788cf96cea64, which  
should have been done only on the master branch.  

commit   : 1bde67c0b9adce8b7ed2a2d1fcb2788cf96cea64    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 25 Aug 2011 09:39:35 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 25 Aug 2011 09:39:35 -0400    

This makes it slightly more clear that '*' is not part of the default  
value, in case that wasn't obvious.  
  
As requested by Dougal Sutherland.  

commit   : eb11a37ed8cd0b38d29c7001435c14fb9316cee6    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 25 Aug 2011 09:35:38 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 25 Aug 2011 09:35:38 -0400    

Noted by Hitoshi Harada.  

commit   : ac45828e99024da2a9febe603d1be91cd87a9a50    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2011 23:50:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2011 23:50:15 -0400    

For an empty index, the pgstatindex() function would compute 0.0/0.0 for  
its avg_leaf_density and leaf_fragmentation outputs.  On machines that  
follow the IEEE float arithmetic standard with any care, that results in  
a NaN.  However, per report from Rushabh Lathia, Microsoft couldn't  
manage to get this right, so you'd get a bizarre error on Windows.  
  
Fix by forcing the results to be NaN explicitly, rather than relying on  
the division operator to give that or the snprintf function to print it  
correctly.  I have some doubts that this is really the most useful  
definition, but it seems better to remain backward-compatible with  
those platforms for which the behavior wasn't completely broken.  
  
Back-patch to 8.2, since the code is like that in all current releases.  

commit   : 5354abb8f69734ff1c07cee5e29845b74d46e9d6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2011 15:16:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2011 15:16:23 -0400    

The previous coding resulted in contrib modules unintentionally overriding  
the use of CONTRIB_TESTDB.  There seems no particularly good reason to  
allow that (after all, the makefile can set CONTRIB_TESTDB if that's really  
what it intends).  
  
In passing, document REGRESS_OPTS where the other pgxs.mk options are  
documented.  
  
Back-patch to 9.1 --- in prior versions, there were no cases of contrib  
modules setting REGRESS_OPTS without including the --dbname switch, so  
while the coding was fragile there was no actual bug.  

commit   : ed1a4adbe38ed94cc2e3c017a9f5be4b282bccb9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 24 Aug 2011 21:34:49 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 24 Aug 2011 21:34:49 +0300    

This fixes failures under parallel make when contrib modules use a  
generated backend header file (such as errcodes.h).  

commit   : 867c20c0720bb2fb7441cbb80949b9ae579ee774    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2011 13:47:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2011 13:47:01 -0400    

We'll have to settle for just listing the extensions' data types,  
since function arguments seem to sort differently in different locales.  
Per buildfarm results.  

commit   : e8513328760ea175001bac52c10219315379b2c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2011 13:09:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Aug 2011 13:09:06 -0400    

When we implemented extensions, we made findDependentObjects() treat  
EXTENSION dependency links similarly to INTERNAL links.  However, that  
logic contained an implicit assumption that an object could have at most  
one INTERNAL dependency, so it did not work correctly for objects having  
both INTERNAL and DEPENDENCY links.  This led to failure to drop some  
extension member objects when dropping the extension.  Furthermore, we'd  
never actually exercised the case of recursing to an internally-referenced  
(owning) object from anything other than a NORMAL dependency, and it turns  
out that passing the incoming dependency's flags to the owning object is  
the Wrong Thing.  This led to sometimes dropping a whole extension silently  
when we should have rejected the drop command for lack of CASCADE.  
  
Since we obviously were under-testing extension drop scenarios, add some  
regression test cases.  Unfortunately, such test cases require some  
extensions (duh), so we can't test for problems in the core regression  
tests.  I chose to add them to the earthdistance contrib module, which is  
a good test case because it has a dependency on the cube contrib module.  
  
Back-patch to 9.1.  Arguably these are pre-existing bugs in INTERNAL  
dependency handling, but since it appears that the cases can never arise  
pre-9.1, I'll refrain from back-patching the logic changes further than  
that.  

commit   : 7f7fdd2a17ce087f995a0660fadf3e9523d72810    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Aug 2011 21:49:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Aug 2011 21:49:07 -0400    

When creating a new schema for a non-relocatable extension, we neglected  
to check whether the calling user has permission to create schemas.  
That didn't matter in the original coding, since we had already checked  
superuserness, but in the new dispensation where users need not be  
superusers, we should check it.  Use CreateSchemaCommand() rather than  
calling NamespaceCreate() directly, so that we also enforce the rules  
about reserved schema names.  
  
Per complaint from KaiGai Kohei, though this isn't the same as his patch.  

commit   : 48f545a3aef461a635b975443a99dd268269590a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Aug 2011 17:11:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Aug 2011 17:11:41 -0400    

set_append_rel_pathlist supposed that, while computing per-column width  
estimates for the appendrel, it could ignore child rels for which the  
translated reltargetlist entry wasn't a Var.  This gave rise to completely  
silly estimates in some common cases, such as constant outputs from some or  
all of the arms of a UNION ALL.  Instead, fall back on get_typavgwidth to  
estimate from the value's datatype; which might be a poor estimate but at  
least it's not completely wacko.  
  
That problem was exposed by an Assert in set_subquery_size_estimates, which  
unfortunately was still overoptimistic even with that fix, since we don't  
compute attr_widths estimates for appendrels that are entirely excluded by  
constraints.  So remove the Assert; we'll just fall back on get_typavgwidth  
in such cases.  
  
Also, since set_subquery_size_estimates calls set_baserel_size_estimates  
which calls set_rel_width, there's no need for set_subquery_size_estimates  
to call get_typavgwidth; set_rel_width will handle it for us if we just  
leave the estimate set to zero.  Remove the unnecessary code.  
  
Per report from Erik Rijkers and subsequent investigation.  

commit   : 26a092657ba4ac52212d43bae9a822a119efbd8a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 23 Aug 2011 11:55:21 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 23 Aug 2011 11:55:21 +0300    

Fujii Masao  

commit   : 9c471d24126280a5f90ee9d276a9df37480dfcde    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Aug 2011 10:55:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 22 Aug 2011 10:55:47 -0400    

The previous coding would result in deleting and not re-creating the  
extension membership pg_depend rows, since there was no  
CommandCounterIncrement that would allow recordDependencyOnCurrentExtension  
to see that the deletion had happened.  Make it work like the shell type  
case, ie, keep the existing entries (and then throw an error if they're for  
the wrong extension).  
  
Per bug #6172 from Hitoshi Harada.  Investigation and fix by Dimitri  
Fontaine.  

commit   : 38c9eb8fee298a9242bb2049c4fdf94407187d0c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Aug 2011 18:16:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Aug 2011 18:16:02 -0400    

Due to tuple-slot mismanagement, evaluation of WHEN conditions for AFTER  
ROW UPDATE triggers could crash if there had been a BEFORE ROW trigger  
fired for the same update.  Fix by not trying to overload the use of  
estate->es_trig_tuple_slot.  Per report from Yoran Heling.  
  
Back-patch to 9.0, when trigger WHEN conditions were introduced.  

commit   : 548d1f752be7a11e240f1eadd4f9987a7b9793c5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 20 Aug 2011 14:51:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 20 Aug 2011 14:51:02 -0400    

As pointed out by Sergey Koposov, repeated invocations of tbm_lossify can  
make building a large tidbitmap into an O(N^2) operation.  To fix, make  
sure we remove more than the minimum amount of information per call, and  
add a fallback path to behave sanely if we're unable to fit the bitmap  
within the requested amount of memory.  
  
This has been wrong since the tidbitmap code was written, so back-patch  
to all supported branches.  

commit   : 1ffcc377f692fb227ebfeb6036aa949099d71979    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Aug 2011 11:57:38 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Aug 2011 11:57:38 -0400    

contrib/xml2 can get by without libxslt; the relevant features just  
won't work.  But if doesn't have libxml2, or if sepgsql doesn't have  
libselinux, the link succeeds but the module then fails to work at load  
time.  To avoid that, link the require libraries unconditionally, so  
that it will be clear at link-time that there is a problem.  
  
Per discussion with Tom Lane and KaiGai Kohei.  

commit   : 1013770dd22193928fab5a3e379dc5ebe5a260be    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Aug 2011 11:51:10 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Aug 2011 11:51:10 -0400    

KaiGai Kohei, with some changes by me.  

commit   : d89b8daf5ee05f9c6fa63695e88d2315a224bf2d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Aug 2011 17:23:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Aug 2011 17:23:13 -0400    

commit   : 6a42b29102092d185f9b752f5a4edf4735e42f9b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Aug 2011 11:45:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Aug 2011 11:45:33 -0400    

Now that we have a test that requires nondefault settings to pass, it seems  
like we'd better mention that detail in the directions about how to run the  
tests.  
  
Also do some very minor copy-editing.  

commit   : b936d9264c08418909e3ec5d6107bd104d62fdc2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 18 Aug 2011 16:47:31 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 18 Aug 2011 16:47:31 +0300    

Alvaro committed these fixes to master branch on Tue Jul 29th, as part of  
Noah Misch's patch. The rest of that patch is not needed on 9.1, but this  
part should be backpatched.  

commit   : b9585e8f983863fc7e1e147f503091a5f82d6ccf    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 18 Aug 2011 13:36:37 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 18 Aug 2011 13:36:37 +0300    

The test runs for a quite long time, and the expected output file is huge,  
but this test caught some serious bugs during development, so seems  
worthwhile to keep. The test uses prepared transactions, so it fails if the  
server has max_prepared_transactions=0. Because of that, it's marked as  
"ignore" in the schedule file.  
  
Dan Ports  

commit   : 89c096c56542cdd7355925f826b3c67dc5265155    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 18 Aug 2011 12:16:10 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 18 Aug 2011 12:16:10 +0300    

commit   : 7ce4abf5993dd8819053d0592aa2276d49b3ffb3    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 18 Aug 2011 14:43:16 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 18 Aug 2011 14:43:16 +0300    

Because of ABI tagging, the library version number might no longer be  
exactly the Python version number, so do extra lookups.  This affects  
installations without a shared library, such as ActiveState's  
installer.  
  
Also update the way to detect the location of the 'config' directory,  
which can also be versioned.  
  
Ashesh Vashi  

commit   : 7b1509d56256fa391d4ae71288be194923a41947    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 18 Aug 2011 12:53:32 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 18 Aug 2011 12:53:32 +0300    

Module initialization functions in Python 3 must have external  
linkage, because PyMODINIT_FUNC does dllexport on Windows-like  
platforms.  Without this change, the build with Python 3 fails on  
Windows.  

commit   : f85e4057cfe62752eb57d2315d4acda5bb5c1e9e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Aug 2011 20:18:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Aug 2011 20:18:23 -0400    

Also do another pass of copy-editing.  

commit   : f26474eff49c12c1bfc02f986406e44045108074    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Aug 2011 17:07:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Aug 2011 17:07:25 -0400    

Dropped columns within a composite type were not handled correctly.  
Also, we did not check for whether a composite result type had changed  
since we cached the information about it.  
  
Jan Urbański, per a bug report from Jean-Baptiste Quenot  

commit   : 22a55b3af687806e6b3a08a131d00541774eaade    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 17 Aug 2011 12:03:26 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 17 Aug 2011 12:03:26 -0400    

Bug reported by David Wheeler, fix by Alex Hunsaker.  
# Please enter the commit message for your changes. Lines starting  
# with '#' will be ignored, and an empty message aborts the commit.  
# On branch master  
# Changes to be committed:  
#   (use "git reset HEAD <file>..." to unstage)  
#  
#	modified:   src/pl/plperl/plperl.c  
#  
# Untracked files:  
#   (use "git add <file>..." to include in what will be committed)  
#  
#	autom4te.cache/  
#	configure.in~  
#	doc/src/sgml/ref/grant.sgml~  
#	src/backend/port/win32_latch.c~  
#	src/bin/psql/command.c~  
#	src/include/pg_config.h.win32~  
#	src/pl/plpython/plpython.c~  
#	src/tools/msvc/pgbison.bat~  
#	src/tools/msvc/pgbison.pl.bak  
#	src/tools/msvc/pgflex.bat~  
#	src/tools/msvc/pgflex.pl.bak  
#	src/tools/pgindent/README~  
#	src/tools/pgindent/pgindent.pl  
#	src/tools/pgindent/pgindent.pl~  
#	xxxxx  
#	yyyyyy  

commit   : dfee7d16ad2060e9f73f3002fd979acc085f9391    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 17 Aug 2011 14:02:24 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 17 Aug 2011 14:02:24 +0300    

commit   : aee1df4de5006300cfb59b531933b1e0142a8735    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 17 Aug 2011 11:01:06 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 17 Aug 2011 11:01:06 +0200    

Per comment form Fujii Masao.  

commit   : 59dd4790e24b2fdffe85b8d3664a8374303cca24    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 17 Aug 2011 11:36:47 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 17 Aug 2011 11:36:47 +0300    

To distinguish those cases, add a line to backup_label to indicate  
whether the backup was taken with pg_start/stop_backup(), or by streaming  
(ie. pg_basebackup).  
  
This is a different implementation than what I committed to 9.2 a week ago.  
That implementation was not back-patchable because it required re-initdb.  
  
Fujii Masao  

commit   : 9dcaf9a0526ff988566a47d21b5a8149e17c9ba2    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 17 Aug 2011 10:52:35 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 17 Aug 2011 10:52:35 +0300    

The translation tools are very unhappy about seeing \r in translatable  
strings, so move it to a separate fprintf call.  

commit   : 1361a47359669dffb0bfbbbb6fec8be3c5087656    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 17 Aug 2011 10:05:22 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 17 Aug 2011 10:05:22 +0300    

Josh Kupershmidt  

commit   : 1713bbca7d305c728785afb2c7603da97f4d6704    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2011 15:26:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2011 15:26:30 -0400    

The TID isn't stable enough: we might queue an sinval event before a VACUUM  
FULL, and then process it afterwards, when the target tuple no longer has  
the same TID.  So we must invalidate entries on the basis of hash value  
only.  The old coding can be shown to result in various bizarre,  
hard-to-reproduce errors in the presence of concurrent VACUUM FULLs on  
system catalogs, and could easily result in permanent catalog corruption,  
up to and including complete loss of tables.  
  
This commit is just a minimal fix that removes the unsafe comparison.  
We should remove transmission of the tuple TID from sinval messages  
altogether, and then arrange to suppress the extra message in the common  
case of a heap_update that doesn't change the key hashvalue.  But that's  
going to be much more invasive, and will only produce a probably-marginal  
performance gain, so it doesn't seem like material for a back-patch.  
  
Back-patch to 9.0.  Before that, VACUUM FULL refused to do any tuple moving  
if it found any INSERT_IN_PROGRESS or DELETE_IN_PROGRESS tuples (and  
CLUSTER would give up altogether), so there was no risk of moving a tuple  
that might be the subject of an unsent sinval message.  

commit   : 84333962eae9e513bb12feb41069e3a3945a7a1a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2011 14:38:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2011 14:38:29 -0400    

We have to be sure that we have revalidated each nailed-in-cache relcache  
entry before we try to use it to load data for some other relcache entry.  
The introduction of "mapped relations" in 9.0 broke this, because although  
we updated the state kept in relmapper.c early enough, we failed to  
propagate that information into relcache entries soon enough; in  
particular, we could try to fetch pg_class rows out of pg_class before  
we'd updated its relcache entry's rd_node.relNode value from the map.  
  
This bug accounts for Dave Gould's report of failures after "vacuum full  
pg_class", and I believe that there is risk for other system catalogs  
as well.  
  
The core part of the fix is to copy relmapper data into the relcache  
entries during "phase 1" in RelationCacheInvalidate(), before they'll be  
used in "phase 2".  To try to future-proof the code against other similar  
bugs, I also rearranged the order in which nailed relations are visited  
during phase 2: now it's pg_class first, then pg_class_oid_index, then  
other nailed relations.  This should ensure that RelationClearRelation can  
apply RelationReloadIndexInfo to all nailed indexes without risking use  
of not-yet-revalidated relcache entries.  
  
Back-patch to 9.0 where the relation mapper was introduced.  

commit   : f48e62274f48df5788eef8465198184450ab6ad8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2011 13:48:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2011 13:48:11 -0400    

This works around the problem that a catalog cache entry might contain a  
toast pointer that we try to dereference just as a VACUUM FULL completes  
on that catalog.  We will see the sinval message on the cache entry when  
we acquire lock on the toast table, but by that point we've already told  
tuptoaster.c "here's the pointer to fetch", so it's difficult from a code  
structural standpoint to update the pointer before we use it.  Much less  
painful to ensure that toast pointers are not invalidated in the first  
place.  We have to add a bit of code to deal with the case that a value  
that previously wasn't toasted becomes so; but that should be a  
seldom-exercised corner case, so the inefficiency shouldn't be significant.  
  
Back-patch to 9.0.  In prior versions, we didn't allow CLUSTER on system  
catalogs, and VACUUM FULL didn't result in reassignment of toast OIDs, so  
there was no problem.  

commit   : 45476031a54c12bebf2f209ea2b6fb3bfc905193    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2011 13:12:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Aug 2011 13:12:03 -0400    

The previous code tried to synchronize by unlinking the init file twice,  
but that doesn't actually work: it leaves a window wherein a third process  
could read the already-stale init file but miss the SI messages that would  
tell it the data is stale.  The result would be bizarre failures in catalog  
accesses, typically "could not read block 0 in file ..." later during  
startup.  
  
Instead, hold RelCacheInitLock across both the unlink and the sending of  
the SI messages.  This is more straightforward, and might even be a bit  
faster since only one unlink call is needed.  
  
This has been wrong since it was put in (in 2002!), so back-patch to all  
supported releases.  

commit   : 0615782b23d3e4a9d9acece919bd77f919928953    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 16 Aug 2011 16:56:47 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 16 Aug 2011 16:56:47 +0200    

When streaming including WAL, the size estimate will always be incorrect,  
since we don't know how much WAL is included. To make sure the output doesn't  
look completely unreasonable, this patch increases the total size whenever we  
go past the estimate, to make sure we never go above 100%.  

commit   : be78374f160d4a3bb2357d38e3196f8dcd4ffcc1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 16 Aug 2011 11:24:08 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 16 Aug 2011 11:24:08 +0300    

Also fix a potential portability bug, because INT64_FORMAT is only  
guaranteed to be available with snprintf, not fprintf.  

commit   : adbb764e5040b388c55bf1344cafa3c5fee7c14f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 16 Aug 2011 11:19:50 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 16 Aug 2011 11:19:50 +0300    

commit   : 96a770d5da62c820efcb32e06887f112e9b40d80    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 15 Aug 2011 22:39:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 15 Aug 2011 22:39:37 -0400    

Fix for 9.0, 9.1, and 9.2.  

commit   : b0313ddd6e4924763904b052c7a9ba14166876f6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Aug 2011 17:27:10 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Aug 2011 17:27:10 +0300    

commit   : 90ffdf83d28900f280a8a1e4ed904ebf7da8cb90    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Aug 2011 15:20:16 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Aug 2011 15:20:16 +0300    

This makes it clearer that the error message is perhaps not supposed  
to be understood by users, and it also makes it somewhat clearer that  
it was not accidentally omitted from translation.  
  
Idea from Heikki Linnakangas, except that we don't mark "Reason code"  
for translation at this point, because that would make the  
implementation too cumbersome.  

commit   : 148f321eb4fe9030378ad21ba1be132084a9ab8f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Aug 2011 15:40:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Aug 2011 15:40:29 -0400    

When updating or deleting a system catalog tuple, it's necessary to acquire  
RowExclusiveLock on the catalog before looking up the tuple; otherwise a  
concurrent VACUUM FULL on the catalog might move the tuple to a different  
TID before we can apply the update.  Coding patterns that find the tuple  
via a table scan aren't at risk here, but when obtaining the tuple from a  
catalog cache, correct ordering is important; and several routines in  
foreigncmds.c got it wrong.  Noted while running the regression tests in  
parallel with VACUUM FULL of assorted system catalogs.  
  
For consistency I moved all the heap_open calls to the starts of their  
functions, including a couple for which there was no actual bug.  
  
Back-patch to 8.4 where foreigncmds.c was added.  

commit   : 00fc5d22634df1a59c8a265dba3f12814dc343c3    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 14 Aug 2011 21:03:08 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 14 Aug 2011 21:03:08 +0300    

commit   : 280daac70790cd5fc0129ac620935e4fc4ca7a90    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 14 Aug 2011 10:40:50 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 14 Aug 2011 10:40:50 +0300    

commit   : 6a3f153d08259a2ea1d509668dea665528246ef0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Aug 2011 17:52:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Aug 2011 17:52:24 -0400    

The statement start timestamp was not set before initiating the transaction  
that is used to look up client authentication information in pg_authid.  
In consequence, enable_sig_alarm computed a wrong value (far in the past)  
for statement_fin_time.  That didn't have any immediate effect, because the  
timeout alarm was set without reference to statement_fin_time; but if we  
subsequently blocked on a lock for a short time, CheckStatementTimeout  
would consult the bogus value when we cancelled the lock timeout wait,  
and then conclude we'd timed out, leading to immediate failure of the  
connection attempt.  Thus an innocent "vacuum full pg_authid" would cause  
failures of concurrent connection attempts.  Noted while testing other,  
more serious consequences of vacuum full on system catalogs.  
  
We should set the statement timestamp before StartTransactionCommand(),  
so that the transaction start timestamp is also valid.  I'm not sure if  
there are any non-cosmetic effects of it not being valid, but the xact  
timestamp is at least sent to the statistics machinery.  
  
Back-patch to 9.0.  Before that, the client authentication timeout was done  
outside any transaction and did not depend on this state to be valid.  

commit   : fee4a066b1034e70e185e9dfb0eb6a2cd46dfa68    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Aug 2011 16:36:58 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Aug 2011 16:36:58 -0400    

Backpatch to 9.1, obviously.  

commit   : a60c16db5f36562df571d36fcacbbed33fd40bd4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 11 Aug 2011 11:23:51 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 11 Aug 2011 11:23:51 -0400    

check_object_ownership() isn't happy about the null relation pointer.  
We could fix it there, but this seems more future-proof.  

commit   : 989f530d3f793ed1c990d705d0958bfd2a533b85    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Aug 2011 12:20:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Aug 2011 12:20:45 -0400    

Fix a whole bunch of signal handlers that had been hacked to do things that  
might change errno, without adding the necessary save/restore logic for  
errno.  Also make some minor fixes in unix_latch.c, and clean up bizarre  
and unsafe scheme for disowning the process's latch.  While at it, rename  
the PGPROC latch field to procLatch for consistency with 9.2.  
  
Issues noted while reviewing a patch by Peter Geoghegan.  

commit   : 74d099494c5853a44188316ba117a8909b299d40    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Aug 2011 18:52:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Aug 2011 18:52:35 -0400    

The original definition had the problem that timeouts exceeding about 2100  
seconds couldn't be specified on 32-bit machines.  Milliseconds seem like  
sufficient resolution, and finer grain than that would be fantasy anyway  
on many platforms.  
  
Back-patch to 9.1 so that this aspect of the latch API won't change between  
9.1 and later releases.  
  
Peter Geoghegan  

commit   : 6760a4d4029121981bf3ec24847ddfbacecc070d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Aug 2011 15:30:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Aug 2011 15:30:51 -0400    

Improve the documentation around weak-memory-ordering risks, and do a pass  
of general editorialization on the comments in the latch code.  Make the  
Windows latch code more like the Unix latch code where feasible; in  
particular provide the same Assert checks in both implementations.  
Fix poorly-placed WaitLatch call in syncrep.c.  
  
This patch resolves, for the moment, concerns around weak-memory-ordering  
bugs in latch-related code: we have documented the restrictions and checked  
that existing calls meet them.  In 9.2 I hope that we will install suitable  
memory barrier instructions in SetLatch/ResetLatch, so that their callers  
don't need to be quite so careful.  

commit   : 028a0c5a2913f18c954845cc014786912f39fa30    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Aug 2011 00:48:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Aug 2011 00:48:58 -0400    

A PlaceHolderVar's expression might contain another, lower-level  
PlaceHolderVar.  If the outer PlaceHolderVar is used, the inner one  
certainly will be also, and so we have to make sure that both of them get  
into the placeholder_list with correct ph_may_need values during the  
initial pre-scan of the query (before deconstruct_jointree starts).  
We did this correctly for PlaceHolderVars appearing in the query quals,  
but overlooked the issue for those appearing in the top-level targetlist;  
with the result that nested placeholders referenced only in the targetlist  
did not work correctly, as illustrated in bug #6154.  
  
While at it, add some error checking to find_placeholder_info to ensure  
that we don't try to create new placeholders after it's too late to do so;  
they have to all be created before deconstruct_jointree starts.  
  
Back-patch to 8.4 where the PlaceHolderVar mechanism was introduced.  

commit   : 8956231576f082bd6e75f6c2f1c2a250b919176f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 7 Aug 2011 22:15:38 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 7 Aug 2011 22:15:38 +0300    

Almost all other pages have one; this one must have been forgotten.  

commit   : 9089628d968e9d60c10acf010e7e4225c7f12c96    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 7 Aug 2011 16:11:55 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 7 Aug 2011 16:11:55 +0300    

commit   : b689df4ca95c6f62a231d817e22649939a8150c4    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 7 Aug 2011 15:51:04 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 7 Aug 2011 15:51:04 +0300    

For consistency with other man pages.  

commit   : ad8641d535b46888c2f911a98a9b112771d82af6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 7 Aug 2011 10:49:45 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 7 Aug 2011 10:49:45 +0300    

There is what may actually be a mistake in our markup.  The problem is  
in a situation like  
  
<para>  
 <command>FOO</command> is ...  
  
there is strictly speaking a line break before "FOO".  In the HTML  
output, this does not appear to be a problem, but in the man page  
output, this shows up, so you get double blank lines at odd places.  
  
So far, we have attempted to work around this with an XSL hack, but  
that causes other problems, such as creating run-ins in places like  
  
<acronym>SQL</acronym> <command>COPY</command>  
  
So fix the problem properly by removing the extra whitespace.  I only  
fixed the problems that affect the man page output, not all the  
places.  

commit   : af0eca1a80e3e3a6fa0ee00df4a7883e4f228d0b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Aug 2011 14:53:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Aug 2011 14:53:59 -0400    

Somebody thought it'd be cute to invent a set of Node tag numbers that were  
defined independently of, and indeed conflicting with, the main tag-number  
list.  While this accidentally failed to fail so far, it would certainly  
lead to trouble as soon as anyone wanted to, say, apply copyObject to these  
node types.  Clang was already complaining about the use of makeNode on  
these tags, and I think quite rightly so.  Fix by pushing these node  
definitions into the mainstream, including putting replnodes.h where it  
belongs.  

commit   : 34e2ef661b47140594feb4718893b42fc6fc1771    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2011 21:18:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2011 21:18:02 -0400    

Somebody added a cross-reference to shared_preload_libraries, but wrote the  
wrong variable name when they did it (and didn't bother to make it a link  
either).  
  
Spotted by Christoph Anton Mitterer.  

commit   : 20b6578bdb4fe40eee7a01674eb077ffdb19d874    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2011 21:02:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Aug 2011 21:02:31 -0400    

The previous limit of 1024 was set on the assumption that all modern syslog  
implementations have line length limits of 2KB or so.  However, this is  
false, as at least Solaris and sysklogd truncate at only 1KB.  900 seems  
to leave enough room for the max likely length of the tacked-on prefixes,  
so let's go with that.  
  
As with the previous change, it doesn't seem wise to back-patch this into  
already-released branches; but it should be OK to sneak it into 9.1.  
  
Noah Misch  

commit   : 95245e887858e5b18772387d0ebeba32862e516c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 4 Aug 2011 15:02:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 4 Aug 2011 15:02:02 -0400    

Backpatch to 9.1 and 9.0.  

commit   : 857433b80e99e53b2187fd6a58dacaf2181fb8ce    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 4 Aug 2011 12:06:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 4 Aug 2011 12:06:53 -0400    

Backpatch to 9.1 and 9.0.  

commit   : 1318f1ad775d310fc7ce045603432c0f810dcdbf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Aug 2011 15:16:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Aug 2011 15:16:37 -0400    

This kluge was inserted in a spot apparently chosen at random: the lock  
manager's state is not yet fully set up for the wait, and in particular  
LockWaitCancel hasn't been armed by setting lockAwaited, so the ProcLock  
will not get cleaned up if the ereport is thrown.  This seems to not cause  
any observable problem in trivial test cases, because LockReleaseAll will  
silently clean up the debris; but I was able to cause failures with tests  
involving subtransactions.  
  
Fixes breakage induced by commit c85c941470efc44494fd7a5f426ee85fc65c268c.  
Back-patch to all affected branches.  

commit   : 0dd6a09e3d127e728b9f43cfaf19e5351f60a096    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Aug 2011 13:24:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Aug 2011 13:24:00 -0400    

It was initialized in the wrong place and to the wrong value.  With bad  
luck this could result in incorrect query-cancellation failures in hot  
standby sessions, should a HS backend be holding pin on buffer number 1  
while trying to acquire a lock.  

commit   : bc6616aaedbe4bcd2441334a3bf8f43fe9635bf1    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 2 Aug 2011 10:47:17 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 2 Aug 2011 10:47:17 +0300    

This fixes bug #6139 reported by Hitoshi Harada.  

commit   : c1b910ed189a04c199fc1fb146262053827b524f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 31 Jul 2011 18:03:43 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 31 Jul 2011 18:03:43 +0300    

This is to be able to analyze issues with host names in pg_hba.conf.  

commit   : 4d2d5b8196c774a1ac23cd7e7567e8bbd589b6aa    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Jul 2011 01:50:19 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 30 Jul 2011 01:50:19 -0400    

Backpatch to 9.1.  

commit   : 4798aa5b09d8da9a221da4b91e92f1683174ad1e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2011 14:07:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Jul 2011 14:07:04 -0400    

pg_backup_db.c contained a mini SQL lexer with which it tried to identify  
boundaries between SQL commands, but that code was not designed to cope  
with standard_conforming_strings, and would get the wrong answer if a  
backslash immediately precedes a closing single quote in such a string,  
as per report from Julian Mehnle.  The bug only affects direct-to-database  
restores from archive files made with standard_conforming_strings = on.  
  
Rather than complicating the code some more to try to fix that, let's just  
rip it all out.  The only reason it was needed was to cope with COPY data  
embedded into ordinary archive entries, which was a layout that was used  
only for about the first three weeks of the archive format's existence,  
and never in any production release of pg_dump.  Instead, just rely on the  
archive file layout to tell us whether we're printing COPY data or not.  
  
This bug represents a data corruption hazard in all releases in which  
standard_conforming_strings can be turned on, ie 8.2 and later, so  
back-patch to all supported branches.  

commit   : 42221b597eac30f06f1f49375538072985d3b59b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 27 Jul 2011 23:54:46 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 27 Jul 2011 23:54:46 +0300    

commit   : 0b624d64a1fc7d8ecd031d4aaac368699fca3dc4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Jul 2011 11:20:07 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 27 Jul 2011 11:20:07 -0400    

Noted by Josh Kupershmidt.  

commit   : 14e109e82e8a7a179ad828ec1ed06ac0a8cd011a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 26 Jul 2011 23:27:40 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 26 Jul 2011 23:27:40 +0300    

commit   : d94eb49634fff6abc72bed577269aa21fd9f01e9    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 26 Jul 2011 09:34:55 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 26 Jul 2011 09:34:55 -0400    

Per discussion with Josh Kupershmidt.  

commit   : 5c70cc890dfadb4579c8e96c4b27cce285e75cfc    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 25 Jul 2011 23:46:52 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 25 Jul 2011 23:46:52 -0400    

Windows doesn't have Unix sockets, so it's not needed, and moreover causes compile warnings.  

commit   : cd28f09577667b4bfe36c4c41c786b0f69949bd1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 25 Jul 2011 09:37:06 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 25 Jul 2011 09:37:06 -0400    

Laurenz Albe, somewhat modified by me.  

commit   : 2ae6075b59696f044d15c9f1b60a800407471b62    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Jul 2011 23:29:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Jul 2011 23:29:10 -0400    

On balance, the need to cover this case changes my mind in favor of pushing  
all error-message generation duties into the two fe-secure.c routines.  
So do it that way.  

commit   : f9d466e53036b9bb4e075ebde754b90008cf80b2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Jul 2011 16:29:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Jul 2011 16:29:13 -0400    

In many cases, pqsecure_read/pqsecure_write set up useful error messages,  
which were then overwritten with useless ones by their callers.  Fix this  
by defining the responsibility to set an error message to be entirely that  
of the lower-level function when using SSL.  
  
Back-patch to 8.3; the code is too different in 8.2 to be worth the  
trouble.  

commit   : f9c0547aa205148cc62b692a99fde8c3f62bd058    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Jul 2011 15:17:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Jul 2011 15:17:56 -0400    

This disables an entirely unnecessary "sanity check" that causes failures  
in nonblocking mode, because OpenSSL complains if we move or compact the  
write buffer.  The only actual requirement is that we not modify pending  
data once we've attempted to send it, which we don't.  Per testing and  
research by Martin Pihlak, though this fix is a lot simpler than his patch.  
  
I put the same change into the backend, although it's less clear whether  
it's necessary there.  We do use nonblock mode in some situations in  
streaming replication, so seems best to keep the same behavior in the  
backend as in libpq.  
  
Back-patch to all supported releases.  

commit   : 7f4c34739b183b5cf4e9141e3b2e09b99bf7cbad    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 24 Jul 2011 01:43:01 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 24 Jul 2011 01:43:01 -0400    

Backpatch to 9.1 where this check was added.  

commit   : 552a5c73e08b74968a5f1591c5f09dc8f519a173    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 23 Jul 2011 19:33:04 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 23 Jul 2011 19:33:04 -0400    

commit   : 70a488878f97eeec09356054fc161b9f8e914257    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 24 Jul 2011 00:25:29 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 24 Jul 2011 00:25:29 +0300    

Also change "switch" to "arg" because "switch" is a bit of a sloppy  
term.  So the environment variable is called  
PSQL_EDITOR_LINENUMBER_ARG.  Set "+" as hardcoded default value on  
Unix (since "vi" is the hardcoded default editor), so many users won't  
have to configure this at all.  Move the documentation around a bit to  
centralize the editor configuration under environment variables,  
rather than repeating bits of it under every backslash command that  
invokes an editor.  

commit   : eb15f26d577a11319b9429fb84f752a0135918db    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Jul 2011 16:59:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Jul 2011 16:59:49 -0400    

The original implementation simply did nothing when replacing an existing  
object during CREATE EXTENSION.  The folly of this was exposed by a report  
from Marc Munro: if the existing object belongs to another extension, we  
are left in an inconsistent state.  We should insist that the object does  
not belong to another extension, and then add it to the current extension  
if not already a member.  

commit   : 16a6a70ea37be76b7c3757503defbbd05d2acdf1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 22 Jul 2011 16:15:43 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 22 Jul 2011 16:15:43 -0400    

I broke this in commit 5da79169d3e9f0fab47da03318c44075b3f824c5, which  
was obviously insufficiently well tested.  Add some regression tests  
in the hope of making future slip-ups more likely to be noticed.  

commit   : 64207122a241282189451fdcbab3f5e2a6e1e1b1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jul 2011 12:24:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jul 2011 12:24:14 -0400    

PQsetvalue unnecessarily duplicated the logic in pqAddTuple, and didn't  
duplicate it exactly either --- pqAddTuple does not care what is in the  
tuple-pointer array positions beyond the last valid entry, whereas the  
code in PQsetvalue assumed such positions would contain NULL.  This led  
to possible crashes if PQsetvalue was applied to a PGresult that had  
previously been enlarged with pqAddTuple, for instance one built from a  
server query.  Fix by relying on pqAddTuple instead of duplicating logic,  
and not assuming anything about the contents of res->tuples[res->ntups].  
  
Back-patch to 8.4, where PQsetvalue was introduced.  
  
Andrew Chernow  

commit   : c3810795e99ee20181884e62d925f5ac910f0b8b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 20 Jul 2011 18:31:07 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 20 Jul 2011 18:31:07 -0400    

Also, double-quote the log file name in all places, to allow (on all  
platforms) log file names with spaces.  
  
Back patch to 9.0 and 9.1.  

commit   : 1879cf3f173639de8235fb50be42abbbf672646b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Jul 2011 09:22:57 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Jul 2011 09:22:57 -0400    

KaiGai Kohei, based on feedback from Yeb Havinga, with some  
corrections by me.  

commit   : aa47101338aa05cfec1fc00f0df0eb2bd04f149a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Jul 2011 09:12:42 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Jul 2011 09:12:42 -0400    

This is a bit more consistent with the way pg_description is  
documented, and also include a useful cross-link.  

commit   : 2011712a5aced8a359d46b6815fd8656577230cb    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 19 Jul 2011 08:02:34 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 19 Jul 2011 08:02:34 +0300    

commit   : e4ce3b777586ddc0f9e351509a1daddb482190b2    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 19 Jul 2011 07:50:10 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 19 Jul 2011 07:50:10 +0300    

commit   : 826fe721b2eb7d41c733df3fa654fc992b3d80d6    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Mon, 18 Jul 2011 18:56:15 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Mon, 18 Jul 2011 18:56:15 +0200    

commit   : 40922b69c404ac9e0c9802fe973f5297b8808f0c    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Mon, 18 Jul 2011 16:25:27 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Mon, 18 Jul 2011 16:25:27 +0200    

Patch originally by Akira Kurosawa <kurosawa-akira@mxc.nes.nec.co.jp>.  

commit   : 548d197ca751895ec6acbaee611c287ce1d6fe47    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Jul 2011 07:30:00 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Jul 2011 07:30:00 +0300    

We have a few people involved there now.  

commit   : b17648bc6e1dbb8c717c70129b4774310d6804ab    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Jul 2011 07:26:30 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 18 Jul 2011 07:26:30 +0300    

commit   : fbd847a5877444f098cdbf270b967f8010a48838    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2011 14:21:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2011 14:21:24 -0400    

There may be some other places where we should use errdetail_internal,  
but they'll have to be evaluated case-by-case.  This commit just hits  
a bunch of places where invoking gettext is obviously a waste of cycles.  

commit   : 3b41d490bb4225ff0398900f566b1e4c728eff05    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2011 13:49:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2011 13:49:44 -0400    

Per discussion, these seem too technical to be worth translating.  
  
Kevin Grittner  

commit   : 657836741410563be35180ba34adcdae6c767ce5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2011 13:41:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Jul 2011 13:41:48 -0400    

This function supports untranslated detail messages, in the same way that  
errmsg_internal supports untranslated primary messages.  We've needed this  
for some time IMO, but discussion of some cases in the SSI code provided  
the impetus to actually add it.  
  
Kevin Grittner, with minor adjustments by me  

commit   : 885604d112d5b20d94e2d5d8b352d47a6e585ceb    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sat, 16 Jul 2011 19:58:53 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sat, 16 Jul 2011 19:58:53 +0200    

This fixes SSPI login failures showing "The function  
requested is not supported", often showing up when connecting  
to localhost. The reason was not properly updating the SSPI  
handle when multiple roundtrips were required to complete the  
authentication sequence.  
  
Report and analysis by Ahmed Shinwari, patch by Magnus Hagander  

commit   : f844022a0953ab013055fc68bd3ec34f504a6115    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 15 Jul 2011 10:54:56 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 15 Jul 2011 10:54:56 +0300    

First, when following a right-link, we incorrectly marked the current page  
as the parent of the right sibling. In reality, the parent of the right page  
is the same as the parent of the current page (or some page to the right of  
it, gistFindCorrectParent() will sort that out).  
  
Secondly, when we follow a right-link, we must prepend, not append, the right  
page to our list of pages to visit. That's because we assume that once we  
hit a leaf page in the list, all the rest are leaf pages too, and give up.  
  
To hit these bugs, you need concurrent actions and several unlucky accidents.  
Another backend must split the root page, while you're in process of  
splitting a lower-level page. Furthermore, while you scan the internal nodes  
to re-find the parent, another backend needs to again split some more internal  
pages. Even then, the bugs don't necessarily manifest as user-visible errors  
or index corruption.  
  
While we're at it, make the error reporting a bit better if gistFindPath()  
fails to re-find the parent. It used to be an assertion, but an elog() seems  
more appropriate.  
  
Backpatch to all supported branches.  

commit   : cf82452855b76611b73ab8d4dde75f1758d8bf28    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Jul 2011 17:30:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Jul 2011 17:30:57 -0400    

There's a heuristic in estimate_rel_size() to clamp the minimum size  
estimate for a table to 10 pages, unless we can see that vacuum or analyze  
has been run (and set relpages to something nonzero, so this will always  
happen for a table that's actually empty).  However, it would be better  
not to do this for inheritance parent tables, which very commonly are  
really empty and can be expected to stay that way.  Per discussion of a  
recent pgsql-performance report from Anish Kejariwal.  Also prevent it  
from happening for indexes (although this is more in the nature of  
documentation, since CREATE INDEX normally initializes relpages to  
something nonzero anyway).  
  
Back-patch to 9.0, because the ability to collect statistics across a  
whole inheritance tree has improved the planner's estimates to the point  
where this relatively small error makes a significant difference.  In the  
referenced report, merge or hash joins were incorrectly estimated as  
cheaper than a nestloop with inner indexscan on the inherited table.  
That was less likely before 9.0 because the lack of inherited stats would  
have resulted in a default (and rather pessimistic) estimate of the cost  
of a merge or hash join.  

commit   : a3678ab2147fad8e64ea5198a545fb902e6d65f4    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Jul 2011 19:07:39 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Jul 2011 19:07:39 +0300    

Debian/Ubuntu don't have a /etc/rc.d/ directory, so add some  
alternative names as suggestions.  

commit   : a5e3c182c8ff23c60a629631160e07f9f4710f63    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Jul 2011 18:28:07 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 14 Jul 2011 18:28:07 +0300    

They were wildly outdated.  

commit   : 699a1c65eda557ff847c8da83c615b03f6f74265    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 13 Jul 2011 01:30:35 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 13 Jul 2011 01:30:35 +0300    

commit   : b61b28fbe8147b003550548b4976977252ee39b3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Jul 2011 18:24:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Jul 2011 18:24:53 -0400    

Regular aggregate functions in combination with, or within the arguments  
of, window functions are OK per spec; they have the semantics that the  
aggregate output rows are computed and then we run the window functions  
over that row set.  (Thus, this combination is not really useful unless  
there's a GROUP BY so that more than one aggregate output row is possible.)  
The case without GROUP BY could fail, as recently reported by Jeff Davis,  
because sloppy construction of the Agg node's targetlist resulted in extra  
references to possibly-ungrouped Vars appearing outside the aggregate  
function calls themselves.  See the added regression test case for an  
example.  
  
Fixing this requires modifying the API of flatten_tlist and its underlying  
function pull_var_clause.  I chose to make pull_var_clause's API for  
aggregates identical to what it was already doing for placeholders, since  
the useful behaviors turn out to be the same (error, report node as-is, or  
recurse into it).  I also tightened the error checking in this area a bit:  
if it was ever valid to see an uplevel Var, Aggref, or PlaceHolderVar here,  
that was a long time ago, so complain instead of ignoring them.  
  
Backpatch into 9.1.  The failure exists in 8.4 and 9.0 as well, but seeing  
that it only occurs in a basically-useless corner case, it doesn't seem  
worth the risks of changing a function API in a minor release.  There might  
be third-party code using pull_var_clause.  

commit   : 7c884433992cce9f53d87ca3a5d0d629e21af300    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jul 2011 17:03:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jul 2011 17:03:06 -0400    

We were using GetConfigOption to collect the old value of each setting,  
overlooking the possibility that it didn't exist yet.  This does happen  
in the case of adding a new entry within a custom variable class, as  
exhibited in bug #6097 from Maxim Boguk.  
  
To fix, add a missing_ok parameter to GetConfigOption, but only in 9.1  
and HEAD --- it seems possible that some third-party code is using that  
function, so changing its API in a minor release would cause problems.  
In 9.0, create a near-duplicate function instead.  

commit   : ec194651b8ba36e9ad5f7c98ac77c4d9639e2351    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 8 Jul 2011 17:28:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 8 Jul 2011 17:28:27 +0300    

commit   : ebea4c531c9edac6fd35519b90d83044ae6e448e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Jul 2011 17:04:49 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Jul 2011 17:04:49 +0300    

commit   : 0a5b01a716ef72d1711dbfc4dc9617b7f5e867dc    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Jul 2011 07:37:04 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Jul 2011 07:37:04 +0300    

commit   : 6c76524620d6cca3d667dc16fe65713a107f18c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jul 2011 20:12:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jul 2011 20:12:33 -0400    

commit   : 3e80d0d2e5a0f6a7a971ddcb6e38cc8f0079aed7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jul 2011 19:34:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jul 2011 19:34:24 -0400    

In the example for decode(), show the bytea result in hex format,  
since that's now the default.  Use an E'' string in the example for  
quote_literal(), so that it works regardless of the  
standard_conforming_strings setting.  On the functions-for-binary-strings  
page, leave the examples as-is for readability, but add a note pointing out  
that they are shown in escape format.  Per comments from Thom Brown.  
  
Also, improve the description for encode() and decode() a tad.  
  
Backpatch to 9.0, where bytea_output was introduced.  

commit   : 4eb4b4013d27eaa8bcbd089ce7a20f4bcb2556f3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jul 2011 17:55:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jul 2011 17:55:14 -0400    

commit   : 9b47c67ccde6ec91219ad4aba515a48c136f9568    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 8 Jul 2011 00:36:30 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 8 Jul 2011 00:36:30 +0300    

Dan Ports and Kevin Grittner.  

commit   : fdf8f751e7933c7992cdabc4b8f37d25268f192e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 7 Jul 2011 22:35:09 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 7 Jul 2011 22:35:09 +0300    

Per analysis by Kevin Grittner and Dan Ports, but this approach to fix it  
is different from the original patch.  

commit   : 469345e1e3ae32c8c3c694f9a47cc6edccc5a274    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 7 Jul 2011 21:21:57 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 7 Jul 2011 21:21:57 +0300    

commit   : db43ec43cc4ea68a45ee3364488285edbd790893    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jul 2011 15:10:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jul 2011 15:10:32 -0400    

Per discussion, this structure seems more understandable than what was  
there before.  Make config.sgml and postgresql.conf.sample agree.  
  
In passing do a bit of editorial work on the variable descriptions.  

commit   : a392b5247870da806e511ae2aadb0464509f7afe    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 7 Jul 2011 15:05:21 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 7 Jul 2011 15:05:21 -0400    

The value when BLCKSZ = 8192 is unchanged, but with larger-than-normal  
block sizes we might need to crank things back a bit, as we'll have  
more entries per page than normal in that case.  
  
Kevin Grittner  

commit   : ec1339ea5cb591da53ad7584ffc29e120f6bf74f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jul 2011 13:14:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jul 2011 13:14:46 -0400    

Previous patch only covered the ALTER TABLE changes, not changes in other  
commands; and it neglected to revert the documentation changes.  

commit   : 046d52f7d319419d338fa605f9d6e00b21c5c5ff    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 7 Jul 2011 18:04:37 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 7 Jul 2011 18:04:37 +0300    

If there's a dangerous structure T0 ---> T1 ---> T2, and T2 commits first,  
we need to abort something. If T2 commits before both conflicts appear,  
then it should be caught by OnConflict_CheckForSerializationFailure. If  
both conflicts appear before T2 commits, it should be caught by  
PreCommit_CheckForSerializationFailure. But that is actually run when  
T2 *prepares*. Fix that in OnConflict_CheckForSerializationFailure, by  
treating a prepared T2 as if it committed already.  
  
This is mostly a problem for prepared transactions, which are in prepared  
state for some time, but also for regular transactions because they also go  
through the prepared state in the SSI code for a short moment when they're  
committed.  
  
Kevin Grittner and Dan Ports  

commit   : cb1cc305bc349338f75a549c36041b4c91cf779f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Jul 2011 14:53:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Jul 2011 14:53:16 -0400    

get_op_btree_interpretation assumed this in order to save some duplication  
of code, but it's not true in general anymore because we added <> support  
to btree_gist.  (We still assume it for btree opclasses, though.)  
  
Also, essentially the same logic was baked into predtest.c.  Get rid of  
that duplication by generalizing get_op_btree_interpretation so that it  
can be used by predtest.c.  
  
Per bug report from Denis de Bernardy and investigation by Jeff Davis,  
though I didn't use Jeff's patch exactly as-is.  
  
Back-patch to 9.1; we do not support this usage before that.  

commit   : f8bd267d35503109255c99eae96c86ba8ba1b56f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Jul 2011 18:46:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Jul 2011 18:46:03 -0400    

This was already a runtime failure condition, but it's better to check  
at validation time if possible.  Lightly modified version of a patch  
by Shigeru Hanada.  

commit   : c639d240c00f8d2b6684c03597b30d179d4ab31c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Jul 2011 18:21:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Jul 2011 18:21:12 -0400    

This is useful since a validator might want to require certain options  
to be provided.  The passed array is an empty text array in this case.  
  
Per suggestion by Laurenz Albe, though this is not quite his patch.  

commit   : 457333d5c2f95e9448a2366dab55aab74514295c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 5 Jul 2011 22:56:55 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 5 Jul 2011 22:56:55 +0300    

commit   : 10323f3a592922bce75bc5c38589f0f3427ef232    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Jul 2011 15:54:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Jul 2011 15:54:00 -0400    

As noted by Laurenz Albe, our SGML tools deal rather oddly with chapters  
having just one <sect1>.  Perhaps the tooling could be fixed, but really  
the design of this chapter's introduction is pretty bogus anyhow.  Split  
it into a true introduction and a <sect1> about the FDW functions, so  
that it reads better and dodges the lack-of-a-chapter-TOC problem.  

commit   : c2fe8e70b270ffc8641380e6a16f5824164ce23e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 5 Jul 2011 22:32:12 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 5 Jul 2011 22:32:12 +0300    

commit   : 8b6c89ad13921c7f24e205425f91f6ffda06235a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Jul 2011 15:38:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Jul 2011 15:38:18 -0400    

Modified version of a patch by Shigeru Hanada.  

commit   : 2683a6340de9bda16b436b6d641ea63607ef1009    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Jul 2011 12:04:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Jul 2011 12:04:40 -0400    

handleCopyIn incremented pset.lineno for each line of COPY data read from  
a file.  This is correct when reading from the current script file (i.e.,  
we are doing COPY FROM STDIN followed by in-line data), but it's wrong if  
the data is coming from some other file.  Per bug #6083 from Steve Haslam.  
Back-patch to all supported versions.  

commit   : eb9ca35fbd4fe3b5c6d3dbe006863bd1199c2db2    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 5 Jul 2011 09:45:19 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 5 Jul 2011 09:45:19 +0200    

Per bug #6089, noted by Sidney Cadot  

commit   : 06f04b6dc41354d1eada7b68bab339c908fc97eb    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 5 Jul 2011 00:01:35 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 5 Jul 2011 00:01:35 +0300    

commit   : 413ed2556f7ea21aa7c9d6fe28225455f0e5eac3    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 5 Jul 2011 00:00:14 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 5 Jul 2011 00:00:14 +0300    

commit   : c33acb4f0ae0371a6ee8772d965d13a373cdd7cc    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 4 Jul 2011 22:30:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 4 Jul 2011 22:30:27 +0300    

commit   : ffc50e134a7e67bc48bf512a4bb681d46cc1fe31    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 4 Jul 2011 10:44:07 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 4 Jul 2011 10:44:07 -0400    

commit   : 677f146307a95f862c0c7b51819c79a00af61f95    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 4 Jul 2011 11:11:03 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 4 Jul 2011 11:11:03 +0100    

commit   : 1f7056099728035b55efcd8f889c7b705a68b6de    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 4 Jul 2011 09:30:50 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 4 Jul 2011 09:30:50 +0100    

commit   : 3569e02c98d2802e6fc4912a3ba67dc25e76b6cc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2011 22:12:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2011 22:12:20 -0400    

Somehow, column rolconfig got removed from the documentation of the  
pg_roles view in the 9.0 cycle, although the column is actually still  
there.  In 9.1, we'd also forgotten to document the rolreplication column.  
Spotted by Sakamoto Masahiko.  

commit   : 80d772233760f48119e46d454eae08f58ff1a7f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2011 19:03:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2011 19:03:51 -0400    

Per suggestion from Josh Kupershmidt.  

commit   : 2b9bb6979df9a742243647b6a368125f5ddf496e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Sun, 3 Jul 2011 17:34:47 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Sun, 3 Jul 2011 17:34:47 -0400    

Unlike the relistemp field which it replaced, relpersistence must be  
set correctly quite early during the table creation process, as we  
rely on it quite early on for a number of purposes, including security  
checks.  Normally, this is set based on whether the user enters CREATE  
TABLE, CREATE UNLOGGED TABLE, or CREATE TEMPORARY TABLE, but a  
relation may also be made implicitly temporary by creating it in  
pg_temp.  This patch fixes the handling of that case, and also  
disables creation of unlogged tables in temporary tablespace (such  
table indeed skip WAL-logging, but we reject an explicit  
specification) and creation of relations in the temporary schemas of  
other sessions (which is not very sensible, and didn't work right  
anyway).  
  
Report by Amit Khandekar.  

commit   : ffd3f13fab9579c1460d7100a16809a3159e6504    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2011 13:55:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2011 13:55:02 -0400    

Certain subdirectories do not get built if corresponding options are not  
selected at configure time.  However, "make distprep" should visit such  
directories anyway, so that constructing derived files to be included in  
the tarball happens without requiring all configure options to be given  
in the tarball build script.  Likewise, it's better if cleanup actions  
unconditionally visit all directories (for example, this ensures proper  
cleanup if someone has done a manual make in such a subdirectory).  
  
To handle this, set up a convention that subdirectories that are  
conditionally included in SUBDIRS should be added to ALWAYS_SUBDIRS  
instead when they are excluded.  
  
Back-patch to 9.1, so that plpython's spiexceptions.h will get provided  
in 9.1 tarballs.  There don't appear to be any instances where distprep  
actions got missed in previous releases, and anyway this fix requires  
gmake 3.80 so we don't want to apply it before 9.1.  

commit   : 6b23ba1093d298a41463a24f091c6f86be406449    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 29 Jun 2011 09:26:14 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 29 Jun 2011 09:26:14 +0300    

We had previously (af26857a2775e7ceb0916155e931008c2116632f)  
established the U.S. spellings as standard.  

commit   : 678a6d03441fc5acb18fdd43afdd2dd4145c0593    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 27 Jun 2011 15:46:21 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 27 Jun 2011 15:46:21 +0300    

commit   : 158d071b28529509b0a77317a24ef55fb84480d9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 1 Jul 2011 23:09:13 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 1 Jul 2011 23:09:13 -0400    

commit   : 3b80219e96f2d2b696ed8dc395d468b38d8ef592    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jun 2011 19:46:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jun 2011 19:46:58 -0400    

Such a condition is unsatisfiable in combination with any other type of  
btree-indexable condition (since we assume btree operators are always  
strict).  8.3 and 8.4 had an explicit test for this, which I removed in  
commit 29c4ad98293e3c5cb3fcdd413a3f4904efff8762, mistakenly thinking that  
the case would be subsumed by the more general handling of IS (NOT) NULL  
added in that patch.  Put it back, and improve the comments about it, and  
add a regression test case.  
  
Per bug #6079 from Renat Nasyrov, and analysis by Dean Rasheed.  

commit   : f01e3d3a414f909762ab840719aeb8ae291aab5a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 29 Jun 2011 21:43:53 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 29 Jun 2011 21:43:53 +0300    

This has the user-visible effect that if a seq scan is initialized in the  
executor, but never executed, we now acquire the predicate lock on the heap  
relation anyway. We could avoid that by taking the lock on the first  
heap_getnext() call instead, but it doesn't seem worth the trouble given  
that it feels more natural to do it in heap_beginscan().  
  
Also, remove the retail PredicateLockTuple() calls from heap_getnext(). In  
a seqscan, started with heap_begin(), we're holding a whole-relation  
predicate lock on the heap so there's no need to lock the tuples  
individually.  
  
Kevin Grittner and me  

commit   : 1aa447a1e1273e51f1bb34e085c021941db86212    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 29 Jun 2011 21:40:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 29 Jun 2011 21:40:27 +0300    

Kevin Grittner  

commit   : 3ec6e00ece5fc7483f8890306005f97a2c640861    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 29 Jun 2011 19:35:11 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 29 Jun 2011 19:35:11 +0200    

Per bug #6082, reported by Steve Haslam  

commit   : ca7e04b0b9943d5c33d2e993ff685d45b5bddbbd    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 27 Jun 2011 22:15:07 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Mon, 27 Jun 2011 22:15:07 +0100    

Noah Misch and Simon Riggs  

commit   : 379352602ce1f247d1bed41b62baad4e1ee6d767    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 27 Jun 2011 10:38:45 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 27 Jun 2011 10:38:45 -0400    

As noted by Christian Ullrich.  

commit   : e4fb58f894b75829f9475aac6991002c785de4c0    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sat, 25 Jun 2011 15:40:49 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sat, 25 Jun 2011 15:40:49 -0700    

commit   : ea41b8c822df5a2e4862c76d72937df9b62f1a99    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Jun 2011 16:06:57 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Jun 2011 16:06:57 -0400    

Explain that querying pg_locks does not simultaneously lock both the  
normal lock manager and the predicate lock manager.  
  
Per discussion with Kevin Grittner.  

commit   : 50016867a30632cfeaa79cf03b5d183383ea220a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 23 Jun 2011 19:57:45 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 23 Jun 2011 19:57:45 -0400    

Backpatch to 9.1 and 9.0.  

commit   : 1c20ba4f41faccbd11c90c4220ef6ae11a574ba5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2011 23:03:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2011 23:03:11 -0400    

s/const//g wasn't exactly what I was suggesting here ... parameter  
declarations of the form "const structtype *param" are good and useful,  
so put those occurrences back.  Likewise, avoid casting away the const  
in a "const void *" parameter.  

commit   : d9db32401c1477fb63fb47a376fc0d08605dcc9b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 22 Jun 2011 20:48:35 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 22 Jun 2011 20:48:35 -0400    

Backpatch to 9.1.  
  
Dan McGee  

commit   : c6635bd7ba4618b7d8507c77d2226f889e3d37d9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 22 Jun 2011 17:47:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 22 Jun 2011 17:47:24 -0400    

Backpatch to 9.1.  
  
Dan McGee  

commit   : 3ccd16c5a92d9aea32a883f91e8993d61adcb14d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 22 Jun 2011 14:49:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 22 Jun 2011 14:49:04 -0400    

Backpatch to 9.1 and 9.0.  
  
Dan McGee  

commit   : 979d6c9cad8c59580c1c96eb04ce0f4914006a46    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2011 13:20:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2011 13:20:03 -0400    

Per bug #6073 from Hartmut Raschick.  

commit   : 25db27808814f474e2080eef8bac068317b7caf6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2011 13:08:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Jun 2011 13:08:08 -0400    

backend/Makefile was treating errcodes.h as a header always generated  
during build, but actually it's a header provided in tarballs.  Hence,  
must use the absolute-symlink recipe, not the relative-symlink one.  
Per bug #6072 from Hartmut Raschick.  

commit   : fbaa7a23e4d225f3422f5ede9897d49cb7ca3ff5    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 22 Jun 2011 12:18:39 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 22 Jun 2011 12:18:39 +0300    

commit   : 66370f5158f2bca02202376204bfccdfdafd2bd4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 21 Jun 2011 21:54:36 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 21 Jun 2011 21:54:36 -0400    

Kevin Grittner, with additional wordsmithing by me.  

commit   : 0272fd1c008a616fd6f0c361645a335f86c5fe29    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jun 2011 18:00:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jun 2011 18:00:09 -0400    

Fix some grammatical issues, try to clarify a couple of proofs, make the  
terminology more consistent.  

commit   : a0b5146b25cd5924c5e5107c06b8777eec9f0a2f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 22 Jun 2011 00:33:20 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 22 Jun 2011 00:33:20 +0300    

commit   : 567049a76493c7c60eddd1c65c8aa946c6811ed3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jun 2011 14:41:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jun 2011 14:41:05 -0400    

A password containing a character with the high bit set was misprocessed  
on machines where char is signed (which is most).  This could cause the  
preceding one to three characters to fail to affect the hashed result,  
thus weakening the password.  The result was also unportable, and failed  
to match some other blowfish implementations such as OpenBSD's.  
  
Since the fix changes the output for such passwords, upstream chose  
to provide a compatibility hack: password salts beginning with $2x$  
(instead of the usual $2a$ for blowfish) are intentionally processed  
"wrong" to give the same hash as before.  Stored password hashes can  
thus be modified if necessary to still match, though it'd be better  
to change any affected passwords.  
  
In passing, sync a couple other upstream changes that marginally improve  
performance and/or tighten error checking.  
  
Back-patch to all supported branches.  Since this issue is already  
public, no reason not to commit the fix ASAP.  

commit   : 35dd6d48eccbfcd2cb5b4e571e760e1c1f1534fc    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 21 Jun 2011 17:07:10 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 21 Jun 2011 17:07:10 +0300    

commit   : 390c52131b7a42d7b5528d0435d7f6279bdf0ed0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 21 Jun 2011 14:32:11 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 21 Jun 2011 14:32:11 +0300    

One of the prepared_xacts regression tests actually hits this bug. I  
removed the anomaly from the duplicate-gids test so that it fails in the  
intended way, and added a new test to check serialization failures with  
a prepared transaction.  
  
Dan Ports  

commit   : 0d905db20b3201bec3ea69951014b473f92223c7    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 21 Jun 2011 14:12:40 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 21 Jun 2011 14:12:40 +0300    

Dan Ports  

commit   : 9d6e6fededbedb018caf9871cc448dc173b20ea6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jun 2011 16:27:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jun 2011 16:27:36 -0400    

Also be more careful about markup: use & not just &.  

commit   : 6c560bef763f562a38fc629e54d0e20673efb9c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jun 2011 14:33:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jun 2011 14:33:20 -0400    

When recursing after an optimization in pull_up_sublinks_qual_recurse, the  
available_rels value passed down must include only the relations that are  
in the righthand side of the new SEMI or ANTI join; it's incorrect to pull  
up a sub-select that refers to other relations, as seen in the added test  
case.  Per report from BangarRaju Vadapalli.  
  
While at it, rethink the idea of recursing below a NOT EXISTS.  That is  
essentially the same situation as pulling up ANY/EXISTS sub-selects that  
are in the ON clause of an outer join, and it has the same disadvantage:  
we'd force the two joins to be evaluated according to the syntactic nesting  
order, because the lower join will most likely not be able to commute with  
the ANTI join.  That could result in having to form a rather large join  
product, whereas the handling of a correlated subselect is not quite that  
dumb.  So until we can handle those cases better, #ifdef NOT_USED that  
case.  (I think it's okay to pull up in the EXISTS/ANY cases, because SEMI  
joins aren't so inflexible about ordering.)  
  
Back-patch to 8.4, same as for previous patch in this area.  Fortunately  
that patch hadn't made it into any shipped releases yet.