PostgreSQL 9.1.4 commit log

commit   : 8e61ded616bdce65c43254b010f801f39b29ce3b    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 31 May 2012 19:07:09 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 31 May 2012 19:07:09 -0400    

commit   : 7651ec79879d36a68c9ab32a700ee034f7367701    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 31 May 2012 19:03:39 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 31 May 2012 19:03:39 -0400    

commit   : 8620f6f18eee348075f7e3430c04d7784edf1b5c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 31 May 2012 23:31:41 +0300    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 31 May 2012 23:31:41 +0300    

commit   : 3dfaea4727fb3d98e28f4cb9d707c33e2bdbfa7d    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 31 May 2012 11:12:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 31 May 2012 11:12:26 -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   : 56901beb806bde7af419ad67f49086aaca4fc8df    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 31 May 2012 00:48:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 31 May 2012 00:48:04 -0400    

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

commit   : d72a3bd75813615898db27d4bbd2dca5cac9615a    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 30 May 2012 23:28:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 30 May 2012 23:28:10 -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   : fea3ea1f23fb7f72aad28a55a09a60897a08dd3d    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 30 May 2012 19:58:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 30 May 2012 19:58:41 -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   : 8db2e820c96a0ce33d3c15f476aa78bebce2c732    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 30 May 2012 10:53:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 30 May 2012 10:53:36 -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   : cc2469b0925812424efc8aa24234fc3090a5e85e    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 28 May 2012 23:57:14 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 28 May 2012 23:57:14 -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   : 2791f2180d8e7c469fac2a4d88fc449689e4c970    
  
author   : Magnus Hagander <[email protected]>    
date     : Sun, 27 May 2012 10:54:31 +0200    
  
committer: Magnus Hagander <[email protected]>    
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   : 6c1bf45ea50a652d2b8efa778cabb63fdf422e70    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 26 May 2012 19:09:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 26 May 2012 19:09:59 -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   : 71e985a07a7ae9319c00629f319a4c30a9e32fd6    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 25 May 2012 17:34:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 25 May 2012 17:34:58 -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   : 1a93588ffcad3e4876c9610c0a35d79c7fcdeffe    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 25 May 2012 14:35:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 25 May 2012 14:35:41 -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   : 4615d2ca28fe9dff6e5ebaebd6caf190a0c78ba5    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 23 May 2012 19:58:17 +0300    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 23 May 2012 19:58:17 +0300    

And align a bit better with the rest of the debug output.  

commit   : 276bea211f08a3b0d6d5753b654322c8efb781d1    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 22 May 2012 19:42:12 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 22 May 2012 19:42:12 -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   : ae7c8b290f525504978c01d77366a753505d10d5    
  
author   : Robert Haas <[email protected]>    
date     : Tue, 22 May 2012 11:19:33 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Tue, 22 May 2012 11:19:33 -0400    

When the column name is an unqualified name, rather than table.column,  
the error message complains about too many dotted names, which is  
wrong.  Report by Peter Eisentraut based on examination of the  
sepgsql regression test output, but the problem also affects COMMENT.  
New wording as suggested by Tom Lane.  

commit   : 9255d21d2fe5209c96b712f96c799fe594f00f4b    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 May 2012 22:50:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 May 2012 22:50:35 -0400    

There is no reason to do this as early as possible in postmaster startup,  
and good reason not to do it until we have completely created the  
postmaster's lock file, namely that it might contribute to pg_ctl thinking  
that postmaster startup has timed out.  (This would require a rather  
unusual amount of time to be spent scanning temp file directories, but we  
have at least one field report of it happening reproducibly.)  
  
Back-patch to 9.1.  Before that, pg_ctl didn't wait for additional info to  
be added to the lock file, so it wasn't a problem.  
  
Note that this is not a complete fix to the slow-start issue in 9.1,  
because we still had identify_system_timezone being run during postmaster  
start in 9.1.  But that's at least a reasonably well-defined delay, with  
an easy workaround if needed, whereas the temp-files scan is not so  
predictable and cannot be avoided.  

commit   : 435a1437961d72c98a1dbd27c8a9fb75024730f9    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 15 May 2012 19:22:56 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
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   : 69c058ffc8949c6d86240b096196c4b6b64d87e0    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 13 May 2012 18:06:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 13 May 2012 18:06:57 -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   : 436af241c88a2f9b971dbe248e6ec6360438033c    
  
author   : Simon Riggs <[email protected]>    
date     : Sat, 12 May 2012 13:25:34 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Sat, 12 May 2012 13:25:34 +0100    

commit   : 2c1382d96c575a79a2ce014dda90fd1de78b3612    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 11 May 2012 15:22:37 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 11 May 2012 15:22:37 -0400    

We previously recognized that citext wouldn't get marked as collatable  
during pg_upgrade from a pre-9.1 installation, and hacked its  
create-from-unpackaged script to manually perform the necessary catalog  
adjustments.  However, we overlooked the fact that domains over citext,  
as well as the citext[] array type, need the same adjustments.  Extend  
the script to handle those cases.  
  
Also, the documentation suggested that this was only an issue in pg_upgrade  
scenarios, which is quite wrong; loading any dump containing citext from a  
pre-9.1 server will also result in the type being wrongly marked.  
  
I approached the documentation problem by changing the 9.1.2 release note  
paragraphs about this issue, which is historically inaccurate.  But it  
seems better than having the information scattered in multiple places, and  
leaving incorrect info in the 9.1.2 notes would be bad anyway.  We'll still  
need to mention the issue again in the 9.1.4 notes, but perhaps they can  
just reference 9.1.2 for fix instructions.  
  
Per report from Evan Carroll.  Back-patch into 9.1.  

commit   : 2ca6bac892aa650154f591c730359a968bea726a    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 11 May 2012 09:46:42 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 11 May 2012 09:46:42 -0400    

Fixes bug #6635, reported by Akira Kurosawa.  

commit   : f93e45d4071af89cf1b37c76fbd5976d11d77347    
  
author   : Simon Riggs <[email protected]>    
date     : Fri, 11 May 2012 14:46:19 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Fri, 11 May 2012 14:46:19 +0100    

commit   : 1a4bc2db6cb80a6e52aed8f5a68b895231653d6c    
  
author   : Simon Riggs <[email protected]>    
date     : Fri, 11 May 2012 14:38:11 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Fri, 11 May 2012 14:38:11 +0100    

commit   : 153b1dbaa0b94143041ab1e0cf249a02380f0acf    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 11 May 2012 12:35:33 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 11 May 2012 12:35:33 +0300    

When inserting the downlinks for a split gist page, we used hold the locks  
on the child pages until the insertion into the parent - and recursively its  
parent if it had to be split too - were all completed. Change that so that  
the locks on child pages are released after the insertion in the immediate  
parent is done, before recursing further up the tree.  
  
This reduces the number of lwlocks that are held simultaneously. Holding  
many locks is bad for concurrency, and in extreme cases you can even hit  
the limit of 100 simultaneously held lwlocks in a backend. If you're really  
unlucky, you can hit the limit while in a critical section, which brings  
down the whole system.  
  
This fixes bug #6629 reported by Tom Forbes. Backpatch to 9.1. The page  
splitting code was rewritten in 9.1, and the old code did not have this  
problem.  

commit   : 1b48f6af315e9db89aaf43e8c8c9de903294fbdf    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 10 May 2012 13:36:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 10 May 2012 13:36:18 -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   : 71ca53608de1763c0d82bf463580a30f634eba56    
  
author   : Magnus Hagander <[email protected]>    
date     : Thu, 10 May 2012 09:11:38 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Thu, 10 May 2012 09:11:38 +0200    

Show a proper error message instead of a SQL error.  
  
Josh Kupershmidt  

commit   : 05a86891232e1bd5e43d559f30bec2fc00131f37    
  
author   : Joe Conway <[email protected]>    
date     : Wed, 9 May 2012 22:53:17 -0700    
  
committer: Joe Conway <[email protected]>    
date     : Wed, 9 May 2012 22:53:17 -0700    

commit   : e7c43ddc266172f409f5d5bb3e571cafe7d14fa2    
  
author   : Simon Riggs <[email protected]>    
date     : Wed, 9 May 2012 13:59:30 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Wed, 9 May 2012 13:59:30 +0100    

commit   : 1c0e678678a661f8437ed238a5c515b81547aaf4    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 4 May 2012 17:43:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 4 May 2012 17:43:35 -0400    

Commit 62c7bd31c8878dd45c9b9b2429ab7a12103f3590 had assorted problems, most  
visibly that it broke PREPARE TRANSACTION in the presence of session-level  
advisory locks (which should be ignored by PREPARE), as per a recent  
complaint from Stephen Rees.  More abstractly, the patch made the  
LockMethodData.transactional flag not merely useless but outright  
dangerous, because in point of fact that flag no longer tells you anything  
at all about whether a lock is held transactionally.  This fix therefore  
removes that flag altogether.  We now rely entirely on the convention  
already in use in lock.c that transactional lock holds must be owned by  
some ResourceOwner, while session holds are never so owned.  Setting the  
locallock struct's owner link to NULL thus denotes a session hold, and  
there is no redundant marker for that.  
  
PREPARE TRANSACTION now works again when there are session-level advisory  
locks, and it is also able to transfer transactional advisory locks to the  
prepared transaction, but for implementation reasons it throws an error if  
we hold both types of lock on a single lockable object.  Perhaps it will be  
worth improving that someday.  
  
Assorted other minor cleanup and documentation editing, as well.  
  
Back-patch to 9.1, except that in the 9.1 branch I did not remove the  
LockMethodData.transactional flag for fear of causing an ABI break for  
any external code that might be examining those structs.  

commit   : 6d362ec209f0174f36a78936c5269f8d5f2cd26e    
  
author   : Magnus Hagander <[email protected]>    
date     : Thu, 3 May 2012 13:01:31 +0200    
  
committer: Magnus Hagander <[email protected]>    
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   : 08bc189ee746606b6417ed4a2f0f9d7901c5b8e1    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 27 Apr 2012 19:49:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 27 Apr 2012 19:49:26 -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   : 1869f000b0a31d71906ad6ac6e86b08a65f723f0    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 27 Apr 2012 00:12:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 27 Apr 2012 00:12:47 -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   : 4fa520f147992616a08e5dbb34620dc46d664fc2    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 26 Apr 2012 21:03:48 +0300    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 26 Apr 2012 21:03:48 +0300    

Before 9.1, PL/Python functions returning composite types could return  
a string and it would be parsed using record_in.  The 9.1 changes made  
PL/Python only expect dictionaries, tuples, or objects supporting  
getattr as output of composite functions, resulting in a regression  
and a confusing error message, as the strings were interpreted as  
sequences and the code for transforming lists to database tuples was  
used.  Fix this by treating strings separately as before, before  
checking for the other types.  
  
The reason why it's important to support string to database tuple  
conversion is that trigger functions on tables with composite columns  
get the composite row passed in as a string (from record_out).  
Without supporting converting this back using record_in, this makes it  
impossible to implement pass-through behavior for these columns, as  
PL/Python no longer accepts strings for composite values.  
  
A better solution would be to fix the code that transforms composite  
inputs into Python objects to produce dictionaries that would then be  
correctly interpreted by the Python->PostgreSQL counterpart code.  But  
that would be too invasive to backpatch to 9.1, and it is too late in  
the 9.2 cycle to attempt it.  It should be revisited in the future,  
though.  
  
Reported as bug #6559 by Kirill Simonov.  
  
Jan Urbański  

commit   : dc7521dcb9410167a4748d9702bfe05746d7d27a    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 25 Apr 2012 20:20:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 25 Apr 2012 20:20:43 -0400    

setrefs.c failed to do "rtoffset" adjustment of Vars in RETURNING lists,  
which meant they were left with the wrong varnos when the RETURNING list  
was in a subquery.  That was never possible before writable CTEs, of  
course, but now it's broken.  The executor fails to notice any problem  
because ExecEvalVar just references the ecxt_scantuple for any normal  
varno; but EXPLAIN breaks when the varno is wrong, as illustrated in a  
recent complaint from Bartosz Dmytrak.  
  
Since the eventual rtoffset of the subquery is not known at the time  
we are preparing its plan node, the previous scheme of executing  
set_returning_clause_references() at that time cannot handle this  
adjustment.  Fortunately, it turns out that we don't really need to do it  
that way, because all the needed information is available during normal  
setrefs.c execution; we just have to dig it out of the ModifyTable node.  
So, do that, and get rid of the kluge of early setrefs processing of  
RETURNING lists.  (This is a little bit of a cheat in the case of inherited  
UPDATE/DELETE, because we are not passing a "root" struct that corresponds  
exactly to what the subplan was built with.  But that doesn't matter, and  
anyway this is less ugly than early setrefs processing was.)  
  
Back-patch to 9.1, where the problem became possible to hit.  

commit   : bf0d462a9d85037558861d9c6d50d2eaa284cc34    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 25 Apr 2012 17:25:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 25 Apr 2012 17:25:18 -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   : f33f1a875f9b799da202408e118a47e4ee2bab7b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 25 Apr 2012 21:11:59 +0300    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 25 Apr 2012 21:11:59 +0300    

commit   : 342901930c1baefe49688c7d25a69196cf644180    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 18 Apr 2012 10:58:24 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 18 Apr 2012 10:58:24 -0400    

commit   : f8c53d5b411da9518876c93161199e38eaaa5118    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 18 Apr 2012 10:45:18 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Wed, 18 Apr 2012 10:45:18 -0400    

Noah Misch  

commit   : a146e7be893446521362d60d302d50dfe1001f13    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 17 Apr 2012 18:37:42 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 17 Apr 2012 18:37:42 -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   : 10fcfada235af6186c9474230483ab0fe5c9610d    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 17 Apr 2012 16:28:31 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 17 Apr 2012 16:28:31 +0300    

When using synchronous replication, we waited for the commit record to be  
replicated, but if we our transaction didn't write any other WAL records,  
that's not required because we don't even flush the WAL locally to disk in  
that case. This lead to long waits when committing a transaction that only  
modified a temporary table. Bug spotted by Thom Brown.  

commit   : 79853989c577cc90754d7562363bf802157864ae    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 11 Apr 2012 20:24:25 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 11 Apr 2012 20:24:25 -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   : 35400e14b8e0dea994862d0f16d275b35b5e31b3    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 11 Apr 2012 12:02:14 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 11 Apr 2012 12:02:14 -0400    

This aligns 9.1's behavior with that of older branches.  HEAD is now even  
laxer, ignoring missing schemas all the time, but that seems like too big  
a change for a released branch.  Per complaint from Robert Haas.  

commit   : 6cc2ed14f166604b11f85188724c47325ab37b4b    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 10 Apr 2012 19:57:14 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 10 Apr 2012 19:57:14 -0400    

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

commit   : 5cf6fddd63c29daab6daa6d0981d51c5f64b876a    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Apr 2012 20:49:06 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 Apr 2012 20:49:06 -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   : 0e20abdb47e3499353ac4fd1b2d21e82ec6b1461    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Apr 2012 11:58:24 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 88e071533fba70747aaf8d9b32fb927b7157ad16    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sun, 8 Apr 2012 19:39:12 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
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   : ef29bb1f7254222835267cc03389ed12602c677c    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Sun, 8 Apr 2012 18:28:12 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
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   : 63d8636c50f2ca053aa6a214340bb322bc5687d5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 Apr 2012 19:00:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 Apr 2012 19:00:18 -0400    

Thom Brown  

commit   : e2923d341994a0aa3881ca29f345c40a98b6cb60    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 Apr 2012 18:10:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 Apr 2012 18:10:26 -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   : 60243e89a707bb141aa1b164c2d6fb59e3e22408    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 4 Apr 2012 15:05:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 4 Apr 2012 15:05:16 -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   : 8d2a5fb219aab954fe6642a2c1abdaa058ddeaef    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 3 Apr 2012 20:43:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 3 Apr 2012 20:43:20 -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   : 99e2076bc73fe20c856986c50f4eafefa23edc38    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 31 Mar 2012 15:51:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 31 Mar 2012 15:51:11 -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   : fa76bb0168326b322a5dbb2cdffed51c79289cde    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 31 Mar 2012 14:42:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 31 Mar 2012 14:42:23 -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   : dde1813dff577991a71bd3beedb333cd2ad2559f    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 29 Mar 2012 17:52:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 29 Mar 2012 17:52:33 -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   : 20d98ab6e4110087d1816cd105a40fcc8ce0a307    
  
author   : Simon Riggs <[email protected]>    
date     : Thu, 29 Mar 2012 14:57:08 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Thu, 29 Mar 2012 14:57:08 +0100    

Bug report from Daniel Farina  

commit   : 4d278b785e22ff8d56ac86d5ed1871e096b2ea80    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 28 Mar 2012 12:19:22 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Wed, 28 Mar 2012 12:19:22 -0400    

Thomas Ogrisegg and Fujii Masao  

commit   : 9f0a01707607e476ac3a89854777cdba76e0ff37    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 25 Mar 2012 23:17:27 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 25 Mar 2012 23:17:27 -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   : 811a2cbc167bfef4e5a88d468d5258385318ad87    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 24 Mar 2012 16:21:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 24 Mar 2012 16:21:48 -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   : eca0c389f185b6bd76b4ca77195aa47d2e90dbb2    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 23 Mar 2012 20:18:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 23 Mar 2012 20:18:08 -0400    

Per compiler warnings on buildfarm member black_firefly.  

commit   : 10b2e7404f80ef26a3a6df6b1a9121bd16efb905    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 22 Mar 2012 15:40:27 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 22 Mar 2012 15:40:27 -0400    

Since 9.1, the minimum overhead is three bytes, not five.  
  
Fujii Masao  

commit   : f318ee848c9a7c3dd289fe67245e4a12ba136bca    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 22 Mar 2012 14:13:17 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 5bd06e619c82c3b2e29fed40aae5fc39a9620908    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 21 Mar 2012 13:04:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 21 Mar 2012 13:04:07 -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   : 16f42be840bc7a96fb008055632388954c3548ba    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 21 Mar 2012 12:38:34 -0400    
  
committer: Robert Haas <[email protected]>    
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   : 04e9dc6e01dd8acb1b477c1649172dfbda822581    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 21 Mar 2012 17:43:53 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 21 Mar 2012 17:43:53 +0200    

The problem was that ResetLatch was not being called in the walsender loop  
if the connection was terminated, so WaitLatch never sleeps until the  
terminated connection is detected. In the master-branch, this was already  
fixed as a side-effect of some refactoring of the loop. This commit  
backports that refactoring to 9.1. 9.0 does not have this bug, because we  
didn't use latches back then.  
  
Fujii Masao  

commit   : 52b03fbdfed752ff10620d44eb808b09baf29add    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 20 Mar 2012 13:14:16 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 20 Mar 2012 13:14:16 -0300    

commit   : bceef1bcbefec400e35789c3ffb9fbdd1ee534d9    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 19 Mar 2012 17:29:05 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 19 Mar 2012 17:29:05 -0300    

Failing to do so causes trigger invocation to fail when they are nested  
within a function invocation that changes the current package.  
  
Backpatch to 9.1; previous releases used a different method to obtain  
_TD.  Per bug report from Mark Murawski (bug #6511)  
  
Author: Alex Hunsaker  

commit   : 28155746150f584e8147e2e3f68fec8c0d819cbf    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 19 Mar 2012 09:31:50 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 19 Mar 2012 09:31:50 -0400    

Backpatch to 9.1.  
  
Report from Àlvaro  

commit   : ed79eddba9367f1e35e480e87cbaafc18b9f75ca    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 17 Mar 2012 17:30:52 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 17 Mar 2012 17:30:52 -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   : b6948e15464d7e86c0d892619d9c90c9cfd124f1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 16 Mar 2012 19:53:31 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 16 Mar 2012 19:53:31 +0200    

found by Coverity  

commit   : 805f798e0ef0030b0f475a7a56322c51b5ef38b3    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 16 Mar 2012 13:11:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 16 Mar 2012 13:11:20 -0400    

In commit 57664ed25e5dea117158a2e663c29e60b3546e1c I tried to fix a bug  
reported by Teodor Sigaev by making non-simple-Var output columns distinct  
(by wrapping their expressions with dummy PlaceHolderVar nodes).  This did  
not work too well.  Commit b28ffd0fcc583c1811e5295279e7d4366c3cae6c fixed  
some ensuing problems with matching to child indexes, but per a recent  
report from Claus Stadler, constraint exclusion of UNION ALL subqueries was  
still broken, because constant-simplification didn't handle the injected  
PlaceHolderVars well either.  On reflection, the original patch was quite  
misguided: there is no reason to expect that EquivalenceClass child members  
will be distinct.  So instead of trying to make them so, we should ensure  
that we can cope with the situation when they're not.  
  
Accordingly, this patch reverts the code changes in the above-mentioned  
commits (though the regression test cases they added stay).  Instead, I've  
added assorted defenses to make sure that duplicate EC child members don't  
cause any problems.  Teodor's original problem ("MergeAppend child's  
targetlist doesn't match MergeAppend") is addressed more directly by  
revising prepare_sort_from_pathkeys to let the parent MergeAppend's sort  
list guide creation of each child's sort list.  
  
In passing, get rid of add_sort_column; as far as I can tell, testing for  
duplicate sort keys at this stage is dead code.  Certainly it doesn't  
trigger often enough to be worth expending cycles on in ordinary queries.  
And keeping the test would've greatly complicated the new logic in  
prepare_sort_from_pathkeys, because comparing pathkey list entries against  
a previous output array requires that we not skip any entries in the list.  
  
Back-patch to 9.1, like the previous patches.  The only known issue in  
this area that wasn't caused by the ill-advised previous patches was the  
MergeAppend planning failure, which of course is not relevant before 9.1.  
It's possible that we need some of the new defenses against duplicate child  
EC entries in older branches, but until there's some clear evidence of that  
I'm going to refrain from back-patching further.  

commit   : 0cb4a0bfb80c7d75c745faf3597bed5c3f9a3c49    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 13 Mar 2012 15:26:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 13 Mar 2012 15:26:36 -0400    

Dave Malcolm of Red Hat is working on a static code analysis tool for  
Python-related C code.  It reported a number of problems in plpython,  
most of which were failures to check for NULL results from object-creation  
functions, so would only be an issue in very-low-memory situations.  
  
Patch in HEAD and 9.1.  We could go further back but it's not clear that  
these issues are important enough to justify the work.  
  
Jan Urbański  

commit   : 5a264d4aa09466746de6311e3728d094f01f325f    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 12 Mar 2012 10:13:39 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 12 Mar 2012 10:13:39 -0400    

commit   : 66d3e691dbfdd4af56e19303bbfa36dbdd561dce    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Sun, 11 Mar 2012 19:24:34 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Sun, 11 Mar 2012 19:24:34 +0900    

commit   : 3043608cf72b0abd8b022034080f44cc29ff0cf5    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 8 Mar 2012 22:29:01 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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   : 6f59d42b943e721c6ddf9513e3e82067ca40bce5    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 8 Mar 2012 22:21:12 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 8 Mar 2012 22:21:12 +0200    

found by Coverity  

commit   : 46c9f5d6f0bf680708fbd7c1972a31b58fab5f35    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 7 Mar 2012 23:46:41 +0200    
  
committer: Peter Eisentraut <[email protected]>    
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   : 0ba7ff5fa542c1cf77bac001c534ff0c82b2fde2    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 7 Mar 2012 23:35:03 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 7 Mar 2012 23:35:03 +0200    

If a client encoding is specified as a connection parameter (or  
environment variable), internal storage allocated for it would never  
be freed.  

commit   : ad05b5d28d99e1511a10b542c72ada2e97cc0228    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 8 Mar 2012 15:52:34 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 8 Mar 2012 15:52:34 -0500    

Phil Sorber reported that a rewriting ALTER TABLE within an extension  
update script failed, because it creates and then drops a placeholder  
table; the drop was being disallowed because the table was marked as an  
extension member.  We could hack that specific case but it seems likely  
that there might be related cases now or in the future, so the most  
practical solution seems to be to create an exception to the general rule  
that extension member objects can only be dropped by dropping the owning  
extension.  To wit: if the DROP is issued within the extension's own  
creation or update scripts, we'll allow it, implicitly performing an  
"ALTER EXTENSION DROP object" first.  This will simplify cases such as  
extension downgrade scripts anyway.  
  
No docs change since we don't seem to have documented the idea that you  
would need ALTER EXTENSION DROP for such an action to begin with.  
  
Also, arrange for explicitly temporary tables to not get linked as  
extension members in the first place, and the same for the magic  
pg_temp_nnn schemas that are created to hold them.  This prevents assorted  
unpleasant results if an extension script creates a temp table: the forced  
drop at session end would either fail or remove the entire extension, and  
neither of those outcomes is desirable.  Note that this doesn't fix the  
ALTER TABLE scenario, since the placeholder table is not temp (unless the  
table being rewritten is).  
  
Back-patch to 9.1.  

commit   : 610fd3442d12f0a2774456be795120759fd3f9c3    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 7 Mar 2012 17:19:18 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Wed, 7 Mar 2012 17:19:18 -0500    

Commit 3e9a2672d25aed15ae6b4a09decbd8927d069868 fixed this for master,  
but REL9_1_STABLE also needs fixing; this is a back-branch commit only.  
  
Tomas Vondra  

commit   : e076ee6d3f1bf9ece52eb7c9dacea8f91e4c991c    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 5 Mar 2012 14:08:57 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 5 Mar 2012 14:08:57 -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   : ef03b34550e3577c4be3baa25b70787f5646c57b    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 2 Mar 2012 14:28:49 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 2 Mar 2012 14:28:49 -0500    

This fixes an oversight in commit 11cad29c91524aac1d0b61e0ea0357398ab79bf8,  
which introduced MergeAppend plans.  Before that happened, we never  
particularly cared about the sort ordering of scans of inheritance child  
relations, since appending their outputs together would destroy any  
ordering anyway.  But now it's important to be able to match child relation  
sort orderings to those of the surrounding query.  The original coding of  
add_child_rel_equivalences skipped ec_has_const EquivalenceClasses, on the  
originally-correct grounds that adding child expressions to them was  
useless.  The effect of this is that when a parent variable is equated to  
a constant, we can't recognize that index columns on the equivalent child  
variables are not sort-significant; that is, we can't recognize that a  
child index on, say, (x, y) is able to generate output in "ORDER BY y"  
order when there is a clause "WHERE x = constant".  Adding child  
expressions to the (x, constant) EquivalenceClass fixes this, without any  
downside that I can see other than a few more planner cycles expended on  
such queries.  
  
Per recent gripe from Robert McGehee.  Back-patch to 9.1 where MergeAppend  
was introduced.  

commit   : af1967239a90a5860e2158ebe814a7bcd42e6c6b    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 29 Feb 2012 12:11:10 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 29 Feb 2012 12:11:10 -0500    

Several places were still written as though standard_conforming_strings  
didn't exist, much less be the default.  Now that it is on by default,  
we can simplify the text and just insert occasional notes suggesting that  
you might have to think harder if it's turned off.  Per discussion of a  
suggestion from Hannes Frederic Sowa.  
  
Back-patch to 9.1 where standard_conforming_strings was made the default.  

commit   : 86073a2b7acc58fce8701a9207a46adb41fbd8cc    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 29 Feb 2012 15:22:49 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 29 Feb 2012 15:22:49 +0200    

A prepared transaction can get new conflicts in and out after preparing, so  
we cannot rely on the in- and out-flags stored in the statefile at prepare-  
time. As a quick fix, make the conservative assumption that after a restart,  
all prepared transactions are considered to have both in- and out-conflicts.  
That can lead to unnecessary rollbacks after a crash, but that shouldn't be  
a big problem in practice; you don't want prepared transactions to hang  
around for a long time anyway.  
  
Dan Ports  

commit   : 57b100fe0fb1d0d5803789d3113b89fa18a34fad    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 26 Feb 2012 15:12:23 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 26 Feb 2012 15:12:23 -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.