PostgreSQL 9.0.8 commit log

commit   : eab246d75f557cc5027568ccb0461ce5614eaad8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 19:09:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 19:09:35 -0400    

commit   : e7e092f32274db2c6dd4f3cd2894c1125acb156d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 19:03:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 19:03:45 -0400    

commit   : 7c61eb3fa69330ccedc0fae0db37fc5747aa2e7a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 31 May 2012 23:27:32 +0300    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 31 May 2012 23:27:32 +0300    

commit   : d9e1ea4de8c96c913bd979c1209258157a4605d9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 11:12:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 11:12:33 -0400    

Per discussion, it does not seem like a good idea to change the behavior of  
age(xid) in a minor release, even though the old definition causes the  
function to fail on hot standby slaves.  Therefore, revert commit  
5829387381d2e4edf84652bb5a712f6185860670 and follow-on commits in the back  
branches only.  

commit   : fcd7fe55c502a1d8952aa0e3377ad33928984655    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 00:48:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 31 May 2012 00:48:11 -0400    

DST law changes in Antarctica, Armenia, Chile, Cuba, Falkland Islands,  
Gaza, Haiti, Hebron, Morocco, Syria, Tokelau Islands.  
Historical corrections for Canada.  

commit   : b53c7c3bc69658c31c5fd5fe7873cb85254e42f5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 May 2012 23:28:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 May 2012 23:28:16 -0400    

It's not very sensible to set such attributes on a handler function;  
but if one were to do so, fmgr.c went into infinite recursion because  
it would call fmgr_security_definer instead of the handler function proper.  
There is no way for fmgr_security_definer to know that it ought to call the  
handler and not the original function referenced by the FmgrInfo's fn_oid,  
so it tries to do the latter, causing the whole process to start over  
again.  
  
Ordinarily such misconfiguration of a procedural language's handler could  
be written off as superuser error.  However, because we allow non-superuser  
database owners to create procedural languages and the handler for such a  
language becomes owned by the database owner, it is possible for a database  
owner to crash the backend, which ideally shouldn't be possible without  
superuser privileges.  In 9.2 and up we will adjust things so that the  
handler functions are always owned by superusers, but in existing branches  
this is a minor security fix.  
  
Problem noted by Noah Misch (after several of us had failed to detect  
it :-().  This is CVE-2012-2655.  

commit   : 9b0875a2045cecc9de2a0f1c16e7930510a394ae    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 May 2012 19:58:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 May 2012 19:58:47 -0400    

We used to only allow offsets less than +/-13 hours, then it was +/14,  
then it was +/-15.  That's still not good enough though, as per today's bug  
report from Patric Bechtel.  This time I actually looked through the Olson  
timezone database to find the largest offsets used anywhere.  The winners  
are Asia/Manila, at -15:56:00 until 1844, and America/Metlakatla, at  
+15:13:42 until 1867.  So we'd better allow offsets less than +/-16 hours.  
  
Given the history, we are way overdue to have some greppable #define  
symbols controlling this, so make some ... and also remove an obsolete  
comment that didn't get fixed the last time.  
  
Back-patch to all supported branches.  

commit   : b1d01f9a8984f21865e3d9cc9830900db8f91a06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 May 2012 10:53:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 May 2012 10:53:40 -0400    

Overly tight coding caused the password transformation loop to stop  
examining input once it had processed a byte equal to 0x80.  Thus, if the  
given password string contained such a byte (which is possible though not  
highly likely in UTF8, and perhaps also in other non-ASCII encodings), all  
subsequent characters would not contribute to the hash, making the password  
much weaker than it appears on the surface.  
  
This would only affect cases where applications used DES crypt() to encode  
passwords before storing them in the database.  If a weak password has been  
created in this fashion, the hash will stop matching after this update has  
been applied, so it will be easy to tell if any passwords were unexpectedly  
weak.  Changing to a different password would be a good idea in such a case.  
(Since DES has been considered inadequately secure for some time, changing  
to a different encryption algorithm can also be recommended.)  
  
This code, and the bug, are shared with at least PHP, FreeBSD, and OpenBSD.  
Since the other projects have already published their fixes, there is no  
point in trying to keep this commit private.  
  
This bug has been assigned CVE-2012-2143, and credit for its discovery goes  
to Rubin Xu and Joseph Bonneau.  

commit   : 73bf9b77fc28840a335002d8dc817e8706d9a2ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 May 2012 23:57:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 May 2012 23:57:20 -0400    

AbortOutOfAnyTransaction failed to do anything if the state it saw on  
entry corresponded to failing partway through StartTransaction.  I fixed  
AbortCurrentTransaction to cope with that case way back in commit  
60b2444cc3ba037630c9b940c3c9ef01b954b87b, but evidently overlooked that  
AbortOutOfAnyTransaction should do likewise.  
  
Back-patch to all supported branches.  It's not clear that this omission  
has any more-than-cosmetic consequences, but it's also not clear that it  
doesn't, so back-patching seems the least risky choice.  

commit   : 785b8d6ab312e5bee0846094fe06982c1d4c07f2    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 27 May 2012 10:54:31 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 27 May 2012 10:54:31 +0200    

Write the file to a temporary name and then rename() it into the  
permanent name, to ensure it can't end up half-written and corrupt  
in case of a crash during shutdown.  
  
Unlink the file after it has been read so it's removed from the data  
directory and not included in base backups going to replication slaves.  

commit   : 2ce097e6e8989028ce18fdca010351b8fcc9dfd0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 May 2012 19:10:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 May 2012 19:10:05 -0400    

The only interesting-for-performance case wherein we force heapscan here  
is when we're rebuilding the relcache init file, and the only such case  
that is likely to be examining a catalog big enough to be syncscanned is  
RelationBuildTupleDesc.  But the early-exit optimization in that code gets  
broken if we start the scan at a random place within the catalog, so that  
allowing syncscan is actually a big deoptimization if pg_attribute is large  
(at least for the normal case where the rows for core system catalogs have  
never been changed since initdb).  Hence, prevent syncscan here.  Per my  
testing pursuant to complaints from Jeff Frost and Greg Sabino Mullane,  
though neither of them seem to have actually hit this specific problem.  
  
Back-patch to 8.3, where syncscan was introduced.  

commit   : d566ad3eb3e2ea532358123795f16fbeb5c0a46e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 May 2012 17:35:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 May 2012 17:35:05 -0400    

Previously, casts to name could generate invalidly-encoded results.  
  
Also, make these functions match namein() more exactly, by consistently  
using palloc0() instead of ad-hoc zeroing code.  
  
Back-patch to all supported branches.  
  
Karl Schnaitter and Tom Lane  

commit   : 965d76f972bec5595e84a8e8567636cb3ba7a1f2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 May 2012 14:35:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 May 2012 14:35:47 -0400    

The previous coding presented a significant bottleneck when dumping  
databases containing many thousands of schemas, since the total time  
spent searching would increase roughly as O(N^2) in the number of objects.  
Noted by Jeff Janes, though I rewrote his proposed patch to use the  
existing findObjectByOid infrastructure.  
  
Since this is a longstanding performance bug, backpatch to all supported  
versions.  

commit   : c676f835b544d73b3e75d994000d586f878fcb21    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 May 2012 19:42:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 May 2012 19:42:18 -0400    

If a seqscan encounters many consecutive pages containing only dead tuples,  
it can remain in the loop in heapgettup for a long time, and there was no  
CHECK_FOR_INTERRUPTS anywhere in that loop.  This meant there were  
real-world situations where a query would be effectively uncancelable for  
long stretches.  Add a check placed to occur once per page, which should be  
enough to provide reasonable response time without adding any measurable  
overhead.  
  
Report and patch by Merlin Moncure (though I tweaked it a bit).  
Back-patch to all supported branches.  

commit   : 26d73ddac43667f80cec530ac8644beeecfd666f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 15 May 2012 19:22:56 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 15 May 2012 19:22:56 +0300    

We were using memcpy() to copy to a possibly overlapping memory region,  
which is a no-no. Use memmove() instead.  

commit   : 82992a4cd07c427d8215ecc19b56e4f4eb9471b2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 May 2012 18:07:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 May 2012 18:07:02 -0400    

If the tablespace directory is missing entirely, we allow DROP TABLESPACE  
to go through, on the grounds that it should be possible to clean up the  
catalog entry in such a situation.  However, we forgot that the pg_tblspc  
symlink might still be there.  We should try to remove the symlink too  
(but not fail if it's no longer there), since not doing so can lead to  
weird behavior subsequently, as per report from Michael Nolan.  
  
There was some discussion of adding dependency links to prevent DROP  
TABLESPACE when the catalogs still contain references to the tablespace.  
That might be worth doing too, but it's an orthogonal question, and in  
any case wouldn't be back-patchable.  
  
Back-patch to 9.0, which is as far back as the logic looks like this.  
We could possibly do something similar in 8.x, but given the lack of  
reports I'm not sure it's worth the trouble, and anyway the case could  
not arise in the form the logic is meant to cover (namely, a post-DROP  
transaction rollback having resurrected the pg_tablespace entry after  
some or all of the filesystem infrastructure is gone).  

commit   : 37edecfdfe21c2d20431109e9d1aeb18485bbf0a    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 12 May 2012 13:24:15 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sat, 12 May 2012 13:24:15 +0100    

commit   : 329ee80f79b412915ba96f6896de15b6386b2b97    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 11 May 2012 14:45:08 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 11 May 2012 14:45:08 +0100    

commit   : 67ff11b42b2811c18fc9dfa54ded02303a082f7c    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 11 May 2012 14:38:53 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Fri, 11 May 2012 14:38:53 +0100    

commit   : b149d1f90e7d42f719babc0c26addaeffa18df8c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 May 2012 13:36:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 May 2012 13:36:23 -0400    

The original coding failed to reset ImmediateInterruptOK before returning,  
which would potentially allow a subsequent query-cancel interrupt to be  
accepted at an unsafe point.  This is a really nasty bug since it's so hard  
to predict the consequences, but they could be unpleasant.  
  
Also, ensure that signal handlers are serviced before this function  
returns, even if the semaphore is already set.  This should make the  
behavior more like Unix.  
  
Back-patch to all supported versions.  

commit   : 5a96a0a8cf8cea3c5737fec9d37a75f012302f60    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Wed, 9 May 2012 22:51:17 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Wed, 9 May 2012 22:51:17 -0700    

commit   : d02918fc3e67104348dd7ba67b17df6836201ac0    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 9 May 2012 14:00:09 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Wed, 9 May 2012 14:00:09 +0100    

commit   : 14c412da46d9e36ab19c42ec6fb66139dbc30c3e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 3 May 2012 13:01:31 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 3 May 2012 13:01:31 +0200    

This backatches Heikki's patch in 140a4fbf1a87891a79a2c61a08416828d39f286a  
to make sure the documentation on the website gets updated, since  
we're regularly receiving complains about this link.  

commit   : 14f9fb575b23f02a92b870908e6b801a209b0a2e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Apr 2012 19:49:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Apr 2012 19:49:34 -0400    

Normally whole-row Vars are printed as "tabname.*".  However, that does not  
work at top level of a targetlist, because per SQL standard the parser will  
think that the "*" should result in column-by-column expansion; which is  
not at all what a whole-row Var implies.  We used to just print the table  
name in such cases, which works most of the time; but it fails if the table  
name matches a column name available anywhere in the FROM clause.  This  
could lead for instance to a view being interpreted differently after dump  
and reload.  Adding parentheses doesn't fix it, but there is a reasonably  
simple kluge we can use instead: attach a no-op cast, so that the "*" isn't  
syntactically at top level anymore.  This makes the printing of such  
whole-row Vars a lot more consistent with other Vars, and may indeed fix  
more cases than just the reported one; I'm suspicious that cases involving  
schema qualification probably didn't work properly before, either.  
  
Per bug report and fix proposal from Abbas Butt, though this patch is quite  
different in detail from his.  
  
Back-patch to all supported versions.  

commit   : a6708e2571ac6d2d2b1dc4cdae39acb282c0c5a9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Apr 2012 00:12:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Apr 2012 00:12:53 -0400    

If it fails to open a new log file, the syslogger assumes there's something  
wrong with its parameters (such as log_directory), and stops attempting  
automatic time-based or size-based log file rotations.  Sending it SIGHUP  
is supposed to start that up again.  However, the original coding for that  
was really bogus, involving clobbering a couple of GUC variables and hoping  
that SIGHUP processing would restore them.  Get rid of that technique in  
favor of maintaining a separate flag showing we've turned rotation off.  
Per report from Mark Kirkwood.  
  
Also, the syslogger will automatically attempt to create the log_directory  
directory if it doesn't exist, but that was only happening at startup.  
For consistency and ease of use, it should do the same whenever the value  
of log_directory is changed by SIGHUP.  
  
Back-patch to all supported branches.  

commit   : b0f24b5626727f81ecd7024ed5cefbaa336c8100    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Apr 2012 17:25:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Apr 2012 17:25:24 -0400    

Due to rather sloppy thinking (on my part, I'm afraid) about the  
appropriate behavior for boundary conditions, pg_next_dst_boundary() gave  
undefined, platform-dependent results when the input time is exactly the  
last recorded DST transition time for the specified time zone, as a result  
of fetching values one past the end of its data arrays.  
  
Change its specification to be that it always finds the next DST boundary  
*after* the input time, and adjust code to match that.  The sole existing  
caller, DetermineTimeZoneOffset, doesn't actually care about this  
distinction, since it always uses a probe time earlier than the instant  
that it does care about.  So it seemed best to me to change the API to make  
the result=1 and result=0 cases more consistent, specifically to ensure  
that the "before" outputs always describe the state at the given time,  
rather than hacking the code to obey the previous API comment exactly.  
  
Per bug #6605 from Sergey Burladyan.  Back-patch to all supported versions.  

commit   : 5969ee4df7e98cbb8cc0d1ec04027567ab932a50    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 18 Apr 2012 10:58:01 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 18 Apr 2012 10:58:01 -0400    

commit   : 4fd49c7336226124a3288fd67774f856de7ddb0d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 18 Apr 2012 10:45:18 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 18 Apr 2012 10:45:18 -0400    

Noah Misch  

commit   : 156fac55c79e8c5e09972cf46d175024c0cedde9    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 17 Apr 2012 18:37:25 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 17 Apr 2012 18:37:25 -0400    

A number of utility programs were rather careless about paremeters  
that can be set via both an option argument and a positional  
argument. This leads to results which can violate the Principal  
Of Least Astonishment. These changes refuse to use positional  
arguments to override settings that have been made via positional  
arguments. The changes are backpatched to all live branches.  

commit   : 05504f11b0fdcaf2270edad27a776b01fc956e05    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Apr 2012 20:24:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Apr 2012 20:24:32 -0400    

cost_index tries to estimate the per-tuple costs of evaluating filter  
conditions (a/k/a qpquals) by subtracting the estimated cost of the  
indexqual conditions from that of the baserestrictinfo conditions.  This is  
correct so long as the indexquals list is a subset of the baserestrictinfo  
list.  However, in the presence of derived indexable conditions it's  
completely wrong, leading to bogus or even negative scan cost estimates,  
as seen for example in bug #6579 from Istvan Endredy.  In practice the  
problem isn't severe except in the specific case of a LIKE optimization on  
a functional index containing a very expensive function.  
  
A proper fix for this might change cost estimates by more than people would  
like for stable branches, so in the back branches let's just clamp the cost  
difference to be not less than zero.  That will at least prevent completely  
insane behavior, while not changing the results normally.  

commit   : 916eec2dcf86630fe169e7338f247ef87a401987    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 Apr 2012 19:57:13 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 10 Apr 2012 19:57:13 -0400    

Per bug report from Ants Aasma.  
  
Backpatch to 9.1 and 9.0.  

commit   : 8b67e3cbe0c3e14a5e250e4f03748e9908e988f3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Apr 2012 20:49:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Apr 2012 20:49:11 -0400    

It's still non-deterministic in some sense ... but given fixed settings  
and identical planning problems, it will now always choose the same plan,  
so we probably shouldn't tar it with that brush.  Per bug #6565 from  
Guillaume Cottenceau.  Back-patch to 9.0 where the behavior was fixed.  

commit   : be9aad6b9e451a2767c645353c7f4c9722a9d1df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Apr 2012 11:58:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Apr 2012 11:58:24 -0400    

estimate_num_groups() gets unhappy with  
	create table empty();  
	select * from empty except select * from empty e2;  
I can't see any actual use-case for such a query (and the table is illegal  
per SQL spec), but it seems like a good idea that it not cause an assert  
failure.  

commit   : 785d4998b69a538023b82bfa95db4af5f7d07b06    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 8 Apr 2012 19:39:12 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 8 Apr 2012 19:39:12 +0300    

This was a thinko in previous commit. Now that stack base pointer is now set  
in PostmasterMain and SubPostmasterMain, it doesn't need to be set in  
PostgresMain anymore.  

commit   : 77dc2b0a43176d571aabac245e7228d834f7af95    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 8 Apr 2012 18:28:12 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 8 Apr 2012 18:28:12 +0300    

We used to only initialize the stack base pointer when starting up a regular  
backend, not in other processes. In particular, autovacuum workers can run  
arbitrary user code, and without stack-depth checking, infinite recursion  
in e.g an index expression will bring down the whole cluster.  
  
The comment about PL/Java using set_stack_base() is not yet true. As the  
code stands, PL/java still modifies the stack_base_ptr variable directly.  
However, it's been discussed in the PL/Java mailing list that it should be  
changed to use the function, because PL/Java is currently oblivious to the  
register stack used on Itanium. There's another issues with PL/Java, namely  
that the stack base pointer it sets is not really the base of the stack, it  
could be something close to the bottom of the stack. That's a separate issue  
that might need some further changes to this code, but that's a different  
story.  
  
Backpatch to all supported releases.  

commit   : f42a4c01f4bae27a06330ab235adb6533ca4ecd9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Apr 2012 19:00:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Apr 2012 19:00:23 -0400    

Thom Brown  

commit   : 13847713e275baa047e62f00150bc3a814fc68d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Apr 2012 18:10:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Apr 2012 18:10:35 -0400    

XLOG_GIN_UPDATE_META_PAGE and XLOG_GIN_DELETE_LISTPAGE records were printed  
with a list link field labeled as "blkno", which was confusing, especially  
when the link was empty (InvalidBlockNumber).  Print the metapage block  
number instead, since that's what's actually being updated.  We could  
include the link values too as a separate field, but not clear it's worth  
the trouble.  
  
Back-patch to 8.4 where the dubious code was added.  

commit   : 9b4d973af090694d3128a51b709c61f5a1ecc80f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Apr 2012 15:05:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Apr 2012 15:05:25 -0400    

The original coding of the syslogger had an arbitrary limit of 20 large  
messages concurrently in progress, after which it would just punt and dump  
message fragments to the output file separately.  Our ambitions are a bit  
higher than that now, so allow the data structure to expand as necessary.  
  
Reported and patched by Andrew Dunstan; some editing by Tom  

commit   : 49281db951973fb0b83740d90e22b5b5c61f9173    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Apr 2012 20:43:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Apr 2012 20:43:25 -0400    

dblink_exec leaked temporary database connections if any error occurred  
after connection setup, for example  
	SELECT dblink_exec('...connect string...', 'select 1/0');  
Add a PG_TRY block to ensure PQfinish gets done when it is needed.  
(dblink_record_internal is on the hairy edge of needing similar treatment,  
but seems not to be actively broken at the moment.)  
  
Also, in 9.0 and up, only one of the three functions using tuplestore  
return mode was properly checking that the query context would allow  
a tuplestore result.  
  
Noted while reviewing dblink patch.  Back-patch to all supported branches.  

commit   : e1a66794d3bea30eb96714cc0df2f7ae584632a4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Mar 2012 15:51:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Mar 2012 15:51:17 -0400    

Combining the loop workspace with the record of already-processed objects  
might have been a cute trick, but it behaves horridly if there are many  
dependency loops to repair: the time spent in the first step of findLoop()  
grows as O(N^2).  Instead use a separate flag array indexed by dump ID,  
which we can check in constant time.  The length of the workspace array  
is now never more than the actual length of a dependency chain, which  
should be reasonably short in all cases of practical interest.  The code  
is noticeably easier to understand this way, too.  
  
Per gripe from Mike Roest.  Since this is a longstanding performance bug,  
backpatch to all supported versions.  

commit   : b77da19930e6b6f0e8ff0f721e59713e3709eea1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Mar 2012 14:42:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Mar 2012 14:42:28 -0400    

The loop that matched owned sequences to their owning tables required time  
proportional to number of owned sequences times number of tables; although  
this work was only expended in selective-dump situations, which is probably  
why the issue wasn't recognized long since.  Refactor slightly so that we  
can perform this work after the index array for findTableByOid has been  
set up, reducing the time to O(M log N).  
  
Per gripe from Mike Roest.  Since this is a longstanding performance bug,  
backpatch to all supported versions.  

commit   : 6205bb6e2875514c191370f22f1e10184b655fc5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Mar 2012 17:52:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 Mar 2012 17:52:38 -0400    

The DBLINK_GET_CONN and DBLINK_GET_NAMED_CONN macros did not set the  
surrounding function's conname variable, causing errors to be incorrectly  
reported as having occurred on the "unnamed" connection in some cases.  
This bug was actually visible in two cases in the regression tests,  
but apparently whoever added those cases wasn't paying attention.  
  
Noted by Kyotaro Horiguchi, though this is different from his proposed  
patch.  
  
Back-patch to 8.4; 8.3 does not have the same type of error reporting  
so the patch is not relevant.  

commit   : efff1cc5fe541ee01488981becd8a54e0f8af49f    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 29 Mar 2012 14:58:02 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Thu, 29 Mar 2012 14:58:02 +0100    

Bug report from Daniel Farina  

commit   : 70e94d2dd7ccfa38b13e8d9f6e58db913fe3ec17    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Mar 2012 23:17:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Mar 2012 23:17:32 -0400    

The COPY documentation says "COPY FROM matches the input against the null  
string before removing backslashes".  It is therefore reasonable to presume  
that null markers like E'\\0' will work ... and they did, until someone put  
the tests in the wrong order during microoptimization-driven rewrites.  
Since then, we've been failing if the null marker is something that would  
de-escape to an invalidly-encoded string.  Since null markers generally  
need to be something that can't appear in the data, this represents a  
nontrivial loss of functionality; surprising nobody noticed it earlier.  
  
Per report from Jeff Davis.  Backpatch to 8.4 where this got broken.  

commit   : 29e0b4cb772c0089007f795655136e1dd3d48f93    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Mar 2012 16:21:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 24 Mar 2012 16:21:54 -0400    

For some reason, in the original coding of the PlaceHolderVar mechanism  
I had supposed that PlaceHolderVars couldn't propagate into subqueries.  
That is of course entirely possible.  When it happens, we need to treat  
an outer-level PlaceHolderVar much like an outer Var or Aggref, that is  
SS_replace_correlation_vars() needs to replace the PlaceHolderVar with  
a Param, and then when building the finished SubPlan we have to provide  
the PlaceHolderVar expression as an actual parameter for the SubPlan.  
The handling of the contained expression is a bit delicate but it can be  
treated exactly like an Aggref's expression.  
  
In addition to the missing logic in subselect.c, prepjointree.c was failing  
to search subqueries for PlaceHolderVars that need their relids adjusted  
during subquery pullup.  It looks like everyplace else that touches  
PlaceHolderVars got it right, though.  
  
Per report from Mark Murawski.  In 9.1 and HEAD, queries affected by this  
oversight would fail with "ERROR: Upper-level PlaceHolderVar found where  
not expected".  But in 9.0 and 8.4, you'd silently get possibly-wrong  
answers, since the value transmitted into the subquery wouldn't go to null  
when it should.  

commit   : 7bdf9b863f57f13fe73b3bed1c456aa905068272    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Mar 2012 14:13:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 22 Mar 2012 14:13:17 -0400    

An incorrect and entirely unnecessary "safety check" in exec_stmt_getdiag()  
caused the code to treat an assignment to a variable with dno zero as a  
no-op.  Unfortunately, that's a perfectly valid dno.  This has been broken  
since GET DIAGNOSTICS was invented.  It's not terribly surprising that the  
bug went unnoticed for so long, since in most cases you probably wouldn't  
use the function's first-created variable (normally its first parameter)  
as a GET DIAGNOSTICS target.  Nonetheless, it's broken.  Per bug #6551  
from Adam Buraczewski.  

commit   : 3bf25a2a16ca6efefa97f058da062b6c5933ebe1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Mar 2012 13:04:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Mar 2012 13:04:12 -0400    

Since 9.0, removing lots of large objects in a single transaction risks  
exceeding max_locks_per_transaction, because we merged large object removal  
into the generic object-drop mechanism, which takes out an exclusive lock  
on each object to be dropped.  This creates a hazard for contrib/vacuumlo,  
which has historically tried to drop all unreferenced large objects in one  
transaction.  There doesn't seem to be any correctness requirement to do it  
that way, though; we only need to drop enough large objects per transaction  
to amortize the commit costs.  
  
To prevent a regression from pre-9.0 releases wherein vacuumlo worked just  
fine, back-patch commits b69f2e36402aaa222ed03c1769b3de6d5be5f302 and  
64c604898e812aa93c124c666e8709fff1b8dd26, which break vacuumlo's deletions  
into multiple transactions with a user-controllable upper limit on the  
number of objects dropped per transaction.  
  
Tim Lewis, Robert Haas, Tom Lane  

commit   : d4a68363aff508a1179cd5e3f45f61a08104a1e1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 21 Mar 2012 12:38:34 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 21 Mar 2012 12:38:34 -0400    

This was never intended to be allowed, and is blocked for an ordinary  
CREATE TABLE, but CREATE TABLE AS slipped through the cracks.  This  
commit won't do anything to fix existing cases where this has loophole  
has been exploited, but it still seems prudent to lock it down going  
forward.  
  
Back-branch commit only, as this problem has been refactored away  
on the master branch.  
  
Andres Freund  

commit   : 4ba41df89605371b5be732b9682bee2bfaf52251    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Mar 2012 13:14:16 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Mar 2012 13:14:16 -0300    

commit   : c0998cfa53051eebbda90f2ca8d9058938c5e005    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 17 Mar 2012 17:24:15 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 17 Mar 2012 17:24:15 -0400    

When converting source files, pg_regress' inputdir and outputdir options were  
ignored when computing the locations of the destination files. In consequence,  
these options were effectively unusable when the regression inputs need to  
be adjusted by pg_regress. This patch makes pg_regress put the converted files  
in the same place that these options specify non-converted input or results  
files are to be found. Backpatched to all live branches.  

commit   : 5d492502ac29f4d2db41bafc68ae7e7615a7fb5f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 12 Mar 2012 10:13:33 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 12 Mar 2012 10:13:33 -0400    

commit   : 677d2ff18f54bccb6e190f27c1eb57f45b6a65de    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 11 Mar 2012 19:44:53 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 11 Mar 2012 19:44:53 +0900    

commit   : 9ddda5894c940c3a4363a35f6540ac33c31296e0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Mar 2012 22:29:01 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Mar 2012 22:29:01 +0200    

In a rare case, one byte past the end of memory belonging to the  
sqlca_t structure would be written to.  
  
found by Coverity  

commit   : b108a77505f5a3b21c756d47ffa3c93b0d6166b7    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Mar 2012 22:21:12 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 8 Mar 2012 22:21:12 +0200    

found by Coverity  

commit   : ebe608915cf9b6689b6dfcb92ddb31c8da765670    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 7 Mar 2012 23:46:41 +0200    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 7 Mar 2012 23:46:41 +0200    

Due to an apparent thinko, when printing a table in expanded mode  
(\x), space would be allocated for 1 slot plus 1 byte per line,  
instead of 1 slot per line plus 1 slot for the NULL terminator.  When  
the line count is small, reading or writing the terminator would  
therefore access memory beyond what was allocated.  

commit   : 0e925196340bf9279238f780cc10125fca2a0733    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Mar 2012 14:09:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Mar 2012 14:09:01 -0500    

In backup.sgml, point out that you need to be using the logging collector  
if you want to log messages from a failing archive_command script.  (This  
is an oversimplification, in that it will work without the collector as  
long as you're not sending postmaster stderr to /dev/null; but it seems  
like a good idea to encourage use of the collector to avoid problems  
with multiple processes concurrently scribbling on one file.)  
  
In config.sgml, do some wordsmithing of logging_collector discussion.  
  
Per bug #6518 from Janning Vygen  

commit   : 268ca4f57ea2dc3bf0dfb0f5c17fbda269b5d462    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Feb 2012 15:12:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Feb 2012 15:12:28 -0500    

In commit 4016bdef8aded77b4903c457050622a5a1815c16 I fixed a bunch of  
ginxlog.c bugs having to do with not handling XLogReadBuffer failures  
correctly.  However, in ginRedoUpdateMetapage and ginRedoDeleteListPages,  
I unaccountably thought that failure to read the metapage would be  
impossible and just put in an elog(PANIC) call.  This is of course wrong:  
failure is exactly what will happen if the index got dropped (or rebuilt)  
between creation of the WAL record and the crash we're trying to recover  
from.  I believe this explains Nicholas Wilson's recent report of these  
errors getting reached.  
  
Also, fix memory leak in forgetIncompleteSplit.  This wasn't of much  
concern when the code was written, but in a long-running standby server  
page split records could be expected to accumulate indefinitely.  
  
Back-patch to 8.4 --- before that, GIN didn't have a metapage.