PostgreSQL 9.1.3 commit log

commit   : 64c47e4542910ebbfb494bec3f8abf8733113394    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 23 Feb 2012 17:53:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 23 Feb 2012 17:53:36 -0500    

commit   : 22795f096b521e975800cd2fff222f958500ef19    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 23 Feb 2012 17:47:59 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 23 Feb 2012 17:47:59 -0500    

Security: CVE-2012-0866, CVE-2012-0867, CVE-2012-0868  

commit   : 2d2f63ddccc6a557e7eb35252483fea7fe4a688a    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 23 Feb 2012 15:53:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 23 Feb 2012 15:53:17 -0500    

pg_dump was incautious about sanitizing object names that are emitted  
within SQL comments in its output script.  A name containing a newline  
would at least render the script syntactically incorrect.  Maliciously  
crafted object names could present a SQL injection risk when the script  
is reloaded.  
  
Reported by Heikki Linnakangas, patch by Robert Haas  
  
Security: CVE-2012-0868  

commit   : e6fcb03dc0de1771f7d408b5df1738272e6f98e5    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 23 Feb 2012 15:48:09 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 23 Feb 2012 15:48:09 -0500    

Both libpq and the backend would truncate a common name extracted from a  
certificate at 32 bytes.  Replace that fixed-size buffer with dynamically  
allocated string so that there is no hard limit.  While at it, remove the  
code for extracting peer_dn, which we weren't using for anything; and  
don't bother to store peer_cn longer than we need it in libpq.  
  
This limit was not so terribly unreasonable when the code was written,  
because we weren't using the result for anything critical, just logging it.  
But now that there are options for checking the common name against the  
server host name (in libpq) or using it as the user's name (in the server),  
this could result in undesirable failures.  In the worst case it even seems  
possible to spoof a server name or user name, if the correct name is  
exactly 32 bytes and the attacker can persuade a trusted CA to issue a  
certificate in which that string is a prefix of the certificate's common  
name.  (To exploit this for a server name, he'd also have to send the  
connection astray via phony DNS data or some such.)  The case that this is  
a realistic security threat is a bit thin, but nonetheless we'll treat it  
as one.  
  
Back-patch to 8.4.  Older releases contain the faulty code, but it's not  
a security problem because the common name wasn't used for anything  
interesting.  
  
Reported and patched by Heikki Linnakangas  
  
Security: CVE-2012-0867  

commit   : 54e2b6488bb294691a525a272d6f614ac2046282    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 23 Feb 2012 15:39:02 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 23 Feb 2012 15:39:02 -0500    

This check was overlooked when we added function execute permissions to the  
system years ago.  For an ordinary trigger function it's not a big deal,  
since trigger functions execute with the permissions of the table owner,  
so they couldn't do anything the user issuing the CREATE TRIGGER couldn't  
have done anyway.  However, if a trigger function is SECURITY DEFINER,  
that is not the case.  The lack of checking would allow another user to  
install it on his own table and then invoke it with, essentially, forged  
input data; which the trigger function is unlikely to realize, so it might  
do something undesirable, for instance insert false entries in an audit log  
table.  
  
Reported by Dinesh Kumar, patch by Robert Haas  
  
Security: CVE-2012-0866  

commit   : 630fa6f308ad1652ffc11c0001aaa35018ea81ce    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 23 Feb 2012 15:05:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 23 Feb 2012 15:05:17 -0500    

In the Fedora variant of MinGW, the openssl libraries have their normal  
names, not libeay32 and libssleay32.  Adjust configure probes to allow  
that, per bug #6486.  
  
Tomasz Ostrowski  

commit   : 602dd1eeaad14a4bef92045956de7e7249f8b38e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 23 Feb 2012 20:40:55 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 23 Feb 2012 20:40:55 +0200    

commit   : 09c00af94ea684be55a5790474c8bff11639bf17    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 23 Feb 2012 12:51:33 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 23 Feb 2012 12:51:33 +0200    

And adjust wording for consistency.  

commit   : f209a0c559a68c77144ef99ea692b8b65f50c47e    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 22 Feb 2012 18:11:51 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 22 Feb 2012 18:11:51 -0500    

commit   : cfd1c382f0e85dea157ec6d56352d0513f7b7f0f    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 21 Feb 2012 17:58:02 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 21 Feb 2012 17:58:02 -0300    

This was overlooked when implementing those kinds of objects, in commit  
cae565e503c42a0942ca1771665243b4453c5770.  
  
Per report from Pawel Casperek.  

commit   : 11c730f4122ee8677b1cfdd5647faeaabc471af8    
  
author   : Simon Riggs <[email protected]>    
date     : Wed, 22 Feb 2012 13:53:48 +0000    
  
committer: Simon Riggs <[email protected]>    
date     : Wed, 22 Feb 2012 13:53:48 +0000    

Fujii Masao  

commit   : 6182e01f18f71c48915e2aebb20362294de6e677    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 21 Feb 2012 15:03:44 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 21 Feb 2012 15:03:44 -0500    

When "vacuuming" a single btree page by removing LP_DEAD tuples, we are not  
actually within a vacuum operation, but rather in an ordinary insertion  
process that could well be running concurrently with a vacuum.  So clearing  
the cycleid is incorrect, and could cause the concurrent vacuum to miss  
removing tuples that it needs to remove.  This is a longstanding bug  
introduced by commit e6284649b9e30372b3990107a082bc7520325676 of  
2006-07-25.  I believe it explains Maxim Boguk's recent report of index  
corruption, and probably some other previously unexplained reports.  
  
In 9.0 and up this is a one-line fix; before that we need to introduce a  
flag to tell _bt_delitems what to do.  

commit   : 3d2aa2c086116fd41dc7f8cff1e3ec9e5d4e2b2c    
  
author   : Magnus Hagander <[email protected]>    
date     : Tue, 21 Feb 2012 17:12:25 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Tue, 21 Feb 2012 17:12:25 +0100    

This causes an exception when running under a debugger or in particular  
when running on a debug version of Windows.  
  
Patch from MauMau  

commit   : f22bd1570e5bc820d7493d7c60d42634c6403171    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 20 Feb 2012 16:21:35 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 20 Feb 2012 16:21:35 -0500    

According to Chris Rees, this has worked for awhile, and the current  
FreeBSD port is removing the test anyway.  

commit   : d3158f339f7580ce7eeb71a6f2da0b1813aa3684    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 20 Feb 2012 00:52:42 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 20 Feb 2012 00:52:42 -0500    

The syntax "\n*", that is a backref with a * quantifier directly applied  
to it, has never worked correctly in Spencer's library.  This has been an  
open bug in the Tcl bug tracker since 2005:  
https://sourceforge.net/tracker/index.php?func=detail&aid=1115587&group_id=10894&atid=110894  
  
The core of the problem is in parseqatom(), which first changes "\n*" to  
"\n+|" and then applies repeat() to the NFA representing the backref atom.  
repeat() thinks that any arc leading into its "rp" argument is part of the  
sub-NFA to be repeated.  Unfortunately, since parseqatom() already created  
the arc that was intended to represent the empty bypass around "\n+", this  
arc gets moved too, so that it now leads into the state loop created by  
repeat().  Thus, what was supposed to be an "empty" bypass gets turned into  
something that represents zero or more repetitions of the NFA representing  
the backref atom.  In the original example, in place of  
	^([bc])\1*$  
we now have something that acts like  
	^([bc])(\1+|[bc]*)$  
At runtime, the branch involving the actual backref fails, as it's supposed  
to, but then the other branch succeeds anyway.  
  
We could no doubt fix this by some rearrangement of the operations in  
parseqatom(), but that code is plenty ugly already, and what's more the  
whole business of converting "x*" to "x+|" probably needs to go away to fix  
another problem I'll mention in a moment.  Instead, this patch suppresses  
the *-conversion when the target is a simple backref atom, leaving the case  
of m == 0 to be handled at runtime.  This makes the patch in regcomp.c a  
one-liner, at the cost of having to tweak cbrdissect() a little.  In the  
event I went a bit further than that and rewrote cbrdissect() to check all  
the string-length-related conditions before it starts comparing characters.  
It seems a bit stupid to possibly iterate through many copies of an  
n-character backreference, only to fail at the end because the target  
string's length isn't a multiple of n --- we could have found that out  
before starting.  The existing coding could only be a win if integer  
division is hugely expensive compared to character comparison, but I don't  
know of any modern machine where that might be true.  
  
This does not fix all the problems with quantified back-references.  In  
particular, the code is still broken for back-references that appear within  
a larger expression that is quantified (so that direct insertion of the  
quantification limits into the BACKREF node doesn't apply).  I think fixing  
that will take some major surgery on the NFA code, specifically introducing  
an explicit iteration node type instead of trying to transform iteration  
into concatenation of modified regexps.  
  
Back-patch to all supported branches.  In HEAD, also add a regression test  
case for this.  (It may seem a bit silly to create a regression test file  
for just one test case; but I'm expecting that we will soon import a whole  
bunch of regex regression tests from Tcl, so might as well create the  
infrastructure now.)  

commit   : 86328cbc348a6c2614bd1fddbf21380a92417e04    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 16 Feb 2012 20:00:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 16 Feb 2012 20:00:17 -0500    

The array intersection code would give wrong results if the first entry of  
the correct output array would be "1".  (I think only this value could be  
at risk, since the previous word would always be a lower-bound entry with  
that fixed value.)  
  
Problem spotted by Julien Rouhaud, initial patch by Guillaume Lelarge,  
cosmetic improvements by me.  

commit   : 04a0231e56c4f401b681fe8a87829b4d11cd18ce    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 15 Feb 2012 16:18:39 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 15 Feb 2012 16:18:39 -0500    

This extends the changes of commit 6252c4f9e201f619e5eebda12fa867acd4e4200e  
so that we run the cleanup hook earlier for failure cases as well as  
success cases.  As before, the point is to avoid an assertion failure from  
an Assert I added in commit a874fe7b4c890d1fe3455215a83ca777867beadd, which  
was meant to check that no user-written code can be called during portal  
cleanup.  This fixes a case reported by Pavan Deolasee in which the Assert  
could be triggered during backend exit (see the new regression test case),  
and also prevents the possibility that the cleanup hook is run after  
portions of the portal's state have already been recycled.  That doesn't  
really matter in current usage, but it foreseeably could matter in the  
future.  
  
Back-patch to 9.1 where the Assert in question was added.  

commit   : 421513ba84a0efb4a6690c5a2e1062947804e4d3    
  
author   : Michael Meskes <[email protected]>    
date     : Mon, 13 Feb 2012 13:19:57 +0100    
  
committer: Michael Meskes <[email protected]>    
date     : Mon, 13 Feb 2012 13:19:57 +0100    

With a unique counter being added anyway, there is no need anymore to have the variable name listed, too.  

commit   : 6c1603cd8a6a90c6d1b509fb199edaab383ecf58    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 13 Feb 2012 08:22:54 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 13 Feb 2012 08:22:54 -0500    

Problem reported by Peter Eisentraut.  
  
Backpatched to release 9.0.  

commit   : 6fb17aeeab87dafca42a9db49ecb152a967d155c    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 11 Feb 2012 18:06:29 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 11 Feb 2012 18:06:29 -0500    

Datatype I/O functions are allowed to leak memory in CurrentMemoryContext,  
since they are generally called in short-lived contexts.  However, plpgsql  
calls such functions for purposes of type conversion, and was calling them  
in its procedure context.  Therefore, any leaked memory would not be  
recovered until the end of the plpgsql function.  If such a conversion  
was done within a loop, quite a bit of memory could get consumed.  Fix by  
calling such functions in the transient "eval_econtext", and adjust other  
logic to match.  Back-patch to all supported versions.  
  
Andres Freund, Jan Urbański, Tom Lane  

commit   : dd4e0a38781e0c48409f0c092b04b2ec75ed1a7e    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 10 Feb 2012 15:22:14 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 10 Feb 2012 15:22:14 -0500    

If an extension has not been selected to be dumped (perhaps because of  
a --schema or --table switch), the contents of its configuration tables  
surely should not get dumped either.  Per gripe from  
Hubert Depesz Lubaczewski.  

commit   : e565eff45a7d2cec6148cb5942d24ad0ebfbb1af    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 10 Feb 2012 14:09:25 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 10 Feb 2012 14:09:25 -0500    

In pre-7.3 databases, pg_attribute.attislocal doesn't exist.  The easiest  
way to make sure the new inheritance logic behaves sanely is to assume it's  
TRUE, not FALSE.  This will result in printing child columns even when  
they're not really needed.  We could work harder at trying to reconstruct a  
value for attislocal, but there is little evidence that anyone still cares  
about dumping from such old versions, so just do the minimum necessary to  
have a valid dump.  
  
I had this correct in the original draft of the patch, but for some  
unaccountable reason decided it wasn't necessary to change the value.  
Testing against an old server shows otherwise...  

commit   : 182228bd747caa362664bff525fc8346a37da16e    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 10 Feb 2012 13:28:10 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 10 Feb 2012 13:28:10 -0500    

Revise pg_dump's handling of inherited columns, which was last looked at  
seriously in 2001, to eliminate several misbehaviors associated with  
inherited default expressions and NOT NULL flags.  In particular make sure  
that a column is printed in a child table's CREATE TABLE command if and  
only if it has attislocal = true; the former behavior would sometimes cause  
a column to become marked attislocal when it was not so marked in the  
source database.  Also, stop relying on textual comparison of default  
expressions to decide if they're inherited; instead, don't use  
default-expression inheritance at all, but just install the default  
explicitly at each level of the hierarchy.  This fixes the  
search-path-related misbehavior recently exhibited by Chester Young, and  
also removes some dubious assumptions about the order in which ALTER TABLE  
SET DEFAULT commands would be executed.  
  
Back-patch to all supported branches.  

commit   : 1e7d008bf899764f20b8f23bc182886f908277f9    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 8 Feb 2012 16:19:31 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 8 Feb 2012 16:19:31 -0500    

Throwing an error only after we've built the main index fork is pretty  
unfriendly when the table already contains data.  Per gripe from Jay  
Levitt.  

commit   : ef19c9dfaa99a2b78ed0f78aa4a44ed31636fdc4    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Feb 2012 15:29:26 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Feb 2012 15:29:26 -0500    

The postmaster was coded to treat any unexpected exit of the startup  
process (i.e., the WAL replay process) as a catastrophic crash, and not try  
to restart it. This was OK so long as the startup process could not have  
any sibling postmaster children.  However, if a hot-standby backend  
crashes, we SIGQUIT the startup process along with everything else, and the  
resulting exit is hardly "unexpected".  Treating it as such meant we failed  
to restart a standby server after any child crash at all, not only a crash  
of the WAL replay process as intended.  Adjust that.  Back-patch to 9.0  
where hot standby was introduced.  

commit   : c74ad4e55bf9142478192e5507555ac2c95e0985    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Feb 2012 14:44:04 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Feb 2012 14:44:04 -0500    

Although we will not even issue an XLOG_TBLSPC_DROP WAL record unless  
removal of the tablespace's directories succeeds, that does not guarantee  
that the same operation will succeed during WAL replay.  Foreseeable  
reasons for it to fail include temp files created in the tablespace by Hot  
Standby backends, wrong directory permissions on a standby server, etc etc.  
The original coding threw ERROR if replay failed to remove the directories,  
but that is a serious overreaction.  Throwing an error aborts recovery,  
and worse means that manual intervention will be needed to get the database  
to start again, since otherwise the same error will recur on subsequent  
attempts to replay the same WAL record.  And the consequence of failing to  
remove the directories is only that some probably-small amount of disk  
space is wasted, so it hardly seems justified to throw an error.  
Accordingly, arrange to report such failures as LOG messages and keep going  
when a failure occurs during replay.  
  
Back-patch to 9.0 where Hot Standby was introduced.  In principle such  
problems can occur in earlier releases, but Hot Standby increases the odds  
of trouble significantly.  Given the lack of field reports of such issues,  
I'm satisfied with patching back as far as the patch applies easily.  

commit   : f1b8a84dec30b44e6a0b306f95961f5426cb8368    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 6 Feb 2012 13:14:46 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 6 Feb 2012 13:14:46 -0500    

Fix a longstanding thinko in replay of NEXTOID and checkpoint records: we  
tried to advance nextOid only if it was behind the value in the WAL record,  
but the comparison would draw the wrong conclusion if OID wraparound had  
occurred since the previous value.  Better to just unconditionally assign  
the new value, since OID assignment shouldn't be happening during replay  
anyway.  
  
The consequences of a failure to update nextOid would be pretty minimal,  
since we have long had the code set up to obtain another OID and try again  
if the generated value is already in use.  But in the worst case there  
could be significant performance glitches while such loops iterate through  
many already-used OIDs before finding a free one.  
  
The odds of a wraparound happening during WAL replay would be small in a  
crash-recovery scenario, and the length of any ensuing OID-assignment stall  
quite limited anyway.  But neither of these statements hold true for a  
replication slave that follows a WAL stream for a long period; its behavior  
upon going live could be almost unboundedly bad.  Hence it seems worth  
back-patching this fix into all supported branches.  
  
Already fixed in HEAD in commit c6d76d7c82ebebb7210029f7382c0ebe2c558bca.  

commit   : 2a846719090eff235ac8dd7815e51859e834331d    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 6 Feb 2012 11:50:01 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 6 Feb 2012 11:50:01 -0300    

Declare this in Makefile to avoid failures in parallel compiles.  
  
Author: Lionel Elie Mamane  

commit   : b2e1eaa4a1e5d4a624d2628cd485ba04f6fcfc4a    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 5 Feb 2012 15:49:17 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 5 Feb 2012 15:49:17 -0500    

RestoreBkpBlocks was in the habit of zeroing and refilling the target  
buffer; which was perfectly safe when the code was written, but is unsafe  
during Hot Standby operation.  The reason is that we have coding rules  
that allow backends to continue accessing a tuple in a heap relation while  
holding only a pin on its buffer.  Such a backend could see transiently  
zeroed data, if WAL replay had occasion to change other data on the page.  
This has been shown to be the cause of bug #6425 from Duncan Rance (who  
deserves kudos for developing a sufficiently-reproducible test case) as  
well as Bridget Frey's re-report of bug #6200.  It most likely explains the  
original report as well, though we don't yet have confirmation of that.  
  
To fix, change the code so that only bytes that are supposed to change will  
change, even transiently.  This actually saves cycles in RestoreBkpBlocks,  
since it's not writing the same bytes twice.  
  
Also fix seq_redo, which has the same disease, though it has to work a bit  
harder to meet the requirement.  
  
So far as I can tell, no other WAL replay routines have this type of bug.  
In particular, the index-related replay routines, which would certainly be  
broken if they had to meet the same standard, are not at risk because we  
do not have coding rules that allow access to an index page when not  
holding a buffer lock on it.  
  
Back-patch to 9.0 where Hot Standby was added.  

commit   : 8572cc495cd07d4f4a59624d275a75b45340a3b2    
  
author   : Simon Riggs <[email protected]>    
date     : Wed, 1 Feb 2012 09:31:07 +0000    
  
committer: Simon Riggs <[email protected]>    
date     : Wed, 1 Feb 2012 09:31:07 +0000    

Simon Riggs, bug report Tom Lane, diagnosis Pavan Deolasee  

commit   : b896e1e8527b7b4831222b5f7739c860dc922059    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 30 Jan 2012 10:32:46 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 30 Jan 2012 10:32:46 +0200    

When default_text_search_config, default_tablespace, or temp_tablespaces  
setting is set per-user or per-database, with an "ALTER USER/DATABASE SET  
..." statement, don't throw an error if the text search configuration or  
tablespace does not exist. In case of text search configuration, even if  
it doesn't exist in the current database, it might exist in another  
database, where the setting is intended to have its effect. This behavior  
is now the same as search_path's.  
  
Tablespaces are cluster-wide, so the same argument doesn't hold for  
tablespaces, but there's a problem with pg_dumpall: it dumps "ALTER USER  
SET ..." statements before the "CREATE TABLESPACE" statements. Arguably  
that's pg_dumpall's fault - it should dump the statements in such an order  
that the tablespace is created first and then the "ALTER USER SET  
default_tablespace ..." statements after that - but it seems better to be  
consistent with search_path and default_text_search_config anyway. Besides,  
you could still create a dump that throws an error, by creating the  
tablespace, running "ALTER USER SET default_tablespace", then dropping the  
tablespace and running pg_dumpall on that.  
  
Backpatch to all supported versions.  

commit   : 106123fa269de39e5215eb8808889a78c9a45fe7    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 29 Jan 2012 16:31:31 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 29 Jan 2012 16:31:31 -0500    

In commit 57664ed25e5dea117158a2e663c29e60b3546e1c, I made the planner  
wrap non-simple-variable outputs of appendrel children (IOW, child SELECTs  
of UNION ALL subqueries) inside PlaceHolderVars, in order to solve some  
issues with EquivalenceClass processing.  However, this means that any  
upper-level WHERE clauses mentioning such outputs will now contain  
PlaceHolderVars after they're pushed down into the appendrel child,  
and that prevents indxpath.c from recognizing that they could be matched  
to index expressions.  To fix, add explicit stripping of PlaceHolderVars  
from index operands, same as we have long done for RelabelType nodes.  
Add a regression test covering both this and the plain-UNION case (which  
is a totally different code path, but should also be able to do it).  
  
Per bug #6416 from Matteo Beccati.  Back-patch to 9.1, same as the  
previous change.  

commit   : b3bd5a093f3758cf168dae88478f9fc5b37ff6b1    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 28 Jan 2012 20:54:56 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 28 Jan 2012 20:54:56 -0500    

The sort order is no longer fixed at database creation time, but can be  
controlled via COLLATE.  Noted by Thomas Kellerer.  

commit   : 1a096957d747a3bc93abe65722c919c8a40a1049    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 28 Jan 2012 20:24:49 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 28 Jan 2012 20:24:49 -0500    

Formerly we passed an empty list to each per-child-table invocation of  
grouping_planner, and then merged the results into the global list.  
However, that fails if there's a CTE attached to the statement, because  
create_ctescan_plan uses the list to find the plan referenced by a CTE  
reference; so it was unable to find any CTEs attached to the outer UPDATE  
or DELETE.  But there's no real reason not to use the same list throughout  
the process, and doing so is simpler and faster anyway.  
  
Per report from Josh Berkus of "could not find plan for CTE" failures.  
Back-patch to 9.1 where we added support for WITH attached to UPDATE or  
DELETE.  Add some regression test cases, too.  

commit   : 0b1e1779533081f9d48c110a5e91ba122fc54461    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 28 Jan 2012 17:44:03 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 28 Jan 2012 17:44:03 -0500    

We can't just skip initializing such subplans, because the referencing CTE  
node will expect to find the subplan available when it initializes.  That  
in turn means that ExecInitModifyTable must allow the case (which actually  
it needed to do anyway, since there's no guarantee that ModifyTable is  
exactly at the top of the CTE plan tree).  So move the complaint about not  
being allowed in EvalPlanQual mode to execution instead of initialization.  
Testing turned up yet another problem, which is that we'd try to  
re-initialize the result relation's index list, leading to leaks and  
dangling pointers.  
  
Per report from Phil Sorber.  Back-patch to 9.1 where data-modifying CTEs  
were introduced.  

commit   : 7c016e3f56e2a7d8e9dd00a6d2d80bdc2239424e    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 27 Jan 2012 23:09:16 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 27 Jan 2012 23:09:16 -0500    

Due to oversights, the encrypt_iv() and decrypt_iv() functions failed to  
report certain types of invalid-input errors, and would instead return  
random garbage values.  
  
Marko Kreen, per report from Stefan Kaltenbrunner  

commit   : b7922a6dd0ec2ff949751d77b004576c820de19c    
  
author   : Magnus Hagander <[email protected]>    
date     : Fri, 27 Jan 2012 10:36:27 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Fri, 27 Jan 2012 10:36:27 +0100    

commit   : e96fcb06b9721f975daed229c0c61f283d320357    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 25 Jan 2012 09:35:17 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 25 Jan 2012 09:35:17 -0500    

Backpatch to 9.1.  

commit   : fa4dad6cc0fe7b66b2627ce7124a7767bfbaba63    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 24 Jan 2012 22:42:37 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 24 Jan 2012 22:42:37 -0500    

Per report from Peter.  

commit   : e9cdb00ccdf3c4ef8706e801617bd4ed21907f5d    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 23 Jan 2012 21:08:46 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 23 Jan 2012 21:08:46 -0500    

commit   : 02f377dbe50074a7016f4a476a8d15d294cd0874    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 18 Jan 2012 17:09:44 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 18 Jan 2012 17:09:44 +0200    

When the only remaining active transactions are READ ONLY, we do a "partial  
cleanup" of committed transactions because certain types of conflicts  
aren't possible anymore. For committed r/w transactions, we release the  
SIREAD locks but keep the SERIALIZABLEXACT. However, for committed r/o  
transactions, we can go further and release the SERIALIZABLEXACT too. The  
problem was with the latter case: we were returning the SERIALIZABLEXACT to  
the free list without removing it from the finished list.  
  
The only real change in the patch is the SHMQueueDelete line, but I also  
reworked some of the surrounding code to make it obvious that r/o and r/w  
transactions are handled differently -- the existing code felt a bit too  
clever.  
  
Dan Ports  

commit   : ef007e67022bf7f2367aa10fd226d6fb86b6fb9c    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 15 Jan 2012 16:20:39 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 15 Jan 2012 16:20:39 -0500    

Along the way, add a missing dependency in the GNUmakefile.  
  
Alex Hunsaker, with a slight adjustment by me.  

commit   : b994c57a8032f55f816768ee55a677e03190abae    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 12 Jan 2012 16:40:19 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 12 Jan 2012 16:40:19 -0500    

In commit 7b0d0e9356963d5c3e4d329a917f5fbb82a2ef05, I made CLUSTER and  
VACUUM FULL try to preserve toast value OIDs from the original toast table  
to the new one.  However, if we have to copy both live and recently-dead  
versions of a row that has a toasted column, those versions may well  
reference the same toast value with the same OID.  The patch then led to  
duplicate-key failures as we tried to insert the toast value twice with the  
same OID.  (The previous behavior was not very desirable either, since it  
would have silently inserted the same value twice with different OIDs.  
That wastes space, but what's worse is that the toast values inserted for  
already-dead heap rows would not be reclaimed by subsequent ordinary  
VACUUMs, since they go into the new toast table marked live not deleted.)  
  
To fix, check if the copied OID already exists in the new toast table, and  
if so, assume that it stores the desired value.  This is reasonably safe  
since the only case where we will copy an OID from a previous toast pointer  
is when toast_insert_or_update was given that toast pointer and so we just  
pulled the data from the old table; if we got two different values that way  
then we have big problems anyway.  We do have to assume that no other  
backend is inserting items into the new toast table concurrently, but  
that's surely safe for CLUSTER and VACUUM FULL.  
  
Per bug #6393 from Maxim Boguk.  Back-patch to 9.0, same as the previous  
patch.  

commit   : d427e75e51d9e7d76fc2a4bc142ba7be852a1078    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 Jan 2012 19:56:27 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 Jan 2012 19:56:27 -0500    

The original coding examined the next character before verifying that  
there *is* a next character.  In the worst case with the input buffer  
right up against the end of memory, this would result in a segfault.  
  
Problem spotted by Paul Guyot; this commit extends his patch to fix an  
additional case.  In addition, make the code a tad more readable by not  
overloading the usage of *tlen.  

commit   : 068e08eebbb2204f525647daad3fe15063b77820    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 7 Jan 2012 15:38:59 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 7 Jan 2012 15:38:59 -0500    

Historically we've used the SWPB instruction for TAS() on ARM, but this  
is deprecated and not available on ARMv6 and later.  Instead, make use  
of a GCC builtin if available.  We'll still fall back to SWPB if not,  
so as not to break existing ports using older GCC versions.  
  
Eventually we might want to try using __sync_lock_test_and_set() on some  
other architectures too, but for now that seems to present only risk and  
not reward.  
  
Back-patch to all supported versions, since people might want to use any  
of them on more recent ARM chips.  
  
Martin Pitt  

commit   : f517ece06379125a554472c94eb55f7fc82ff658    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 Jan 2012 13:31:41 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 Jan 2012 13:31:41 -0500    

Spotted by Koizumi Satoru.  

commit   : 522650a6e4516763bcc902c18ac371f50809abb3    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 Jan 2012 13:04:15 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 Jan 2012 13:04:15 -0500    

In commit 6545a901aaf84cb05212bb6a7674059908f527c3, I removed the mini SQL  
lexer that was in pg_backup_db.c, thinking that it had no real purpose  
beyond separating COPY data from SQL commands, which purpose had been  
obsoleted by long-ago fixes in pg_dump's archive file format.  
Unfortunately this was in error: that code was also used to identify  
command boundaries in INSERT-style table data, which is run together as a  
single string in the archive file for better compressibility.  As a result,  
direct-to-database restores from archive files made with --inserts or  
--column-inserts fail in our latest releases, as reported by Dick Visser.  
  
To fix, restore the mini SQL lexer, but simplify it by adjusting the  
calling logic so that it's only required to cope with INSERT-style table  
data, not arbitrary SQL commands.  This allows us to not have to deal with  
SQL comments, E'' strings, or dollar-quoted strings, none of which have  
ever been emitted by dumpTableData_insert.  
  
Also, fix the lexer to cope with standard-conforming strings, which was the  
actual bug that the previous patch was meant to solve.  
  
Back-patch to all supported branches.  The previous patch went back to 8.2,  
which unfortunately means that the EOL release of 8.2 contains this bug,  
but I don't think we're doing another 8.2 release just because of that.  

commit   : f9f04845045086feb1144f52cc2911e9f08efe3f    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 6 Jan 2012 08:32:32 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 6 Jan 2012 08:32:32 -0500    

As noted by Heikki Linnakangas, the previous coding confused the "flags"  
variable with the "mask" variable.  The affect of this appears to be that  
unlogged buffers would get written out at every checkpoint rather than  
only at shutdown time.  Although that's arguably an acceptable failure  
mode, I'm back-patching this change, since it seems like a poor idea to  
rely on this happening to work.  

commit   : d1d836f92c0798f4bc4138dc6b87279199c4f49a    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 5 Jan 2012 18:01:52 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 5 Jan 2012 18:01:52 -0500    

Apparently the perl garbage collector was a bit too eager, so here  
we control when the new SV is garbage collected.  

commit   : d496384d6771c276a0253758418e7933b6f31167    
  
author   : Andrew Dunstan <[email protected]>    
date     : Thu, 5 Jan 2012 12:03:44 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Thu, 5 Jan 2012 12:03:44 -0500    

Certain things like typeglobs or readonly things like $^V cause  
perl's SvPVutf8() to die nastily and crash the backend. To avoid  
that bug we make a copy of the object, which will subsequently be  
garbage collected.  
  
Back patched to 9.1 where we first started using SvPVutf8().  
  
Per -hackers discussion. Original problem reported by David Wheeler.  

commit   : 658ee0108637683216fb093b9f2c7e23bfd150c5    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 4 Jan 2012 18:31:01 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 4 Jan 2012 18:31:01 -0500    

As previously coded, the QueryDesc's dest pointer was left dangling  
(pointing at an already-freed receiver object) after ExecutorEnd.  It's a  
bit astonishing that it took us this long to notice, and I'm not sure that  
the known problem case with SQL functions is the only one.  Fix it by  
saving and restoring the original receiver pointer, which seems the most  
bulletproof way of ensuring any related bugs are also covered.  
  
Per bug #6379 from Paul Ramsey.  Back-patch to 8.4 where the current  
handling of SELECT INTO was introduced.  

commit   : 188f1b928205bf33ce29887eeeee26ce9227908f    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Jan 2012 14:43:51 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 Jan 2012 14:43:51 -0500    

Because coerce_type recurses into the argument of a CollateExpr,  
coerce_to_target_type's longstanding code for detecting whether coerce_type  
had actually done anything (to wit, returned a different node than it  
passed in) was broken in 9.1.  This resulted in unexpected failures in  
hide_coercion_node; which was not the latter's fault, since it's critical  
that we never call it on anything that wasn't inserted by coerce_type.  
(Else we might decide to "hide" a user-written function call.)  
  
Fix by removing and replacing the CollateExpr in coerce_to_target_type  
itself.  This is all pretty ugly but I don't immediately see a way to make  
it nicer.  
  
Per report from Jean-Yves F. Barbier.  

commit   : 71b23708d4433d731082ed9c5ca491c7595e0e4d    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 21 Dec 2011 18:23:18 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 21 Dec 2011 18:23:18 -0500    

We forgot to modify column ACLs, so privileges were still shown as having  
been granted by the old owner.  This meant that neither the new owner nor  
a superuser could revoke the now-untraceable-to-table-owner permissions.  
Per bug #6350 from Marc Balmer.  
  
This has been wrong since column ACLs were added, so back-patch to 8.4.  

commit   : 5d7d12de56be2c746bfc30214d3300644e8dc0f3    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 20 Dec 2011 19:57:40 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 20 Dec 2011 19:57:40 -0500    

The original coding of this function overlooked the possibility that  
it could be passed anything except simple OpExpr indexquals.  But  
ScalarArrayOpExpr is possible too, and the code would probably crash  
(and surely give ridiculous answers) in such a case.  Add logic to try  
to estimate sanely for such cases.  
  
In passing, fix the treatment of inner-indexscan cost estimation: it was  
failing to scale up properly for multiple iterations of a nestloop.  
(I think somebody might've thought that index_pages_fetched() is linear,  
but of course it's not.)  
  
Report, diagnosis, and preliminary patch by Marti Raudsepp; I refactored  
it a bit and fixed the cost estimation.  
  
Back-patch into 9.1 where the bogus code was introduced.  

commit   : a63a7a5b091f8b833169476e8de18100fb1cb73d    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 20 Dec 2011 15:00:41 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 20 Dec 2011 15:00:41 -0500    

smgrdounlink takes care to not throw an ERROR if it fails to unlink  
something, but that caution was rendered useless by commit  
3396000684b41e7e9467d1abc67152b39e697035, which put an smgrexists call in  
front of it; smgrexists *does* throw error if anything looks funny, such  
as getting a permissions error from trying to open the file.  If that  
happens post-commit, you get a PANIC, and what's worse the same logic  
appears in the WAL replay code, so the database even fails to restart.  
  
Restore the intended behavior by removing the smgrexists call --- it isn't  
accomplishing anything that we can't do better by adjusting mdunlink's  
ideas of whether it ought to warn about ENOENT or not.  
  
Per report from Joseph Shraibman of unrecoverable crash after trying to  
drop a table whose FSM fork had somehow gotten chmod'd to 000 permissions.  
Backpatch to 8.4, where the bogus coding was introduced.  

commit   : bb4cfebd64cb43b9002e6a748dd8d2a2eed8204b    
  
author   : Michael Meskes <[email protected]>    
date     : Sun, 18 Dec 2011 15:34:33 +0100    
  
committer: Michael Meskes <[email protected]>    
date     : Sun, 18 Dec 2011 15:34:33 +0100    

Ever since we introduced real prepared statements this should work for  
different connections. The old solution just emulating prepared statements,  
though, wasn't able to handle this.  
  
Closes: #6309  

commit   : d0ea1db52a3497d63d400b599980ffb237303cd5    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 16 Dec 2011 15:03:36 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 16 Dec 2011 15:03:36 +0200    

commit   : 24b96804d588da262ae0d3958e14638de217445a    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 14 Dec 2011 17:14:21 -0500    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 14 Dec 2011 17:14:21 -0500    

Suggested solution from Tom Lane. Problem discovered, probably not  
for the first time, while testing the mingw-w64 32 bit compiler.  
  
Backpatched to all live branches.  

commit   : 6cf639dfbddbc44d027730ad1504886312bc905a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 12 Dec 2011 09:49:47 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 12 Dec 2011 09:49:47 +0200    

I forgot to change the functions to use the PG_GETARG_INET_PP() macro,  
when I changed DatumGetInetP() to unpack the datum, like Datum*P macros  
usually do. Also, I screwed up the definition of the PG_GETARG_INET_PP()  
macro, and didn't notice because it wasn't used.  
  
This fixes the memory leak when sorting inet values, as reported  
by Jochen Erwied and debugged by Andres Freund. Backpatch to 8.3, like  
the previous patch that broke it.  

commit   : e45057e0a7c4f5c6f1d662853c616eea26e9b0e4    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Fri, 9 Dec 2011 14:32:42 +0200    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Fri, 9 Dec 2011 14:32:42 +0200    

In master, that was an active bug because of the recent patch to  
immediately PANIC if a reference to a missing page is found in WAL after  
reaching consistency, as Tom Lane's test case demonstrated. In 9.1 and 9.0,  
the only consequence was a misleading "consistent recovery state reached at  
%X/%X" message in the log at the beginning of crash recovery (the database  
is not consistent at that point yet). In 8.4, the log message was not  
printed in crash recovery, even though there was a similar  
reachedMinRecoveryPoint local variable that was also set early. So,  
backpatch to 9.1 and 9.0.  

commit   : 85d85ff7ef04510f24fe5897e5535d765d7a293c    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 7 Dec 2011 13:34:19 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 7 Dec 2011 13:34:19 -0500    

Make sure all calls are protected by HAVE_READLINK, and get the buffer  
overflow tests right.  Be a bit more paranoid about string length in  
_tarWriteHeader(), too.  

commit   : 9c32da5caa2efc9bdc7f04ae26488211ff219e8a    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 7 Dec 2011 12:09:05 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 7 Dec 2011 12:09:05 +0100    

We don't have any such platforms now, but might in the future.  
  
Also, detect cases when a tablespace symlink points to a path that  
is longer than we can handle, and give a warning.  

commit   : 75594e0cf7674d78ba40699ff614a847fe675dc2    
  
author   : Magnus Hagander <[email protected]>    
date     : Tue, 6 Dec 2011 11:02:02 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Tue, 6 Dec 2011 11:02:02 +0100    

Euler Taveira de Oliveira  

commit   : 98fbce09316525e1da5a5c94ea8d75ead69669fb    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 5 Dec 2011 16:45:19 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 5 Dec 2011 16:45:19 -0500    

commit   : 7c9557b6f829fb26d96d2ebca6a396ff69d14520    
  
author   : Michael Meskes <[email protected]>    
date     : Sat, 3 Dec 2011 21:03:57 +0100    
  
committer: Michael Meskes <[email protected]>    
date     : Sat, 3 Dec 2011 21:03:57 +0100    

commit   : a6f8e7d9590d157e379efe4a4edfc32ab283ec42    
  
author   : Magnus Hagander <[email protected]>    
date     : Sat, 3 Dec 2011 15:02:53 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Sat, 3 Dec 2011 15:02:53 +0100    

This makes it possible to use a libpq app with home directory set  
to /dev/null, for example - treating it the same as if the file  
doesn't exist (which it doesn't).  
  
Per bug #6302, reported by Diego Elio Petteno  

commit   : 1cd1a7c1024503259b3968db6b9e8a888ca97f63    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 2 Dec 2011 11:33:53 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 2 Dec 2011 11:33:53 -0500    

PGresults used to be read-only from the application's viewpoint, but now  
that we've exposed various functions that allow modification of a PGresult,  
that sweeping statement is no longer accurate.  Noted by Dmitriy Igrishin.