PostgreSQL 9.0.5 commit log

Stamp 9.0.5.

  
commit   : 8522403c5cd2351a1292b868a85aeec0aab5f2b3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Sep 2011 18:00:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Sep 2011 18:00:48 -0400    

Click here for diff

  
  

Update release notes for 9.1.1, 9.0.5, 8.4.9, 8.3.16, 8.2.22.

  
commit   : 94a419558371951e7bfaf291aa0dc6dba1f57433    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Sep 2011 17:39:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Sep 2011 17:39:25 -0400    

Click here for diff

  
Man, we fixed a lotta bugs since April.  
  

Translation updates

  
commit   : b43bb707cc75be5e751875219657f5af9bbd4adb    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 22 Sep 2011 23:10:16 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 22 Sep 2011 23:10:16 +0300    

Click here for diff

  
  

gistendscan() forgot to free so->giststate.

  
commit   : b04214f6cf3a39f45579aba5b7e687fa4f44c84b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Sep 2011 04:28:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 Sep 2011 04:28:01 -0400    

Click here for diff

  
This oversight led to a massive memory leak --- upwards of 10KB per tuple  
--- during creation-time verification of an exclusion constraint based on a  
GIST index.  In most other scenarios it'd just be a leak of 10KB that would  
be recovered at end of query, so not too significant; though perhaps the  
leak would be noticeable in a situation where a GIST index was being used  
in a nestloop inner indexscan.  In any case, it's a real leak of long  
standing, so patch all supported branches.  Per report from Harald Fuchs.  
  

deflist_to_tuplestore dumped core on an option with no value.

  
commit   : cac73320ef0f35304e2dcade0fe1d32c07cb765f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Sep 2011 11:36:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Sep 2011 11:36:57 -0400    

Click here for diff

  
Make it return NULL for the option_value, instead.  
  
Per report from Frank van Vugt.  Back-patch to 8.4 where this code was  
added.  
  

Fix permissions on pg_largeobject_metadata.h in 9.0 branch.

  
commit   : 4de174d4bfa8e162cf64fb9bf7393fea05b0dee7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Sep 2011 13:17:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Sep 2011 13:17:12 -0400    

Click here for diff

  
For some reason it was 0755 instead of 0644.  
  

Add missing format argument to ecpg_log() call

  
commit   : ba24de13f6b4a1a2ceb6230840330e4192312e09    
  
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    

Click here for diff

  
  

Fix corner case bug in numeric to_char().

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

Click here for diff

  
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.  
  

In pg_upgrade, disallow migration of 8.3 clusters using contrib/ltree because its internal format was changed in 8.4.

  
commit   : c3106a340f3177105b80a0a6e878eba1986ae9fe    
  
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    

Click here for diff

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

Revert documentation patch about NEW/OLD and triggers.

  
commit   : 336059fc0af59f60d1e4c4a1f28a06f97a0e30a9    
  
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    

Click here for diff

  
Backpatch to 9.0 and 9.1.  
  
Patch from Josh Kupershmidt.  
  

Properly document the existance of OLD/NEW trigger pl/pgsql trigger fields.

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

Click here for diff

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

Fix plpgsql “PERFORM” markup.

  
commit   : 665af1ac5aab4b06f5626af22a90102715258687    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Sep 2011 15:20:17 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 Sep 2011 15:20:17 -0400    

Click here for diff

  
Backpatch to 9.0 and 9.1.  
  

Avoid possibly accessing off the end of memory in SJIS2004 conversion.

  
commit   : d5e429b128b0e222f9458a7880427a60da065fa3    
  
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    

Click here for diff

  
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.  
  

Avoid possibly accessing off the end of memory in examine_attribute().

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

Click here for diff

  
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.  
  

Document PERFORM limitation when using WITH queries.

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

Click here for diff

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

Update type-conversion documentation for long-ago changes.

  
commit   : 01543329514475e2c42d52891ff4245bb9f5d83c    
  
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    

Click here for diff

  
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.  
  

Properly document semphore requirements by accounting for worker processes.

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

Click here for diff

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

Update time zone data files to tzdata release 2011i.

  
commit   : e6d4288c514bc7bab1d48bc5a733606d1f57dba9    
  
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    

Click here for diff

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

Document that contrib/pgtrgm only processes ASCII alphanumeric characters.

  
commit   : 3de09ddac58882d9abc5e3327e4d2b0b1238ab54    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Sep 2011 13:24:47 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 5 Sep 2011 13:24:47 -0400    

Click here for diff

  
Backpatch to 9.0 and 9.1.  
  

Guard against using plperl’s Makefile without specifying –with-perl.

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

Click here for diff

  
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.  
  

Fix typo in pg_srand48 (srand48 in older branches).

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

Click here for diff

  
">" 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.  
  

Fix brace indentation of commit f8c74422010e63506fa69635ea61920bc042b70e to fit PostgreSQL style.

  
commit   : 2cda30e757a95f2c2dfa9d3a1726959fa6b02357    
  
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    

Click here for diff

  
  

In ecpglib restore LC_NUMERIC in case of an error.

  
commit   : f8c74422010e63506fa69635ea61920bc042b70e    
  
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    

Click here for diff

  
  

Move the line to undefine setlocale() macro on Win32 outside USE_REPL_SNPRINTF ifdef block. It has nothing to do with whether the replacement snprintf function is used. It caused no live bug, because the replacement snprintf function is always used on Win32, but it was nevertheless misplaced.

  
commit   : a02e40990433e59dee14129c119184dcbca4c2e3    
  
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    

Click here for diff

  
  

Further repair of eqjoinsel ndistinct-clamping logic.

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

Click here for diff

  
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.  
  

Fix pg_upgrade to preserve toast relfrozenxids for old 8.3 servers.

  
commit   : e724b969d82862a08255ba6f2921a7a66e65a852    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2011 21:50:00 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 31 Aug 2011 21:50:00 -0400    

Click here for diff

  
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.  
  

Improve eqjoinsel’s ndistinct clamping to work for multiple levels of join.

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

Click here for diff

  
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.  
  

Fix a missed case in code for “moving average” estimate of reltuples.

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

Click here for diff

  
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.  
  

Actually, all of parallel restore’s limitations should be tested earlier.

  
commit   : 2de0fdeb68d7176df35a880c9180bd9e2d9eca4c    
  
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    

Click here for diff

  
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.  
  

Be more user-friendly about unsupported cases for parallel pg_restore.

  
commit   : fbf776a2eb5a7dcca218458cb2139b97918382d5    
  
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    

Click here for diff

  
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.  
  

Don’t assume that “E” response to NEGOTIATE_SSL_CODE means pre-7.0 server.

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

Click here for diff

  
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.  
  

Ensure we discard unread/unsent data when abandoning a connection attempt.

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

Click here for diff

  
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.  
  

Fix potential memory clobber in tsvector_concat().

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

Click here for diff

  
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.  
  

In pg_upgrade, limit schema name filter to include toast tables. Bug introduced recently when trying to filter out temp tables.

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

Click here for diff

  
Backpatch to 9.0 and 9.1.  
  

Fix psql lexer to avoid use of backtracking.

  
commit   : 9354f5b76acf37c96ed0173ff8ab3e415bae2b04    
  
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    

Click here for diff

  
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.  
  

Properly quote SQL/MED generic options in pg_dump output.

  
commit   : b7cd5c836ae952b5911eac9ec5f888779a2d0b81    
  
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    

Click here for diff

  
Shigeru Hanada  
  

Fix pgstatindex() to give consistent results for empty indexes.

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

Click here for diff

  
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.  
  

Add recovery.conf to the index in the user manual.

  
commit   : 7ec0258091c7d1f3d109c9a7a1016e702b744ebe    
  
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    

Click here for diff

  
Fujii Masao  
  

Fix trigger WHEN conditions when both BEFORE and AFTER triggers exist.

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

Click here for diff

  
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.  
  

Fix performance problem when building a lossy tidbitmap.

  
commit   : 706493a1f7cbd9c7d3a792fd5066b55c145b9b01    
  
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    

Click here for diff

  
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.  
  

Change PyInit_plpy to external linkage

  
commit   : d4c24254fab0b9908211f990c4239664f3ed5630    
  
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    

Click here for diff

  
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.  
  

Forget about targeting catalog cache invalidations by tuple TID.

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

Click here for diff

  
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.  
  

Fix incorrect order of operations during sinval reset processing.

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

Click here for diff

  
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.  
  

Preserve toast value OIDs in toast-swap-by-content for CLUSTER/VACUUM FULL.

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

Click here for diff

  
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.  
  

Fix race condition in relcache init file invalidation.

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

Click here for diff

  
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.  
  

In pg_upgrade, avoid dumping orphaned temporary tables. This makes the pg_upgrade schema matching pattern match pg_dump/pg_dumpall.

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

Click here for diff

  
Fix for 9.0, 9.1, and 9.2.  
  

Fix unsafe order of operations in foreign-table DDL commands.

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

Click here for diff

  
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.  
  

Fix incorrect timeout handling during initial authentication transaction.

  
commit   : 739cbdd9c38252fe2e8241a704f9d9f9a5363e74    
  
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    

Click here for diff

  
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.  
  

Fix nested PlaceHolderVar expressions that appear only in targetlists.

  
commit   : 8a14bdb10f0a9b123e5c6f70f33334b132b3da29    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Aug 2011 00:49:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Aug 2011 00:49:04 -0400    

Click here for diff

  
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.  
  

Fix thinko in documentation of local_preload_libraries.

  
commit   : f60078232d587d62c7343780ce1c470e5f5c66a5    
  
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    

Click here for diff

  
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.  
  

Fix markup for recent wal_level clarification.

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

Click here for diff

  
Backpatch to 9.1 and 9.0.  
  

In documentaiton, clarify which commands have reduced WAL volume for wal_level = minimum.

  
commit   : 072e6076d10955da5ee46416607a8ff19afd6b40    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 4 Aug 2011 12:06:54 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 4 Aug 2011 12:06:54 -0400    

Click here for diff

  
Backpatch to 9.1 and 9.0.  
  

Move CheckRecoveryConflictDeadlock() call to a safer place.

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

Click here for diff

  
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.  
  

Fix incorrect initialization of ProcGlobal->startupBufferPinWaitBufId.

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

Click here for diff

  
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.  
  

Avoid integer overflow when LIMIT + OFFSET >= 2^63.

  
commit   : f00fbad6bd43141faae05cd13a518fd28ae94673    
  
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    

Click here for diff

  
This fixes bug #6139 reported by Hitoshi Harada.  
  

Fix pg_restore’s direct-to-database mode for standard_conforming_strings.

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

Click here for diff

  
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.  
  

Fix typo.

  
commit   : bc9d2e7c4ae1cb4f0392194f539ba3e6847f42f5    
  
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    

Click here for diff

  
Noted by Josh Kupershmidt.  
  

Add missing newlines at end of error messages

  
commit   : 9df8ce848245592b6b8ac919319be3167ef774ac    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 26 Jul 2011 23:28:44 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 26 Jul 2011 23:28:44 +0300    

Click here for diff

  
  

Clarify which relkinds accept column comments.

  
commit   : 6f8f9c2bdd30eef9c3f1858fb413f5f4e39d6010    
  
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    

Click here for diff

  
Per discussion with Josh Kupershmidt.  
  

Fix previous patch so it also works if not USE_SSL (mea culpa).

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

Click here for diff

  
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.  
  

Improve libpq’s error reporting for SSL failures.

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

Click here for diff

  
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.  
  

Use OpenSSL’s SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER flag.

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

Click here for diff

  
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.  
  

Fix PQsetvalue() to avoid possible crash when adding a new tuple.

  
commit   : fe0e1a633a164cfc0cddae0ee318d40230a491b0    
  
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    

Click here for diff

  
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  
  

In pg_upgrade, fix the -l/log option to work on Windows.

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

Click here for diff

  
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.  
  

Adapted expected result for latest change to ecpglib.

  
commit   : 3089a3a1011dcf5dfc34143892f482e7c8f8e797    
  
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    

Click here for diff

  
  

Made ecpglib write double with a precision of 15 digits.

  
commit   : 77a7a57f7fb8f9c1fc6449938f459d17cc2cfc80    
  
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    

Click here for diff

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

Fix SSPI login when multiple roundtrips are required

  
commit   : d662e3970d265a9edc645d2755cf427ed33498c1    
  
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    

Click here for diff

  
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  
  

Fix two ancient bugs in GiST code to re-find a parent after page split:

  
commit   : 75f386df50939072c060a1656b1209c13b5545f8    
  
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    

Click here for diff

  
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.  
  

In planner, don’t assume that empty parent tables aren’t really empty.

  
commit   : 0dd46a776651b2cb49c120a2deb169526ad4afb8    
  
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    

Click here for diff

  
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.  
  

Fix another oversight in logging of changes in postgresql.conf settings.

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

Click here for diff

  
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   : d1ca2a1ee93916d69836d7a1924aa7601bcfb635    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jul 2011 19:34:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jul 2011 19:34:28 -0400    

Click here for diff

  
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.  
  

Fix use of unportable %m format

  
commit   : f1d869276f7c256ade9d5dd6a4d8143821cdac1c    
  
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    

Click here for diff

  
  

Fix psql’s counting of script file line numbers during COPY.

  
commit   : 245b5f1794eff632f9dd1252f29f65aad02e871d    
  
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    

Click here for diff

  
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.  
  

Fix typo in sslmode documentation

  
commit   : 1e7b52d753f84ed46095a68f23e992a95e41f13f    
  
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    

Click here for diff

  
Per bug #6089, noted by Sidney Cadot  
  

Clarify that you need ActiveState perl 5.8 or later to build on Windows.

  
commit   : 6bb8659ecf358bc83ed141120e0a6c73724fe0e4    
  
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    

Click here for diff

  
  

Back-patch Fix bat file quoting of %ENV from commit 19b7fac8.

  
commit   : 1e8b78e521e2dc12bd1fd5831e5b9b427a07e70c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 4 Jul 2011 10:12:27 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 4 Jul 2011 10:12:27 -0400    

Click here for diff

  
  

Fix omissions in documentation of the pg_roles view.

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

Click here for diff

  
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.  
  

Fix EXPLAIN to handle gating Result nodes within inner-indexscan subplans.

  
commit   : 789d3d4541e95c6079a55196bd63a6ab90e57c7c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2011 01:35:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Jul 2011 01:35:15 -0400    

Click here for diff

  
It is possible for a NestLoop plan node to pass an OUTER Var into an  
"inner indexscan" that is an Append construct (derived from an inheritance  
tree or UNION ALL subquery).  The OUTER tuple is then passed down at  
runtime to the leaf indexscan node(s) where it will actually be used.  
EXPLAIN has to likewise pass the information about the nestloop's outer  
subplan down through the Append node, else it will fail to print the  
outer-reference Vars (with complaints like "bogus varno: 65001").  
  
However, there was a case missed in all this: we could also have gating  
Result nodes that were inserted into the appendrel plan tree to deal with  
pseudoconstant qual conditions.  So EXPLAIN has to pass down the outer plan  
node to a Result's subplan, too.  Per example from Jon Nelson.  
  
The problem is gone in 9.1 because we replaced the nestloop outer-tuple  
kluge with a Param-based data transfer mechanism.  Also, so far as I can  
tell, the case can't happen before 8.4 because of restrictions on what  
sorts of appendrel members could be pulled up into the parent query.  
So this patch is only needed for 8.4 and 9.0.  
  

In pg_upgrade 9.0 and 9.1, document suggestion of using a non-default port number to avoid unintended client connections.

  
commit   : 46242281b44c7546b321ba503b8d99cc299ca746    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 1 Jul 2011 23:09:14 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 1 Jul 2011 23:09:14 -0400    

Click here for diff

  
  

Restore correct btree preprocessing of “indexedcol IS NULL” conditions.

  
commit   : bbfcc71496051651accb71540130c6d36377a692    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jun 2011 19:47:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jun 2011 19:47:07 -0400    

Click here for diff

  
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.  
  

Protect pg_stat_reset_shared() against NULL input

  
commit   : cbfd82aad252fd86b560a7b7c3d87260a34a595e    
  
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    

Click here for diff

  
Per bug #6082, reported by Steve Haslam  
  

Reduce impact of btree page reuse on Hot Standby by fixing off-by-1 error. WAL records of type XLOG_BTREE_REUSE_PAGE were generated using a latestRemovedXid one higher than actually needed because xid used was page opaque->btpo.xact rather than an actually removed xid. Noticed on an otherwise quiet system by Noah Misch.

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

Click here for diff

  
Noah Misch and Simon Riggs  
  

  
commit   : 3a2906545f839aaf3a49f08a6f8d2cb1f841168f    
  
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    

Click here for diff

  
Backpatch to 9.1 and 9.0.  
  

Fix pg_upgrade status message capitalization mistake.

  
commit   : 7412f5cd29b8da364e88f5a63a17c8573dbad73b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 22 Jun 2011 14:49:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 22 Jun 2011 14:49:09 -0400    

Click here for diff

  
Backpatch to 9.1 and 9.0.  
  
Dan McGee  
  

Apply upstream fix for blowfish signed-character bug (CVE-2011-2483).

  
commit   : 3246a1791de01e6adbb1ee295dae65fa4fe12c6c    
  
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    

Click here for diff

  
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.  
  

Fix missed use of “cp -i” in an example, per Fujii Masao.

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

Click here for diff

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

Fix thinko in previous patch for optimizing EXISTS-within-EXISTS.

  
commit   : 5f129cf942bb16d5e6d9db01db1789c98116baa1    
  
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    

Click here for diff

  
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.  
  

Fixed string in German translation that causes segfault.

  
commit   : b8e287711c2f0ce2aed0c1eeb50bc0154025c289    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Mon, 20 Jun 2011 13:53:15 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Mon, 20 Jun 2011 13:53:15 +0200    

Click here for diff

  
Applied patch by Christoph Berg <cb@df7cb.de> to replace placeholder "%s" by  
correct string.  
  

Fix thinko in previous patch to always update pg_class.reltuples/relpages.

  
commit   : ccdce73b2145a0a762188709b89ca73e7d2efcd8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jun 2011 14:01:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jun 2011 14:01:01 -0400    

Click here for diff

  
I mis-simplified the test where ANALYZE decided if it could get away  
without doing anything: under the new regime, that's never allowed.  Per  
bug #6068 from Jeff Janes.  Back-patch to 8.4, just like previous patch.  
  

Don’t use “cp -i” in the example WAL archive_command.

  
commit   : ae7fc61bc3138d4e938f0faf353a92f0fb4d89ca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jun 2011 19:13:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jun 2011 19:13:12 -0400    

Click here for diff

  
This is a dangerous example to provide because on machines with GNU cp,  
it will silently do the wrong thing and risk archive corruption.  Worse,  
during the 9.0 cycle somebody "improved" the discussion by removing the  
warning that used to be there about that, and instead leaving the  
impression that the command would work as desired on most Unixen.  
It doesn't.  Try to rectify the damage by providing an example that is safe  
most everywhere, and then noting that you can try cp -i if you want but  
you'd better test that.  
  
In back-patching this to all supported branches, I also added an example  
command for Windows, which wasn't provided before 9.0.  
  

Obtain table locks as soon as practical during pg_dump.

  
commit   : 7975f2baa955397fbeb64b5301235ed1dd0f9be6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jun 2011 18:19:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jun 2011 18:19:14 -0400    

Click here for diff

  
For some reason, when we (I) added table lock acquisition to pg_dump,  
we didn't think about making it happen as soon as possible after the  
start of the transaction.  What with subsequent additions, there was  
actually quite a lot going on before we got around to that; which sort  
of defeats the purpose.  Rearrange the order of calls in dumpSchema()  
to close the risk window as much as we easily can.  Back-patch to all  
supported branches.  
  

Add overflow checks to int4 and int8 versions of generate_series().

  
commit   : 51328d56a412578480bad0fb65b7cf58816d71b8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2011 14:28:45 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 17 Jun 2011 14:28:45 -0400    

Click here for diff

  
The previous code went into an infinite loop after overflow.  In fact,  
an overflow is not really an error; it just means that the current  
value is the last one we need to return.  So, just arrange to stop  
immediately when overflow is detected.  
  
Back-patch all the way.  
  

Respect Hot Standby controls while recycling btree index pages. Btree pages were recycled after VACUUM deletes all records on a page and then a subsequent VACUUM occurs after the RecentXmin horizon is reached. Using RecentXmin meant that we did not respond correctly to the user controls provide to avoid Hot Standby conflicts and so spurious conflicts could be generated in some workload combinations. We now reuse pages only when we reach RecentGlobalXmin, which can be much later in the presence of long running queries and is also controlled by vacuum_defer_cleanup_age.

  
commit   : 1c7ddbf3501e989d6b783dc516c44c3535dbe03f    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 16 Jun 2011 10:12:50 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 16 Jun 2011 10:12:50 +0100    

Click here for diff

  
Noah Misch and Simon Riggs  
  

Fix failure to account for memory used by tuplestore_putvalues().

  
commit   : 669ac03af62328e4eb572dacb8ba319414ef1211    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Jun 2011 14:05:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Jun 2011 14:05:22 -0400    

Click here for diff

  
This oversight could result in a tuplestore using much more than the  
intended amount of memory.  It would only happen in a code path that loaded  
a tuplestore via tuplestore_putvalues(), and many of those won't emit huge  
amounts of data; but cases such as holdable cursors and plpgsql's RETURN  
NEXT command could have the problem.  The fix ensures that the tuplestore  
will switch to write-to-disk mode when it overruns work_mem.  
  
The potential overrun was finite, because we would still count the space  
used by the tuple pointer array, so the tuplestore code would eventually  
flip into write-to-disk mode anyway.  When storing wide tuples we would  
go far past the expected work_mem usage before that happened; but this  
may account for the lack of prior reports.  
  
Back-patch to 8.4, where tuplestore_putvalues was introduced.  
  
Per bug #6061 from Yann Delorme.  
  

  
commit   : 6122849416fdde839ca44ca50906642708c5db21    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jun 2011 18:14:56 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jun 2011 18:14:56 -0400    

Click here for diff

  
Per suggestsion from #postgresql irc channel.  
  
Backpatch to 9.0.  
  

Fix assorted issues with build and install paths containing spaces.

  
commit   : 52463867275cfd40a29c0705f43ce67f54c3f78e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Jun 2011 12:50:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Jun 2011 12:50:16 -0400    

Click here for diff

  
Apparently there is no buildfarm critter exercising this case after all,  
because it fails in several places.  With this patch, build, install,  
check-world, and installcheck-world pass for me on OS X.  
  

Fix grammatical mistake introduced by previous commit

  
commit   : a2b354afb603ad9b1e527ed6e2f7180271f97fa2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 14 Jun 2011 13:48:23 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 14 Jun 2011 13:48:23 -0400    

Click here for diff

  
Per note from Tom  
  

Mention DROP TABLE as well as ALTER TABLE NO INHERIT

  
commit   : 247fd8105aa6bcb3201dbc19e206fcb27b940040    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 14 Jun 2011 11:20:52 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 14 Jun 2011 11:20:52 -0400    

Click here for diff

  
... when talking about how good they are in replacement of bulk DELETE  
in partitioned setups.  
  
The original wording was a bit confusing.  
  
Per an observation from David Wheeler.  
  

Fix aboriginal copy-paste mistake in error message

  
commit   : a03f1d399dbfdc87798742329270d99962216100    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 13 Jun 2011 17:50:30 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 13 Jun 2011 17:50:30 -0400    

Click here for diff

  
Spotted by Jaime Casanova  
  

Expand warnings on locks acquired by CREATE INDEX CONCURRENTLY

  
commit   : 2602e637505ed9b4500bb0f17abcb630b2b711b3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 13 Jun 2011 17:12:26 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 13 Jun 2011 17:12:26 -0400    

Click here for diff

  
The previous wording wasn't explicit enough, which could misled readers  
into thinking that the locks acquired are more restricted in nature than  
they really are.  The resulting optimism can be damaging to morale when  
confronted with reality, as has been observed in the field.  
  
Greg Smith  
  

Remove parentheses from mention of current_schemas function.

  
commit   : 6350d75bf2faa81cf7b8ccd3ceeb5fe4adefc7f5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 13 Jun 2011 13:02:54 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 13 Jun 2011 13:02:54 -0400    

Click here for diff

  
This is more consistent with what we do elsewhere, and hopefully avoids  
creating the perception that current_schemas takes no arguments.  
  
As suggested by Brendan Jurd  
  

Add doc cross-reference to search_path discussion of current_schemas().

  
commit   : c06bdaf92c78d3d5bc6efdc4474abbf33ab7a047    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 13 Jun 2011 12:37:49 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 13 Jun 2011 12:37:49 -0400    

Click here for diff

  
Brendan Jurd  
  

Work around gcc 4.6.0 bug that breaks WAL replay.

  
commit   : 45d792f70272ed57b932816562f31c2f79426c2a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Jun 2011 17:03:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Jun 2011 17:03:11 -0400    

Click here for diff

  
ReadRecord's habit of using both direct references to tmpRecPtr and  
references to *RecPtr (which is pointing at tmpRecPtr) triggers an  
optimization bug in gcc 4.6.0, which apparently has forgotten about  
aliasing rules.  Avoid the compiler bug, and make the code more readable  
to boot, by getting rid of the direct references.  Improve the comments  
while at it.  
  
Back-patch to all supported versions, in case they get built with 4.6.0.  
  
Tom Lane, with some cosmetic suggestions from Alex Hunsaker  
  

Use the correct eventlog severity for error

  
commit   : cdd08887b9f160271f8d6695d5914c53814105c6    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 9 Jun 2011 18:21:38 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 9 Jun 2011 18:21:38 +0200    

Click here for diff

  
  

Support silent mode for service registrations on win32

  
commit   : 15fe829b23ad1871ed0b27d807371cbd37768289    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 9 Jun 2011 18:18:45 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 9 Jun 2011 18:18:45 +0200    

Click here for diff

  
Using -s when registering a service will now suppress  
the application eventlog entries stating that the service  
is starting and started.  
  
MauMau  
  

Fix documentation of information_schema.element_types

  
commit   : ffa653b945cb6a03e64b7c7c0d61b7ee916ada1b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 9 Jun 2011 07:24:14 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 9 Jun 2011 07:24:14 +0300    

Click here for diff

  
The documentation of the columns collection_type_identifier and  
dtd_identifier was wrong.  This effectively reverts commits  
8e1ccad51901e83916dae297cd9afa450957a36c and  
57352df66d3a0885899d39c04c067e63c7c0ba30 and updates the name  
array_type_identifier (the name in SQL:1999) to  
collection_type_identifier.  
  
closes bug #5926  
  

Allow building with perl 5.14.

  
commit   : cb252c2acd415d304e3254e99f82058d11a69e04    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 4 Jun 2011 19:35:04 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 4 Jun 2011 19:35:04 -0400    

Click here for diff

  
Patch from Alex Hunsaker.  
  

Fix documentation reference to “above” example

  
commit   : 39dbc62adedc8758580d099e4a21f1e5a4a0bf85    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 4 Jun 2011 23:12:27 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 4 Jun 2011 23:12:27 +0300    

Click here for diff

  
found by Thom Brown  
  

More ECPG documentation fixes

  
commit   : ec688fd346e7f3413bd69ff2413a1e6da6aec402    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 4 Jun 2011 22:29:26 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 4 Jun 2011 22:29:26 +0300    

Click here for diff

  
Marc Cousin  
  

ECPG documentation fix

  
commit   : 843c280626ae97dbf521d27992abfdfdfe69e279    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 4 Jun 2011 22:11:20 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 4 Jun 2011 22:11:20 +0300    

Click here for diff

  
Marc Cousin, Satoshi Nagayasu  
  

Expose the “VALUES” alias that we generate for a stand-alone VALUES list.

  
commit   : ab1aaf3d220645501a33a4f044d42507f280c8d7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jun 2011 15:48:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jun 2011 15:48:25 -0400    

Click here for diff

  
We were trying to make that strictly an internal implementation detail,  
but it turns out that it's exposed anyway when dumping a view defined  
like  
	CREATE VIEW test_view AS VALUES (1), (2), (3) ORDER BY 1;  
This comes out as  
	CREATE VIEW ... ORDER BY "*VALUES*".column1;  
which fails to parse when reloading the dump.  
  
Hacking ruleutils.c to suppress the column qualification looks like it'd  
be a risky business, so instead promote the RTE alias to full-fledged  
usability.  
  
Per bug #6049 from Dylan Adams.  Back-patch to all supported branches.  
  

Clean up after erroneous SELECT FOR UPDATE/SHARE on a sequence.

  
commit   : bc0550f994539b4cd3b93487439c754e251fedb8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jun 2011 15:31:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jun 2011 15:31:02 -0400    

Click here for diff

  
My previous commit disallowed this operation, but did nothing about  
cleaning up the damage if one had already been done.  With the operation  
disallowed, it's okay to just forcibly clear xmax in a sequence's tuple,  
since any value seen there could not represent a live transaction's lock.  
So, any sequence-specific operation will repair the problem automatically,  
whether or not the user has already seen "could not access status of  
transaction" failures.  
  

Disallow SELECT FOR UPDATE/SHARE on sequences.

  
commit   : c117838597b1a28f6f0feb4a41adff1a7e5e0bc9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jun 2011 14:46:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jun 2011 14:46:22 -0400    

Click here for diff

  
We can't allow this because such an operation stores its transaction XID  
into the sequence tuple's xmax.  Because VACUUM doesn't process sequences  
(and we don't want it to start doing so), such an xmax value won't get  
frozen, meaning it will eventually refer to nonexistent pg_clog storage,  
and even wrap around completely.  Since the row lock is ignored by nextval  
and setval, the usefulness of the operation is highly debatable anyway.  
Per reports of trouble with pgpool 3.0, which had ill-advisedly started  
using such commands as a form of locking.  
  
In HEAD, also disallow SELECT FOR UPDATE/SHARE on toast tables.  Although  
this does work safely given the current implementation, there seems no  
good reason to allow it.  I refrained from changing that behavior in  
back branches, however.  
  

Protect GIST logic that assumes penalty values can’t be negative.

  
commit   : b26d8fda6535799be6eee1e93a8f11756b11af95    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 May 2011 17:53:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 May 2011 17:53:55 -0400    

Click here for diff

  
Apparently sane-looking penalty code might return small negative values,  
for example because of roundoff error.  This will confuse places like  
gistchoose().  Prevent problems by clamping negative penalty values to  
zero.  (Just to be really sure, I also made it force NaNs to zero.)  
Back-patch to all supported branches.  
  
Alexander Korotkov  
  

Fix portability bugs in use of credentials control messages for peer auth.

  
commit   : e73bd1e343c07970ed7d31c83b3d5035abd4e996    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 May 2011 19:16:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 May 2011 19:16:11 -0400    

Click here for diff

  
Even though our existing code for handling credentials control messages has  
been basically unchanged since 2001, it was fundamentally wrong: it did not  
ensure proper alignment of the supplied buffer, and it was calculating  
buffer sizes and message sizes incorrectly.  This led to failures on  
platforms where alignment padding is relevant, for instance FreeBSD on  
64-bit platforms, as seen in a recent Debian bug report passed on by  
Martin Pitt (http://bugs.debian.org//cgi-bin/bugreport.cgi?bug=612888).  
  
Rewrite to do the message-whacking using the macros specified in RFC 2292,  
following a suggestion from Theo de Raadt in that thread.  Tested by me  
on Debian/kFreeBSD-amd64; since OpenBSD and NetBSD document the identical  
CMSG API, it should work there too.  
  
Back-patch to all supported branches.  
  

Fix VACUUM so that it always updates pg_class.reltuples/relpages.

  
commit   : 73bd34c81ebd2208f4bd207b83f8a4df8aec82d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 May 2011 17:05:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 May 2011 17:05:33 -0400    

Click here for diff

  
When we added the ability for vacuum to skip heap pages by consulting the  
visibility map, we made it just not update the reltuples/relpages  
statistics if it skipped any pages.  But this could leave us with extremely  
out-of-date stats for a table that contains any unchanging areas,  
especially for TOAST tables which never get processed by ANALYZE.  In  
particular this could result in autovacuum making poor decisions about when  
to process the table, as in recent report from Florian Helmberger.  And in  
general it's a bad idea to not update the stats at all.  Instead, use the  
previous values of reltuples/relpages as an estimate of the tuple density  
in unvisited pages.  This approach results in a "moving average" estimate  
of reltuples, which should converge to the correct value over multiple  
VACUUM and ANALYZE cycles even when individual measurements aren't very  
good.  
  
This new method for updating reltuples is used by both VACUUM and ANALYZE,  
with the result that we no longer need the grotty interconnections that  
caused ANALYZE to not update the stats depending on what had happened  
in the parent VACUUM command.  
  
Also, fix the logic for skipping all-visible pages during VACUUM so that it  
looks ahead rather than behind to decide what to do, as per a suggestion  
from Greg Stark.  This eliminates useless scanning of all-visible pages at  
the start of the relation or just after a not-all-visible page.  In  
particular, the first few pages of the relation will not be invariably  
included in the scanned pages, which seems to help in not overweighting  
them in the reltuples estimate.  
  
Back-patch to 8.4, where the visibility map was introduced.  
  

Fix null-dereference crash in parse_xml_decl().

  
commit   : ab7c5a90828472c2261048a7195ab9218b55e296    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 May 2011 12:36:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 May 2011 12:36:04 -0400    

Click here for diff

  
parse_xml_decl's header comment says you can pass NULL for any unwanted  
output parameter, but it failed to honor this contract for the "standalone"  
flag.  The only currently-affected caller is xml_recv, so the net effect is  
that sending a binary XML value containing a standalone parameter in its  
xml declaration would crash the backend.  Per bug #6044 from Christopher  
Dillard.  
  
In passing, remove useless initializations of parse_xml_decl's output  
parameters in xml_parse.  
  
Back-patch to 8.3, where this code was introduced.  
  

Preserve caller’s memory context in ProcessCompletedNotifies().

  
commit   : 722548e4309c28631ada292fe6cad04ae8f9c151    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 May 2011 12:10:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 May 2011 12:10:32 -0400    

Click here for diff

  
This is necessary to avoid long-term memory leakage, because the main loop  
in PostgresMain expects to be executing in MessageContext, and hence is a  
bit sloppy about freeing stuff that is only needed for the duration of  
processing the current client message.  The known case of an actual leak  
is when encoding conversion has to be done on the incoming command string,  
but there might be others.  Per report from Per-Olov Esgard.  
  
Back-patch to 9.0, where the bug was introduced by the LISTEN/NOTIFY  
rewrite.  
  

Make decompilation of optimized CASE constructs more robust.

  
commit   : 0bd7305ffb16b238dea79d5f98f88c745fe21db8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 May 2011 19:25:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 May 2011 19:25:19 -0400    

Click here for diff

  
We had some hacks in ruleutils.c to cope with various odd transformations  
that the optimizer could do on a CASE foo WHEN "CaseTestExpr = RHS" clause.  
However, the fundamental impossibility of covering all cases was exposed  
by Heikki, who pointed out that the "=" operator could get replaced by an  
inlined SQL function, which could contain nearly anything at all.  So give  
up on the hacks and just print the expression as-is if we fail to recognize  
it as "CaseTestExpr = RHS".  (We must cover that case so that decompiled  
rules print correctly; but we are not under any obligation to make EXPLAIN  
output be 100% valid SQL in all cases, and already could not do so in some  
other cases.)  This approach requires that we have some printable  
representation of the CaseTestExpr node type; I used "CASE_TEST_EXPR".  
  
Back-patch to all supported branches, since the problem case fails in all.  
  

Avoid uninitialized bits in the result of QTN2QT().

  
commit   : c2a366d9d9d3b1e2dc4c65d9a9fab5c1c0d6c246    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2011 14:20:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 May 2011 14:20:08 -0400    

Click here for diff

  
Found with additional valgrind testing.  
  
Noah Misch  
  

Lobotomize typmod check in convert_tuples_by_position, back branches only.

  
commit   : e48433e9f81d6aceef2b538f1783fbcc91e1074f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2011 14:42:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2011 14:42:18 -0400    

Click here for diff

  
convert_tuples_by_position was rejecting attempts to coerce a record field  
with -1 typmod to the same type with a non-default typmod.  This is in fact  
the "correct" thing to do (since we're just going to do a type relabeling,  
not invoke any length-conversion cast function); but it results in  
rejecting valid cases like bug #6020, because the source record's tupdesc  
is built from Params that don't have typmod assigned.  Since that's a  
regression from previous versions, which accepted this code, we have to do  
something about it.  In HEAD, I've fixed the problem properly by causing  
the Params to receive the correct typmods; but the potential for incidental  
behavioral changes seems high enough to make it unattractive to make the  
same change in released branches.  (And it couldn't be fixed that way in  
8.4 anyway...)  Hence this patch just modifies convert_tuples_by_position  
to not complain if either the input or the output tupdesc has typmod -1.  
This is still a shade tighter checking than we did before 9.0, since before  
that plpgsql failed to consider typmods at all when checking record  
compatibility.  (convert_tuples_by_position is currently used only by  
plpgsql, so we're not affecting other behavior.)  
  
Back-patch to 8.4, since we recently back-ported convert_tuples_by_position  
into that branch.  
  

Replace strdup() with pstrdup(), to avoid leaking memory.

  
commit   : 7541d32e86b739afb41e711a4c790aed446dd0e2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 18 May 2011 22:30:24 -0400    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 18 May 2011 22:30:24 -0400    

Click here for diff

  
It's been like this since the seg module was introduced, so backpatch to  
8.2 which is the oldest supported version.  
  

Install defenses against overflow in BuildTupleHashTable().

  
commit   : 168174c44522b5f5bfad53500fd5dd46aad74f70    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2011 12:52:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 May 2011 12:52:51 -0400    

Click here for diff

  
The planner can sometimes compute very large values for numGroups, and in  
cases where we have no alternative to building a hashtable, such a value  
will get fed directly to BuildTupleHashTable as its nbuckets parameter.  
There were two ways in which that could go bad.  First, BuildTupleHashTable  
declared the parameter as "int" but most callers were passing "long"s,  
so on 64-bit machines undetected overflow could occur leading to a bogus  
negative value.  The obvious fix for that is to change the parameter to  
"long", which is what I've done in HEAD.  In the back branches that seems a  
bit risky, though, since third-party code might be calling this function.  
So for them, just put in a kluge to treat negative inputs as INT_MAX.  
Second, hash_create can go nuts with extremely large requested table sizes  
(notably, my_log2 becomes an infinite loop for inputs larger than  
LONG_MAX/2).  What seems most appropriate to avoid that is to bound the  
initial table size request to work_mem.  
  
This fixes bug #6035 reported by Daniel Schreiber.  Although the reported  
case only occurs back to 8.4 since it involves WITH RECURSIVE, I think  
it's a good idea to install the defenses in all supported branches.  
  

Fix write-past-buffer-end in ldapServiceLookup().

  
commit   : 30cf86fdf49ec6a5c74aab6dcd7cef78e7f1dd54    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2011 11:56:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 May 2011 11:56:38 -0400    

Click here for diff

  
The code to assemble ldap_get_values_len's output into a single string  
wrote the terminating null one byte past where it should.  Fix that,  
and make some other cosmetic adjustments to make the code a trifle more  
readable and more in line with usual Postgres coding style.  
  
Also, free the "result" string when done with it, to avoid a permanent  
memory leak.  
  
Bug report and patch by Albe Laurenz, cosmetic adjustments by me.  
  

Shut down WAL receiver if it’s still running at end of recovery. We used to just check that it’s not running and PANIC if it was, but that can rightfully happen if recovery stops at recovery target.

  
commit   : fbc56f706cdadaaf2a686dacece8b403dfaef50b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 11 May 2011 12:46:08 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 11 May 2011 12:46:08 +0300    

Click here for diff

  
  

Update documentation to state there is three-value logic, not three-value boolean logic.

  
commit   : f71b5c77fa0015492a26838eb489293effee1723    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 9 May 2011 21:04:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 9 May 2011 21:04:22 -0400    

Click here for diff

  
Backpatch to 9.0.X since we just got another bug report about this  
today.  
  

  
commit   : 65a7cd0e9ced21ec7ad67c11cd9a263640fe22e9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 May 2011 15:56:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 May 2011 15:56:43 -0400    

Click here for diff

  
After finding an EXISTS or ANY sub-select that can be converted to a  
semi-join or anti-join, we should recurse into the body of the sub-select.  
This allows cases such as EXISTS-within-EXISTS to be optimized properly.  
The original coding would leave the lower sub-select as a SubLink, which  
is no better and often worse than what we can do with a join.  Per example  
from Wayne Conrad.  
  
Back-patch to 8.4.  There is a related issue in older versions' handling  
of pull_up_IN_clauses, but they're lame enough anyway about the whole area  
that it seems not worth the extra work to try to fix.  
  

Add missing gitignore file

  
commit   : e79518e93744a547ff874832dd40638b9531105e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 2 May 2011 01:03:04 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 2 May 2011 01:03:04 +0300    

Click here for diff

  
  

Catch errors in for loop in makefile

  
commit   : c8c93c6e73b98fc8e0e371a8391d4824732437f2    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 2 May 2011 00:47:09 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 2 May 2011 00:47:09 +0300    

Click here for diff

  
Add "|| exit" so that the rule aborts when a command fails.  
  
This is the minimal backpatch version.  The fix in head is more  
elaborate.  
  

Make CLUSTER lock the old table’s toast table before copying data.

  
commit   : fb69fd176aaa8eab0315c4f891297c03c0b5d825    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 May 2011 17:57:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 May 2011 17:57:40 -0400    

Click here for diff

  
We must lock out autovacuuming of the old toast table before computing the  
OldestXmin horizon we will use.  Otherwise, autovacuum could start on the  
toast table later, compute a later OldestXmin horizon, and remove as DEAD  
toast tuples that we still need (because we think their parent tuples are  
only RECENTLY_DEAD).  Per further thought about bug #5998.  
  

Remove special case for xmin == xmax in HeapTupleSatisfiesVacuum().

  
commit   : 007a6e53ace7e9f015252f14316394ef4b97ae2e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Apr 2011 16:29:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Apr 2011 16:29:51 -0400    

Click here for diff

  
VACUUM was willing to remove a committed-dead tuple immediately if it was  
deleted by the same transaction that inserted it.  The idea is that such a  
tuple could never have been visible to any other transaction, so we don't  
need to keep it around to satisfy MVCC snapshots.  However, there was  
already an exception for tuples that are part of an update chain, and this  
exception created a problem: we might remove TOAST tuples (which are never  
part of an update chain) while their parent tuple stayed around (if it was  
part of an update chain).  This didn't pose a problem for most things,  
since the parent tuple is indeed dead: no snapshot will ever consider it  
visible.  But MVCC-safe CLUSTER had a problem, since it will try to copy  
RECENTLY_DEAD tuples to the new table.  It then has to copy their TOAST  
data too, and would fail if VACUUM had already removed the toast tuples.  
  
Easiest fix is to get rid of the special case for xmin == xmax.  This may  
delay reclaiming dead space for a little bit in some cases, but it's by far  
the most reliable way to fix the issue.  
  
Per bug #5998 from Mark Reid.  Back-patch to 8.3, which is the oldest  
version with MVCC-safe CLUSTER.  
  

Rewrite pg_size_pretty() to avoid compiler bug.

  
commit   : cb0bcf45cbe1092081331f3f759c3ab7580d0cb1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Apr 2011 01:45:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Apr 2011 01:45:02 -0400    

Click here for diff

  
Convert it to use successive shifts right instead of increasing a divisor.  
This is probably a tad more efficient than the original coding, and it's  
nicer-looking than the previous patch because we don't need a special case  
to avoid overflow in the last branch.  But the real reason to do it is to  
avoid a Solaris compiler bug, as per results from buildfarm member moa.  
  

The arguments to pg_ctl kill are not optional - remove brackets in the docs.

  
commit   : c02bc6356f26c6b4373fbac0118409b544ea85f0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 28 Apr 2011 12:51:02 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 28 Apr 2011 12:51:02 +0300    

Click here for diff

  
Fujii Masao  
  

Add comments about the need to avoid uninitialized bits in datatype values.

  
commit   : db3cf2529304f96eabedd21f292bc661d5772aee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Apr 2011 14:06:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Apr 2011 14:06:05 -0400    

Click here for diff

  
There was already one recommendation in the documentation about writing  
C functions to ensure padding bytes are zeroes, but make it stronger.  
  
Also fix an example that was still using direct assignment to a varlena  
length word, which no longer works since the varvarlena changes.  
  

Fix array- and path-creating functions to ensure padding bytes are zeroes.

  
commit   : 433853e9269ee81627400c7edb1e4f9a001d3816    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Apr 2011 13:58:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 27 Apr 2011 13:58:44 -0400    

Click here for diff

  
Per recent discussion, it's important for all computed datums (not only the  
results of input functions) to not contain any ill-defined (uninitialized)  
bits.  Failing to ensure that can result in equal() reporting that  
semantically indistinguishable Consts are not equal, which in turn leads to  
bizarre and undesirable planner behavior, such as in a recent example from  
David Johnston.  We might eventually try to fix this in a general manner by  
allowing datatypes to define identity-testing functions, but for now the  
path of least resistance is to expect datatypes to force all unused bits  
into consistent states.  
  
Per some testing by Noah Misch, array and path functions seem to be the  
only ones presenting risks at the moment, so I looked through all the  
functions in adt/array*.c and geo_ops.c and fixed them as necessary.  In  
the array functions, the easiest/safest fix is to allocate result arrays  
with palloc0 instead of palloc.  Possibly in future someone will want to  
look into whether we can just zero the padding bytes, but that looks too  
complex for a back-patchable fix.  In the path functions, we already had a  
precedent in path_in for just zeroing the one known pad field, so duplicate  
that code as needed.  
  
Back-patch to all supported branches.  
  

Complain if pg_hba.conf contains “hostssl” but SSL is disabled.

  
commit   : af9fb26e2df7b5cfe161d088ce8417b2ceb66063    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Apr 2011 15:40:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Apr 2011 15:40:14 -0400    

Click here for diff

  
Most commenters agreed that this is more friendly than silently failing  
to match the line during actual connection attempts.  Also, this will  
prevent corner cases that might arise when trying to handle such a line  
when the SSL code isn't turned on.  An example is that specifying  
clientcert=1 in such a line would formerly result in a completely  
misleading complaint that root.crt wasn't present, as seen in a recent  
report from Marc-Andre Laverdiere.  While we could have instead fixed  
that specific behavior, it seems likely that we'd have a continuing stream  
of such bizarre behaviors if we keep on allowing hostssl lines when SSL is  
disabled.  
  
Back-patch to 8.4, where clientcert was introduced.  Earlier versions don't  
have this specific issue, and the code is enough different to make this  
patch not applicable without more work than it seems worth.  
  

Fix pg_size_pretty() to avoid overflow for inputs close to INT64_MAX.

  
commit   : 6ba0d8d5ac47b686ac31a2b390ab6a0f181753d1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Apr 2011 16:22:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Apr 2011 16:22:17 -0400    

Click here for diff

  
The expression that tried to round the value to the nearest TB could  
overflow, leading to bogus output as reported in bug #5993 from Nicola  
Cossu.  This isn't likely to ever happen in the intended usage of the  
function (if it could, we'd be needing to use a wider datatype instead);  
but it's not hard to give the expected output, so let's do so.  
  

Fix use of incorrect constant RemoveRoleFromObjectACL.

  
commit   : 147d6269f3e2d20e1790520e117e574092719ca3    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Apr 2011 22:23:58 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 20 Apr 2011 22:23:58 -0400    

Click here for diff

  
This could cause failures when DROP OWNED BY attempt to remove default  
privileges on sequences.  Back-patching to 9.0.  
  
Shigeru Hanada  
  

Fix bugs in indexing of in-doubt HOT-updated tuples.

  
commit   : b381b58286f8fac4d8b08e54e223f238742d1652    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Apr 2011 20:34:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Apr 2011 20:34:16 -0400    

Click here for diff

  
If we find a DELETE_IN_PROGRESS HOT-updated tuple, it is impossible to know  
whether to index it or not except by waiting to see if the deleting  
transaction commits.  If it doesn't, the tuple might again be LIVE, meaning  
we have to index it.  So wait and recheck in that case.  
  
Also, we must not rely on ii_BrokenHotChain to decide that it's possible to  
omit tuples from the index.  That could result in omitting tuples that we  
need, particularly in view of yesterday's fixes to not necessarily set  
indcheckxmin (but it's broken even without that, as per my analysis today).  
Since this is just an extremely marginal performance optimization, dropping  
the test shouldn't hurt.  
  
These cases are only expected to happen in system catalogs (they're  
possible there due to early release of RowExclusiveLock in most  
catalog-update code paths).  Since reindexing of a system catalog isn't a  
particularly performance-critical operation anyway, there's no real need to  
be concerned about possible performance degradation from these changes.  
  
The worst aspects of this bug were introduced in 9.0 --- 8.x will always  
wait out a DELETE_IN_PROGRESS tuple.  But I think dropping index entries  
on the strength of ii_BrokenHotChain is dangerous even without that, so  
back-patch removal of that optimization to 8.3 and 8.4.  
  

Set indcheckxmin true when REINDEX fixes an invalid or not-ready index.

  
commit   : 1d6249d64ddbd7796c1ccaef801b709d5108bc2e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Apr 2011 19:01:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Apr 2011 19:01:25 -0400    

Click here for diff

  
Per comment from Greg Stark, it's less clear that HOT chains don't conflict  
with the index than it would be for a valid index.  So, let's preserve the  
former behavior that indcheckxmin does get set when there are  
potentially-broken HOT chains in this case.  This change does not cause any  
pg_index update that wouldn't have happened anyway, so we're not  
re-introducing the previous bug with pg_index updates, and surely the case  
is not significant from a performance standpoint; so let's be as  
conservative as possible.  
  

Quotes in strings injected into bki file need to escaped. In particular, “People’s Republic of China” locale on Windows was causing initdb to fail.

  
commit   : 8a6d60fd0c01671773055558b687199ede961a97    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 20 Apr 2011 09:49:44 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 20 Apr 2011 09:49:44 +0300    

Click here for diff

  
This fixes bug #5818 reported by yulei. On master, this makes the mapping  
of "People's Republic of China" to just "China" obsolete. In 9.0 and 8.4,  
just fix the escaping. Earlier versions didn't have locale names in bki  
file.  
  

Avoid changing an index’s indcheckxmin horizon during REINDEX.

  
commit   : ebcbc8cfe6c2d9c587ae2a25e545f09b58b666b0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Apr 2011 18:51:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Apr 2011 18:51:03 -0400    

Click here for diff

  
There can never be a need to push the indcheckxmin horizon forward, since  
any HOT chains that are actually broken with respect to the index must  
pre-date its original creation.  So we can just avoid changing pg_index  
altogether during a REINDEX operation.  
  
This offers a cleaner solution than my previous patch for the problem  
found a few days ago that we mustn't try to update pg_index while we are  
reindexing it.  System catalog indexes will always be created with  
indcheckxmin = false during initdb, and with this modified code we should  
never try to change their pg_index entries.  This avoids special-casing  
system catalogs as the former patch did, and should provide a performance  
benefit for many cases where REINDEX formerly caused an index to be  
considered unusable for a short time.  
  
Back-patch to 8.3 to cover all versions containing HOT.  Note that this  
patch changes the API for index_build(), but I believe it is unlikely that  
any add-on code is calling that directly.  
  

Revert “Prevent incorrect updates of pg_index while reindexing pg_index itself.”

  
commit   : 1da9966230a30405ea5981403d4f4a9d83cb1ecb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Apr 2011 16:57:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Apr 2011 16:57:57 -0400    

Click here for diff

  
This reverts commit a03e3e1fd1d4ecfeb1096aeb7854b717061a75d9 of 2011-04-15.  
There's a better way to do it, which will follow shortly.  
  

Silence compiler warning about unused variable on Windows.

  
commit   : b2e2d3a3781c717ee826d01d83e55009321ac24d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 19 Apr 2011 14:54:48 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 19 Apr 2011 14:54:48 +0300    

Click here for diff

  
  

Prevent incorrect updates of pg_index while reindexing pg_index itself.

  
commit   : a03e3e1fd1d4ecfeb1096aeb7854b717061a75d9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2011 20:19:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 Apr 2011 20:19:03 -0400    

Click here for diff

  
The places that attempt to change pg_index.indcheckxmin during a reindexing  
operation cannot be executed safely if pg_index itself is the subject of  
the operation.  This is the explanation for a couple of recent reports of  
VACUUM FULL failing with  
	ERROR:  duplicate key value violates unique constraint "pg_index_indexrelid_index"  
	DETAIL:  Key (indexrelid)=(2678) already exists.  
  
However, there isn't any real need to update indcheckxmin in such a  
situation, if we assume that pg_index can never contain a truly broken HOT  
chain.  This assumption holds if new indexes are never created on it during  
concurrent operations, which is something we don't consider safe for any  
system catalog, not just pg_index.  Accordingly, modify the code to not  
manipulate indcheckxmin when reindexing any system catalog.  
  
Back-patch to 8.3, where HOT was introduced.  The known failure scenarios  
involve 9.0-style VACUUM FULL, so there might not be any real risk before  
9.0, but let's not assume that.  
  

Note that Bison on GnuWin32 has trouble with paths with spaces

  
commit   : c1d42380633b86058b99020452eebece91fc2bf2    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 15 Apr 2011 15:27:02 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 15 Apr 2011 15:27:02 +0200    

Click here for diff

  
Peter Eisentraut  
  

Specify which versions of the Platform SDK are supported

  
commit   : 52a6150445247255c065581e1b08170a87df13e4    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 15 Apr 2011 15:00:42 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 15 Apr 2011 15:00:42 +0200    

Click here for diff

  
Anything including Visual Studio 2010 compilers is not yet  
supported for building on Windows.