PostgreSQL 9.1.10 commit log

commit   : b444726ef6642ed2289a1dc10fe53644dba05623    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Oct 2013 23:13:47 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Oct 2013 23:13:47 -0400    

commit   : 4a72c60e4a4ab3b60c809079924d019367428315    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Oct 2013 22:41:53 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Oct 2013 22:41:53 -0400    

This reverts commit 6ed3c5f7b2846be9e176ea1c99b2d45bba0d6972.  

commit   : 791a71a679970c801f526c6b2bb5ef51d6c21ec5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Oct 2013 22:39:30 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Oct 2013 22:39:30 -0400    

This reverts commit 176c70b9f2ce382a5590e42afd7ba4edb87efecb.  
  
pending resolution of  
http://www.postgresql.org/message-id/1381193255.25702.4.camel@vanquo.pezone.net  

commit   : 56e90da8da137c5a91c4086970b721c5ef7d6871    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 7 Oct 2013 21:35:01 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 7 Oct 2013 21:35:01 -0400    

commit   : d81855129ba6115fe27cf204ca2912f9369bfa47    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 8 Oct 2013 03:49:08 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 8 Oct 2013 03:49:08 +0300    

I forgot to "git add" latest changes after backpatching the changes  
for previous commit.  

commit   : 42c63cafb2af32795afa7dd5d3690186af313785    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 7 Oct 2013 23:57:40 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 7 Oct 2013 23:57:40 +0300    

1. In heap_hot_search_buffer(), the PredicateLockTuple() call is passed  
wrong offset number. heapTuple->t_self is set to the tid of the first  
tuple in the chain that's visited, not the one actually being read.  
  
2. CheckForSerializableConflictIn() uses the tuple's t_ctid field  
instead of t_self to check for exiting predicate locks on the tuple. If  
the tuple was updated, but the updater rolled back, t_ctid points to the  
aborted dead tuple.  
  
Reported by Hannu Krosing. Backpatch to 9.1.  

commit   : 1c4dfd19a6ebb3c2a0471f0a57b9f13d0ccd9d02    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Oct 2013 16:15:26 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 7 Oct 2013 16:15:26 -0400    

commit   : 556e6d0ba33388e8e230f11c88d3df25be79bb37    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Mon, 7 Oct 2013 14:05:26 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Mon, 7 Oct 2013 14:05:26 -0500    

If a tuple was frozen while its predicate locks mattered,  
read-write dependencies could be missed, resulting in failure to  
detect conflicts which could lead to anomalies in committed  
serializable transactions.  
  
This field was added to the tag when we still thought that it was  
necessary to carry locks forward to a new version of an updated  
row.  That was later proven to be unnecessary, which allowed  
simplification of the code, but elimination of xmin from the tag  
was missed at the time.  
  
Per report and analysis by Heikki Linnakangas.  
Backpatch to 9.1.  

commit   : 6ed3c5f7b2846be9e176ea1c99b2d45bba0d6972    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 6 Oct 2013 23:07:28 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 6 Oct 2013 23:07:28 -0400    

Cédric Villemain and me.  

commit   : d648af0df403a32ff7e5cb1af638d239b4bd0bdd    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 2 Oct 2013 21:33:26 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 2 Oct 2013 21:33:26 -0400    

commit   : c768cf616de9c32e154004e34dba20477112f996    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 2 Oct 2013 21:25:39 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 2 Oct 2013 21:25:39 -0400    

commit   : 176c70b9f2ce382a5590e42afd7ba4edb87efecb    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 30 Sep 2013 10:45:40 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 30 Sep 2013 10:45:40 -0400    

This time with the better installation fix, which I hope won't break the  
buildfarm.  

commit   : cd6c03b5c15e2b8bf306d97ed9befaf83ace5f93    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 30 Sep 2013 11:29:09 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 30 Sep 2013 11:29:09 +0300    

lo_open registers the currently active snapshot, and checks if the  
large object exists after that. Normally, snapshots registered by lo_open  
are unregistered at end of transaction when the lo descriptor is closed, but  
if we error out before the lo descriptor is added to the list of open  
descriptors, it is leaked. Fix by moving the snapshot registration to after  
checking if the large object exists.  
  
Reported by Pavel Stehule. Backpatch to 8.4. The snapshot registration  
system was introduced in 8.4, so prior versions are not affected (and not  
supported, anyway).  

commit   : 03b6a6b48e932c4123bee4f6b2a71944da5bd05c    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 30 Sep 2013 00:08:37 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 30 Sep 2013 00:08:37 -0400    

This reverts commit 15892461042f4e00322f4116236697dde022a2f8.  

commit   : 15892461042f4e00322f4116236697dde022a2f8    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 29 Sep 2013 17:33:02 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 29 Sep 2013 17:33:02 -0400    

This is a backpatch of commits d942f9d9, 82b01026, and 6697aa2bc, back  
to release 9.1 where we introduced extensions which make heavy use of  
the PGXS infrastructure.  

commit   : 096ad243351b09b059408d7d8f422df01b4f496b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 26 Sep 2013 11:24:40 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 26 Sep 2013 11:24:40 +0300    

There is a rare race condition, when a transaction that inserted a tuple  
aborts while vacuum is processing the page containing the inserted tuple.  
Vacuum prunes the page first, which normally removes any dead tuples, but  
if the inserting transaction aborts right after that, the loop after  
pruning will see a dead tuple and remove it instead. That's OK, but if the  
page is on a table with no indexes, and the page becomes completely empty  
after removing the dead tuple (or tuples) on it, it will be immediately  
marked as all-visible. That's OK, but the sanity check in vacuum would  
throw a warning because it thinks that the page contains dead tuples and  
was nevertheless marked as all-visible, even though it just vacuumed away  
the dead tuples and so it doesn't actually contain any.  
  
Spotted this while reading the code. It's difficult to hit the race  
condition otherwise, but can be done by putting a breakpoint after the  
heap_page_prune() call.  
  
Backpatch all the way to 8.4, where this code first appeared.  

commit   : 1e691588c19f9c763bfb9e80682ed08033f467a1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 24 Sep 2013 18:19:14 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 24 Sep 2013 18:19:14 -0300    

commit   : ea0a8f0d2266986171043e73e078464f6fa95535    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 23 Sep 2013 16:00:13 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 23 Sep 2013 16:00:13 -0400    

Though @libdir@ almost always matches @abs_builddir@ in this context,  
the test could only fail if they differed.  Back-patch to 9.1, where the  
test was introduced.  
  
Hamid Quddus Akhtar  

commit   : 5eaa369e2e669e0928f2531329825cf4f4d5c884    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 23 Sep 2013 08:33:41 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 23 Sep 2013 08:33:41 -0400    

In libpq, we set up and pass to OpenSSL callback routines to handle  
locking.  When we run out of SSL connections, we try to clean things  
up by de-registering the hooks.  Unfortunately, we had a few calls  
into the OpenSSL library after these hooks were de-registered during  
SSL cleanup which lead to deadlocking.  This moves the thread callback  
cleanup to be after all SSL-cleanup related OpenSSL library calls.  
I've been unable to reproduce the deadlock with this fix.  
  
In passing, also move the close_SSL call to be after unlocking our  
ssl_config mutex when in a failure state.  While it looks pretty  
unlikely to be an issue, it could have resulted in deadlocks if we  
ended up in this code path due to something other than SSL_new  
failing.  Thanks to Heikki for pointing this out.  
  
Back-patch to all supported versions; note that the close_SSL issue  
only goes back to 9.0, so that hunk isn't included in the 8.4 patch.  
  
Initially found and reported by Vesa-Matti J Kari; many thanks to  
both Heikki and Andres for their help running down the specific  
issue and reviewing the patch.  

commit   : f0d76a515e88a2709e23693c2f9cfb979063dfe2    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 11 Sep 2013 20:10:15 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 11 Sep 2013 20:10:15 -0400    

Once the administrator has called for an immediate shutdown or a backend  
crash has triggered a reinitialization, no mere SIGINT or SIGTERM should  
change that course.  Such derailment remains possible when the signal  
arrives before quickdie() blocks signals.  That being a narrow race  
affecting most PostgreSQL signal handlers in some way, leave it for  
another patch.  Back-patch this to all supported versions.  

commit   : 994362a317ced987b6ea616b236c402d715ddcd5    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Sun, 8 Sep 2013 12:59:43 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Sun, 8 Sep 2013 12:59:43 +0200    

Found by Coverity.  

commit   : aef9d25aa3dc90bf303897ffc445c92420df4a6d    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Sun, 8 Sep 2013 12:49:54 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Sun, 8 Sep 2013 12:49:54 +0200    

commit   : 8e67a28eea9b7d068bdbe8fc9978f7fb2edda54b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Sep 2013 18:32:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Sep 2013 18:32:29 -0400    

The previous coding attempted to activate all the GUC settings specified  
in SET clauses, so that the function validator could operate in the GUC  
environment expected by the function body.  However, this is problematic  
when restoring a dump, since the SET clauses might refer to database  
objects that don't exist yet.  We already have the parameter  
check_function_bodies that's meant to prevent forward references in  
function definitions from breaking dumps, so let's change CREATE FUNCTION  
to not install the SET values if check_function_bodies is off.  
  
Authors of function validators were already advised not to make any  
"context sensitive" checks when check_function_bodies is off, if indeed  
they're checking anything at all in that mode.  But extend the  
documentation to point out the GUC issue in particular.  
  
(Note that we still check the SET clauses to some extent; the behavior  
with !check_function_bodies is now approximately equivalent to what ALTER  
DATABASE/ROLE have been doing for awhile with context-dependent GUCs.)  
  
This problem can be demonstrated in all active branches, so back-patch  
all the way.  

commit   : f8730733e048159702a74b82b1106e0646bfaac5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Sep 2013 15:06:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Sep 2013 15:06:21 -0400    

DST law changes in Israel, Morocco, Palestine, Paraguay.  
Historical corrections for Macquarie Island.  

commit   : c558e1e64db77634893ca062d1e8b8f841d54f56    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 2 Sep 2013 14:36:08 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 2 Sep 2013 14:36:08 -0400    

The original query ignored TOAST tables which could result in tables  
needing a vacuum not being reported.  
  
Backpatch to all live branches.  

commit   : b8288038baed0fd71f5c19a6a41f12265a719aea    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 26 Aug 2013 14:55:00 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 26 Aug 2013 14:55:00 -0400    

This change will only apply to mingw compilers, and has been found  
necessary by late versions of the mingw-w64 compiler. It's the same as  
what is done elsewhere for the Microsoft compilers.  
  
Backpatch of commit 73838b5251e.  
  
Problem reported by Michael Cronenworth, although not his patch.  

commit   : f7bbd46dcfb057459f467da1b0385ae6c13e5977    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Aug 2013 17:31:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 23 Aug 2013 17:31:03 -0400    

It's possible that inlining of SQL functions (or perhaps other changes?)  
has exposed typmod information not known at parse time.  In such cases,  
Vars generated by query_planner might have valid typmod values while the  
original grouping columns only have typmod -1.  This isn't a semantic  
problem since the behavior of grouping only depends on type not typmod,  
but it breaks locate_grouping_columns' use of tlist_member to locate the  
matching entry in query_planner's result tlist.  
  
We can fix this without an excessive amount of new code or complexity by  
relying on the fact that locate_grouping_columns only gets called when  
make_subplanTargetList has set need_tlist_eval == false, and that can only  
happen if all the grouping columns are simple Vars.  Therefore we only need  
to search the sub_tlist for a matching Var, and we can reasonably define a  
"match" as being a match of the Var identity fields  
varno/varattno/varlevelsup.  The code still Asserts that vartype matches,  
but ignores vartypmod.  
  
Per bug #8393 from Evan Martin.  The added regression test case is  
basically the same as his example.  This has been broken for a very long  
time, so back-patch to all supported branches.  

commit   : 649839dd9f1c08b7aadb654587edd9f86a3caa3f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Aug 2013 18:31:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Aug 2013 18:31:48 -0400    

With this optimization flag enabled, recent versions of gcc can generate  
incorrect code that assumes variable-length arrays (such as oidvector)  
are actually fixed-length because they're embedded in some larger struct.  
The known instance of this problem was fixed in 9.2 and up by commit  
8137f2c32322c624e0431fac1621e8e9315202f9 and followon work, which hides  
actually-variable-length catalog fields from the compiler altogether.  
And we plan to gradually convert variable-length fields to official  
"flexible array member" notation over time, which should prevent this type  
of bug from reappearing as gcc gets smarter.  We're not going to try to  
back-port those changes into older branches, though, so apply this  
band-aid instead.  
  
Andres Freund  

commit   : a2e66c03a4cc3d300e743930ffcc903ee786ffd5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 17 Aug 2013 21:46:32 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 17 Aug 2013 21:46:32 -0400    

commit   : 6084c0705ae03fa7641369e33a2c487585b8f942    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Aug 2013 12:39:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 3 Aug 2013 12:39:57 -0400    

The C99 and POSIX standards require strtod() to accept all these spellings  
(case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity",  
"-infinity".  However, pre-C99 systems might accept only some or none of  
these, and apparently Windows still doesn't accept "inf".  To avoid  
surprising cross-platform behavioral differences, manually check for each  
of these spellings if strtod() fails.  We were previously handling just  
"infinity" and "-infinity" that way, but since C99 is most of the world  
now, it seems likely that applications are expecting all these spellings  
to work.  
  
Per bug #8355 from Basil Peace.  It turns out this fix won't actually  
resolve his problem, because Python isn't being this careful; but that  
doesn't mean we shouldn't be.  

commit   : c928dc9dfbbfa374f8614726428743d4445bc1d7    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 2 Aug 2013 14:34:56 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 2 Aug 2013 14:34:56 -0400    

If a tuple is locked but not updated by a concurrent transaction,  
HeapTupleSatisfiesDirty would return that transaction's Xid in xmax,  
causing callers to wait on it, when it is not necessary (in fact, if the  
other transaction had used a multixact instead of a plain Xid to mark  
the tuple, HeapTupleSatisfiesDirty would have behave differently and  
*not* returned the Xmax).  
  
This bug was introduced in commit 3f7fbf85dc5b42, dated December 1998,  
so it's almost 15 years old now.  However, it's hard to see this  
misbehave, because before we had NOWAIT the only consequence of this is  
that transactions would wait for slightly more time than necessary; so  
it's not surprising that this hasn't been reported yet.  
  
Craig Ringer and Andres Freund  

commit   : 71127756af12ed64da9e82639f88b6ed13e5f600    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Thu, 1 Aug 2013 15:42:07 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Thu, 1 Aug 2013 15:42:07 -0400    

We should really be reporting a useful error along with returning  
a valid return code if pthread_mutex_lock() throws an error for  
some reason.  Add that and back-patch to 9.0 as the prior patch.  
  
Pointed out by Alvaro Herrera  

commit   : 0b821b8d7c137fbec215f8da286b4a40e53b13d5    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Thu, 1 Aug 2013 01:15:45 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Thu, 1 Aug 2013 01:15:45 -0400    

I've been working with Nick Phillips on an issue he ran into when  
trying to use threads with SSL client certificates.  As it turns out,  
the call in initialize_SSL() to SSL_CTX_use_certificate_chain_file()  
will modify our SSL_context without any protection from other threads  
also calling that function or being at some other point and trying to  
read from SSL_context.  
  
To protect against this, I've written up the attached (based on an  
initial patch from Nick and much subsequent discussion) which puts  
locks around SSL_CTX_use_certificate_chain_file() and all of the other  
users of SSL_context which weren't already protected.  
  
Nick Phillips, much reworked by Stephen Frost  
  
Back-patch to 9.0 where we started loading the cert directly instead of  
using a callback.  

commit   : 1346f40b584d8072bdacdf312027c0ef57e4b7c2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Jul 2013 11:31:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Jul 2013 11:31:33 -0400    

We'd find the same match twice if it was of zero length and not immediately  
adjacent to the previous match.  replace_text_regexp() got similar cases  
right, so adjust this search logic to match that.  Note that even though  
the regexp_split_to_xxx() functions share this code, they did not display  
equivalent misbehavior, because the second match would be considered  
degenerate and ignored.  
  
Jeevan Chalke, with some cosmetic changes by me.  

commit   : ed33ad39a2f353acc3d38591a749f324de3b6c23    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 30 Jul 2013 18:36:52 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 30 Jul 2013 18:36:52 -0400    

Refactoring as part of commit 8ceb24568054232696dddc1166a8563bc78c900a  
had the unintended effect of making REINDEX TABLE and REINDEX DATABASE  
no longer validate constraints enforced by the indexes in question;  
REINDEX INDEX still did so.  Indexes marked invalid remained so, and  
constraint violations arising from data corruption went undetected.  
Back-patch to 9.0, like the causative commit.  

commit   : aa4982169d42660a848e4d25f52bdabcf3f12860    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jul 2013 10:42:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jul 2013 10:42:47 -0400    

These modules used the YYPARSE_PARAM macro, which has been deprecated  
by the bison folk since 1.875, and which they finally removed in 3.0.  
Adjust the code to use the replacement facility, %parse-param, which  
is a much better solution anyway since it allows specification of the  
type of the extra parser parameter.  We can thus get rid of a lot of  
unsightly casting.  
  
Back-patch to all active branches, since somebody might try to build  
a back branch with up-to-date tools.  

commit   : 3ba763bd95b6eb027bc87e73806241b460807091    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2013 11:39:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2013 11:39:18 -0400    

The configure script's test for <sys/ucred.h> did not work on OpenBSD,  
because on that platform <sys/param.h> has to be included first.  
As a result, socket peer authentication was disabled on that platform.  
Problem introduced in commit be4585b1c27ac5dbdd0d61740d18f7ad9a00e268.  
  
Andres Freund, slightly simplified by me.  

commit   : 13f11c8a8cd0f696fc5f4aead96344e4a6173448    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Jul 2013 00:44:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Jul 2013 00:44:09 -0400    

In a boolean column that contains mostly nulls, ANALYZE might not find  
enough non-null values to populate the most-common-values stats,  
but it would still create a pg_statistic entry with stanullfrac set.  
The logic in booltestsel() for this situation did the wrong thing for  
"col IS NOT TRUE" and "col IS NOT FALSE" tests, forgetting that null  
values would satisfy these tests (so that the true selectivity would  
be close to one, not close to zero).  Per bug #8274.  
  
Fix by Andrew Gierth, some comment-smithing by me.  

commit   : 15fdf7302a99b0f63394bc49c2528b4731a6627e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 23 Jul 2013 17:38:31 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 23 Jul 2013 17:38:31 -0400    

Per Coverity Scan  

commit   : c1f51ed2960ac2678535c252072695a4a8325a92    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Jul 2013 16:23:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Jul 2013 16:23:11 -0400    

It's possible to drop a column from an input table of a JOIN clause in a  
view, if that column is nowhere actually referenced in the view.  But it  
will still be there in the JOIN clause's joinaliasvars list.  We used to  
replace such entries with NULL Const nodes, which is handy for generation  
of RowExpr expansion of a whole-row reference to the view.  The trouble  
with that is that it can't be distinguished from the situation after  
subquery pull-up of a constant subquery output expression below the JOIN.  
Instead, replace such joinaliasvars with null pointers (empty expression  
trees), which can't be confused with pulled-up expressions.  expandRTE()  
still emits the old convention, though, for convenience of RowExpr  
generation and to reduce the risk of breaking extension code.  
  
In HEAD and 9.3, this patch also fixes a problem with some new code in  
ruleutils.c that was failing to cope with implicitly-casted joinaliasvars  
entries, as per recent report from Feike Steenbergen.  That oversight was  
because of an inadequate description of the data structure in parsenodes.h,  
which I've now corrected.  There were some pre-existing oversights of the  
same ilk elsewhere, which I believe are now all fixed.  

commit   : e23adeff0c288ff10a368b94cfb78ee291999113    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Jul 2013 10:23:12 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 19 Jul 2013 10:23:12 -0400    

David Christensen  

commit   : 4652abeb30b28dcb38621ea31f24936cdbdc83f8    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Fri, 19 Jul 2013 08:59:20 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Fri, 19 Jul 2013 08:59:20 +0200    

There are cases where the day of year value in struct tm is used, but it never  
got calculated. Problem found by Coverity scan.  

commit   : f4ceb7aa56e356da30a8de376a66f0fbcdbf938a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Jul 2013 21:22:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Jul 2013 21:22:53 -0400    

An ancient logic error in cfindloop() could cause the regex engine to fail  
to find matches that begin later than the start of the string.  This  
function is only used when the regex pattern contains a back reference,  
and so far as we can tell the error is only reachable if the pattern is  
non-greedy (i.e. its first quantifier uses the ? modifier).  Furthermore,  
the actual match must begin after some potential match that satisfies the  
DFA but then fails the back-reference's match test.  
  
Reported and fixed by Jeevan Chalke, with cosmetic adjustments by me.  

commit   : 2f397a08de49e28e3430ff7278f4648757dea2a3    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 15 Jul 2013 11:27:20 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 15 Jul 2013 11:27:20 -0400    

When using libpq, it's generally preferrable to just use the strings  
which are in the PQ structures instead of copying them out, so do  
that instead in BaseBackup(), eliminating the strcpy()'s used there.  
  
Also, in ReceiveAndUnpackTarFile(), check the string length for the  
directory returned by the server for the tablespace path.  

commit   : 3cb7a393e8e93b1e67bb1e0d361dd1eb7d928ae7    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sun, 14 Jul 2013 16:43:47 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sun, 14 Jul 2013 16:43:47 -0400    

In tuplesort.c:inittapes(), we calculate tapeSpace by first figuring  
out how many 'tapes' we can use (maxTapes) and then multiplying the  
result by the tape buffer overhead for each.  Unfortunately, when  
we are on a system with an 8-byte long, we allow work_mem to be  
larger than 2GB and that allows maxTapes to be large enough that the  
32bit arithmetic can overflow when multiplied against the buffer  
overhead.  
  
When this overflow happens, we end up adding the overflow to the  
amount of space available, causing the amount of memory allocated to  
be larger than work_mem.  
  
Note that to reach this point, you have to set work mem to at least  
24GB and be sorting a set which is at least that size.  Given that a  
user who can set work_mem to 24GB could also set it even higher, if  
they were looking to run the system out of memory, this isn't  
considered a security issue.  
  
This overflow risk was found by the Coverity scanner.  
  
Back-patch to all supported branches, as this issue has existed  
since before 8.4.  

commit   : 703bc145f773835637a8a01f2fe4cfb864835bb1    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Thu, 27 Jun 2013 16:00:32 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Thu, 27 Jun 2013 16:00:32 +0200    

Thanks to MauMau <maumau307@gmail.com> for finding and fixing this.  

commit   : ad4c625ee464b409f341d4680127e816391fe94f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jul 2013 09:43:15 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Jul 2013 09:43:15 -0400    

commit   : 271f7b0f8ab8f584fafc7703f1a9ac14d81ca21d    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 7 Jul 2013 13:36:20 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 7 Jul 2013 13:36:20 +0200    

Looks like a cut/paste error in the original addition of the file.  
  
Andres Freund  

commit   : 6dc4e62d0457b42969732aae0651a4bf25565ad5    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Sat, 6 Jul 2013 22:08:53 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Sat, 6 Jul 2013 22:08:53 +0200    

commit   : 456d37a0bfaf22ecd5c7e86778595278b32f43f8    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 5 Jul 2013 16:22:45 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 5 Jul 2013 16:22:45 +0200    

Erikjan Rijkers  

commit   : 2bb2a29c714293ba520d4332533ee62b7d774b28    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Fri, 5 Jul 2013 11:07:16 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Fri, 5 Jul 2013 11:07:16 +0200    

commit   : 8455b70fee2ddaabb5f76ed3aef11c97cbd10507    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 2 Jul 2013 12:21:16 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 2 Jul 2013 12:21:16 -0400    

Make it easier for readers of the FP docs to find out about possibly  
truncated values.  
  
Per complaint from Tom Duffey in message  
F0E0F874-C86F-48D1-AA2A-0C5365BF5118@trillitech.com  
  
Author: Albe Laurenz  
Reviewed by: Abhijit Menon-Sen  

commit   : 50e66d37aceee0f38c44f41834f39cfdda34c796    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jun 2013 13:55:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jun 2013 13:55:04 -0400    

When there's a comment on an index that was created with UNIQUE or PRIMARY  
KEY constraint syntax, we need to label the comment as depending on the  
constraint not the index, since only the constraint object actually appears  
in the dump.  This incorrect dependency can lead to parallel pg_restore  
trying to restore the comment before the index has been created, per bug  
#8257 from Lloyd Albin.  
  
This patch fixes pg_dump to produce the right dependency in dumps made  
in the future.  Usually we also try to hack pg_restore to work around  
bogus dependencies, so that existing (wrong) dumps can still be restored in  
parallel mode; but that doesn't seem practical here since there's no easy  
way to relate the constraint dump entry to the comment after the fact.  
  
Andres Freund  

commit   : c204aba26ce0c7efeaac193d274742423074bbd3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jun 2013 12:36:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jun 2013 12:36:44 -0400    

On Unix-ish platforms, EWOULDBLOCK may be the same as EAGAIN, which is  
*not* a success return, at least not on Linux.  We need to treat it as a  
failure to avoid giving a misleading error message.  Per the Single Unix  
Spec, only EINPROGRESS and EINTR returns indicate that the connection  
attempt is in progress.  
  
On Windows, on the other hand, EWOULDBLOCK (WSAEWOULDBLOCK) is the expected  
case.  We must accept EINPROGRESS as well because Cygwin will return that,  
and it doesn't seem worth distinguishing Cygwin from native Windows here.  
It's not very clear whether EINTR can occur on Windows, but let's leave  
that part of the logic alone in the absence of concrete trouble reports.  
  
Also, remove the test for errno == 0, effectively reverting commit  
da9501bddb42222dc33c031b1db6ce2133bcee7b, which AFAICS was just a thinko;  
or at best it might have been a workaround for a platform-specific bug,  
which we can hope is gone now thirteen years later.  In any case, since  
libpq makes no effort to reset errno to zero before calling connect(),  
it seems unlikely that that test has ever reliably done anything useful.  
  
Andres Freund and Tom Lane  

commit   : 0ae7d63b5c219f8e7f89b8f0f8df18843fed556f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jun 2013 00:27:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Jun 2013 00:27:26 -0400    

Adjust the wording in the first para of "Sequence Manipulation Functions"  
so that neither of the link phrases in it break across line boundaries,  
in either A4- or US-page-size PDF output.  This fixes a reported build  
failure for the 9.3beta2 A4 PDF docs, and future-proofs this particular  
para against causing similar problems in future.  (Perhaps somebody will  
fix this issue in the SGML/TeX documentation tool chain someday, but I'm  
not holding my breath.)  
  
Back-patch to all supported branches, since the same problem could rise up  
to bite us in future updates if anyone changes anything earlier than this  
in func.sgml.  

commit   : 8356d9498860cd377eb1edd8b64a840b6b411081    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 26 Jun 2013 19:51:56 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 26 Jun 2013 19:51:56 -0400    

Back-patch to all supported versions.  
  
Laurenz Albe  

commit   : 1c6afc40f7f9e3fd823e415adbfa6b2ac6f9864d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 25 Jun 2013 13:44:34 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 25 Jun 2013 13:44:34 -0400    

In binary upgrade mode, we need to recreate and then drop dropped  
columns so that all the columns get the right attribute number. This is  
true for foreign tables as well as for native tables. For foreign  
tables we have been getting the first part right but not the second,  
leading to bogus columns in the upgraded database. Fix this all the way  
back to 9.1, where foreign tables were introduced.  

commit   : 3f145f6be3d307af1ac7ceb808b6cf0486bc0c9e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 26 Jun 2013 02:20:11 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 26 Jun 2013 02:20:11 +0900    

In replication, when we shutdown the master, walsender tries to send  
all the outstanding WAL records to the standby, and then to exit. This  
basically means that all the WAL records are fully synced between  
two servers after the clean shutdown of the master. So, after  
promoting the standby to new master, we can restart the stopped  
master as new standby without the need for a fresh backup from  
new master.  
  
But there was one problem so far: though walsender tries to send all  
the outstanding WAL records, it doesn't wait for them to be replicated  
to the standby. Then, before receiving all the WAL records,  
walreceiver can detect the closure of connection and exit. We cannot  
guarantee that there is no missing WAL in the standby after clean  
shutdown of the master. In this case, backup from new master is  
required when restarting the stopped master as new standby.  
  
This patch fixes this problem. It just changes walsender so that it  
waits for all the outstanding WAL records to be replicated to the  
standby before closing the replication connection.  
  
Per discussion, this is a fix that needs to get backpatched rather than  
new feature. So, back-patch to 9.1 where enough infrastructure for  
this exists.  
  
Patch by me, reviewed by Andres Freund.  

commit   : a41c88194b19655d7f2cb556d0fdada227dea941    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Sun, 23 Jun 2013 11:05:02 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Sun, 23 Jun 2013 11:05:02 +0100    

In some cases with higher numbers of subtransactions  
it was possible for us to incorrectly initialize  
subtrans leading to complaints of missing pages.  
  
Bug report by Sergey Konoplev  
Analysis and fix by Andres Freund  

commit   : 27e9e86f6d2268d53555bc9474154f5286c64073    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 19 Jun 2013 22:31:42 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 19 Jun 2013 22:31:42 -0400    

More languages than PL/pgSQL actually support parameter names.  

commit   : be039d4b29be88a7f8b57d6353c81bced54d1b83    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 18 Jun 2013 12:05:48 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 18 Jun 2013 12:05:48 +0100    

ALTER TABLE .. VALIDATE CONSTRAINT previously  
gave incorrect details about lock levels and  
therefore incomplete reasons to use the option.  
  
Initial bug report and fix from Marko Tiikkaja  
Reworded by me to include comments by Kevin Grittner  

commit   : 81bb2d23bdf8d0b102c5fb0abd0a5df6fd74aba9    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sun, 16 Jun 2013 05:15:44 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sun, 16 Jun 2013 05:15:44 +0900    

Back-patch to 9.1 where the directory archive was introduced.  

commit   : cf0f08e03b51c58e72d56d52a9c07ffbe808a3f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Jun 2013 13:11:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Jun 2013 13:11:40 -0400    

In most scenarios a portal without a ResourceOwner is dead and not subject  
to any further execution, but a portal for a cursor WITH HOLD remains in  
existence with no ResourceOwner after the creating transaction is over.  
In this situation, if we attempt to "execute" the portal directly to fetch  
data from it, we were setting CurrentResourceOwner to NULL, leading to a  
segfault if the datatype output code did anything that required a resource  
owner (such as trying to fetch system catalog entries that weren't already  
cached).  The case appears to be impossible to provoke with stock libpq,  
but psqlODBC at least is able to cause it when working with held cursors.  
  
Simplest fix is to just skip the assignment to CurrentResourceOwner, so  
that any resources used by the data output operations will be managed by  
the transaction-level resource owner instead.  For consistency I changed  
all the places that install a portal's resowner as current, even though  
some of them are probably not reachable with a held cursor's portal.  
  
Per report from Joshua Berry (with thanks to Hiroshi Inoue for developing  
a self-contained test case).  Back-patch to all supported versions.  

commit   : e19c932edf199068895b4e3bc53218db59407f0b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 12 Jun 2013 12:20:59 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 12 Jun 2013 12:20:59 -0400    

Patch by me, reviewed by Tatsuo Ishii.  

commit   : e46753e9b935516b296bff8d46b9234bc46ee596    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Jun 2013 17:26:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Jun 2013 17:26:53 -0400    

We need to increment the refcount on the composite type's cached tuple  
descriptor while we do lookups of its column types.  Otherwise a cache  
flush could occur and release the tuple descriptor before we're done with  
it.  This fails reliably with -DCLOBBER_CACHE_ALWAYS, but the odds of a  
failure in a production build seem rather low (since the pfree'd descriptor  
typically wouldn't get scribbled on immediately).  That may explain the  
lack of any previous reports.  Buildfarm issue noted by Christian Ullrich.  
  
Back-patch to 9.1 where the bogus code was added.  

commit   : 219ef8e33ce09725a9ae1c345c63b98884a101d6    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Tue, 11 Jun 2013 14:25:58 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Tue, 11 Jun 2013 14:25:58 +0900    

commit   : 86742ac9c838cb383f951703f28938d371cb7858    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sun, 9 Jun 2013 17:31:51 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sun, 9 Jun 2013 17:31:51 -0700    

getSchemaData() must identify extension member objects and mark them  
as not to be dumped. This must happen after reading all objects that can be  
direct members of extensions, but before we begin to process table subsidiary  
objects. Both rules and event triggers were wrong in this regard.  
  
Backport rules portion of patch to 9.1 -- event triggers do not exist prior to 9.3.  
Suggested fix by Tom Lane, initial complaint and patch by me.  

commit   : a2c2336f9601c7c3b62c910eb5716d196cdd8496    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Jun 2013 18:39:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Jun 2013 18:39:34 -0400    

When the existing code here was written, it made sense to special-case  
RowExprs because that was the only way that we could handle row comparisons  
at all.  Now that we have record_eq() and arrays of composites, the generic  
logic for "scalar" types will in fact work on RowExprs too, so there's no  
reason to throw error for combinations of RowExprs and other ways of  
forming composite values, nor to ignore the possibility of using a  
ScalarArrayOpExpr.  But keep using the old logic when comparing two  
RowExprs, for consistency with the main transformAExprOp() logic.  (This  
allows some cases with not-quite-identical rowtypes to succeed, so we might  
get push-back if we removed it.)  Per bug #8198 from Rafal Rzepecki.  
  
Back-patch to all supported branches, since this works fine as far back as  
8.4.  
  
Rafal Rzepecki and Tom Lane  

commit   : aee8a60c7232cc048e00a704fca49730a722432a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Jun 2013 15:26:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Jun 2013 15:26:55 -0400    

Per discussion, this restriction isn't needed for any real security reason,  
and it seems to confuse people more often than it helps them.  It could  
also result in some database states being unrestorable.  So just drop it.  
  
Back-patch to 9.0, where ALTER DEFAULT PRIVILEGES was introduced.  

commit   : 8c3fdbb56e8ab404bbd4d919c2cc53ca4b031516    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Jun 2013 13:47:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 9 Jun 2013 13:47:06 -0400    

AllocateFile(), AllocateDir(), and some sister routines share a small array  
for remembering requests, so that the files can be closed on transaction  
failure.  Previously that array had a fixed size, MAX_ALLOCATED_DESCS (32).  
While historically that had seemed sufficient, Steve Toutant pointed out  
that this meant you couldn't scan more than 32 file_fdw foreign tables in  
one query, because file_fdw depends on the COPY code which uses  
AllocateFile().  There are probably other cases, or will be in the future,  
where this nonconfigurable limit impedes users.  
  
We can't completely remove any such limit, at least not without a lot of  
work, since each such request requires a kernel file descriptor and most  
platforms limit the number we can have.  (In principle we could  
"virtualize" these descriptors, as fd.c already does for the main VFD pool,  
but not without an additional layer of overhead and a lot of notational  
impact on the calling code.)  But we can at least let the array size be  
configurable.  Hence, change the code to allow up to max_safe_fds/2  
allocated file requests.  On modern platforms this should allow several  
hundred concurrent file_fdw scans, or more if one increases the value of  
max_files_per_process.  To go much further than that, we'd need to do some  
more work on the data structure, since the current code for closing  
requests has potentially O(N^2) runtime; but it should still be all right  
for request counts in this range.  
  
Back-patch to 9.1 where contrib/file_fdw was introduced.  

commit   : d7cb64aeb5a7e40f4ea75e60bba1d606ca06df7f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 8 Jun 2013 10:20:54 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 8 Jun 2013 10:20:54 -0400    

Long-standing code has called tolower() on identifier character bytes  
with the high bit set. This is clearly an error and produces junk output  
when the encoding is multi-byte. This patch therefore restricts this  
activity to cases where there is a character with the high bit set AND  
the encoding is single-byte.  
  
There have been numerous gripes about this, most recently from Martin  
Schäfer.  
  
Backpatch to all live releases.  

commit   : 8af3f277b4f941404ae43251e23d6561f2250ebb    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 7 Jun 2013 09:24:07 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 7 Jun 2013 09:24:07 -0500    

It claimed the value was always zero; it is really always -1.  
  
Per report from Hari Babu  
  
backpatch 734fbbd1d2d1babfbd195414e2445024ad549ae3 to 8.4  

commit   : ca6566612cfb2a4eb15d31aab5df312ebb786372    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Jun 2013 00:08:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 7 Jun 2013 00:08:02 -0400    

Swap the order of a couple of phrases to clarify what the adjective  
"subsequent" applies to.  
  
Joshua Tolley  

commit   : 3ebdf6c9f99b45adf2419db54c1303dabab4fe57    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 6 Jun 2013 18:25:26 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 6 Jun 2013 18:25:26 +0300    

commit   : f753c9d596d835d47770d1b3eed6ea9c1d3af4a8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Jun 2013 23:44:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Jun 2013 23:44:14 -0400    

The planner is aware that it mustn't push down upper-level quals into  
subqueries if the quals reference subquery output columns that contain  
set-returning functions or volatile functions, or are non-DISTINCT outputs  
of a DISTINCT ON subquery.  However, it missed making this check when  
there were one or more levels of UNION or INTERSECT above the dangerous  
expression.  This could lead to "set-valued function called in context that  
cannot accept a set" errors, as seen in bug #8213 from Eric Soroos, or to  
silently wrong answers in the other cases.  
  
To fix, refactor the checks so that we make the column-is-unsafe checks  
during subquery_is_pushdown_safe(), which already has to recursively  
inspect all arms of a set-operation tree.  This makes  
qual_is_pushdown_safe() considerably simpler, at the cost that we will  
spend some cycles checking output columns that possibly aren't referenced  
in any upper qual.  But the cases where this code gets executed at all  
are already nontrivial queries, so it's unlikely anybody will notice any  
slowdown of planning.  
  
This has been broken since commit 05f916e6add9726bf4ee046e4060c1b03c9961f2,  
which makes the bug over ten years old.  A bit surprising nobody noticed it  
before now.  

commit   : 940a85e5e1c32d479d43df89c410195063e786d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Jun 2013 13:32:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Jun 2013 13:32:53 -0400    

In commit 2c92edad48796119c83d7dbe6c33425d1924626d, I broke "EXPLAIN  
(ANALYZE)" syntax, because I mistakenly thought that ANALYZE/ANALYSE were  
only partially reserved and thus would be included in NonReservedWord;  
but actually they're fully reserved so they still need to be called out  
here.  
  
A nicer solution would be to demote these words to type_func_name_keyword  
status (they can't be less than that because of "VACUUM [ANALYZE] ColId").  
While that works fine so far as the core grammar is concerned, it breaks  
ECPG's grammar for reasons I don't have time to isolate at the moment.  
So do this for the time being.  
  
Per report from Kevin Grittner.  Back-patch to 9.0, like the previous  
commit.  

commit   : f94979f618abffb63cad2266f39db8beeeb18afc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Jun 2013 17:22:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Jun 2013 17:22:29 -0400    

The new message (and SQLSTATE) matches the corresponding error cases in  
namespace.c.  
  
This was thought to be a "can't happen" case when extension.c was written,  
so we didn't think hard about how to report it.  But it definitely can  
happen in 9.2 and later, since we no longer require search_path to contain  
any valid schema names.  It's probably also possible in 9.1 if search_path  
came from a noninteractive source.  So, back-patch to all releases  
containing this code.  
  
Per report from Sean Chittenden, though this isn't exactly his patch.  

commit   : dc12e477eb8a9b502bb613299b9e2b3acd85a4d5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Jun 2013 14:58:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Jun 2013 14:58:57 -0400    

The array allocated by GetRunningTransactionLocks() needs to be pfree'd  
when we're done with it.  Otherwise we leak some memory during each  
checkpoint, if wal_level = hot_standby.  This manifests as memory bloat  
in the checkpointer process, or in bgwriter in versions before we made  
the checkpointer separate.  
  
Reported and fixed by Naoya Anzai.  Back-patch to 9.0 where the issue  
was introduced.  
  
In passing, improve comments for GetRunningTransactionLocks(), and add  
an Assert that we didn't overrun the palloc'd array.  

commit   : 89bd9fe5fde46af8e2d93d2cb78a8142ac7caf4d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Jun 2013 14:19:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Jun 2013 14:19:36 -0400    

"eval q{foo}" used to complain that the error was on line 2 of the eval'd  
string, because eval internally tacked on "\n;" so that the end of the  
erroneous command was indeed on line 2.  But as of Perl 5.18 it more  
sanely says that the error is on line 1.  To avoid Perl-version-dependent  
regression test results, use "eval q{foo;}" instead in the two places  
where this matters.  Per buildfarm.  
  
Since people might try to use newer Perl versions with older PG releases,  
back-patch as far as 9.0 where these test cases were added.  

commit   : 1e5588cfd966ef5f4a1e31625b7079cff6d91a5a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2013 20:09:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Jun 2013 20:09:32 -0400    

This change makes type_func_name_keywords less reserved than they were  
before, by allowing them for role names, language names, EXPLAIN and COPY  
options, and SET values for GUCs; which are all places where few if any  
actual keywords could appear instead, so no new ambiguities are introduced.  
  
The main driver for this change is to allow "COPY ... (FORMAT BINARY)"  
to work without quoting the word "binary".  That is an inconsistency that  
has been complained of repeatedly over the years (at least by Pavel Golub,  
Kurt Lidl, and Simon Riggs); but we hadn't thought of any non-ugly solution  
until now.  
  
Back-patch to 9.0 where the COPY (FORMAT BINARY) syntax was introduced.  

commit   : 39485bbdbadab26287e097474bb63acda4593abb    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 27 May 2013 11:12:54 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 27 May 2013 11:12:54 -0400    

The documentation for ALTER TYPE .. RENAME claimed to support a  
RESTRICT/CASCADE option at the 'type' level, which wasn't implemented  
and doesn't make a whole lot of sense to begin with.  What is supported,  
and previously undocumented, is  
  
ALTER TYPE .. RENAME ATTRIBUTE .. RESTRICT/CASCADE.  
  
I've updated the documentation and back-patched this to 9.1 where it was  
first introduced.  

commit   : 7b2d780f2ade55b9d569b1af093e74d4cbfc7792    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 23 May 2013 11:34:30 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 23 May 2013 11:34:30 -0400    

Pavan Deolasee  

commit   : 9d8bc2f0aeaa7f7fceb393fe5740cb709c0f27e7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 May 2013 15:04:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 May 2013 15:04:46 -0400    

PathNameOpenFile failed to ensure that the correct value of errno was  
returned to its caller after a failure (because it incorrectly supposed  
that free() can never change errno).  In some cases this would result  
in a user-visible failure because an expected ENOENT errno was replaced  
with something else.  Bogus EINVAL failures have been observed on OS X,  
for example.  
  
There were also a couple of places that could mangle an important value  
of errno if FDDEBUG was defined.  While the usefulness of that debug  
support is highly debatable, we might as well make it safe to use,  
so add errno save/restore logic to the DO_DB macro.  
  
Per bug #8167 from Nelson Minar, diagnosed by RhodiumToad.  
Back-patch to all supported branches.  

commit   : ee249498a99a1b3be9906aa91f0783939ceb1e21    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 May 2013 15:40:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 May 2013 15:40:16 -0400    

If OID wraparound should occur while in standalone mode (unlikely but  
possible), we want to advance the counter to FirstNormalObjectId not  
FirstBootstrapObjectId.  Otherwise, user objects might be created with OIDs  
in the system-reserved range.  That isn't immediately harmful but it poses  
a risk of conflicts during future pg_upgrade operations.  
  
Noted by Andres Freund.  Back-patch to all supported branches, since all of  
them are supported sources for pg_upgrade operations.  

commit   : 0c2c0f82c2cd6d2fa83955e9d767059639010ffc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 May 2013 17:15:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 May 2013 17:15:43 -0400    

This case doesn't normally happen, because the planner usually clamps  
all row estimates to at least one row; but I found that it can arise  
when dealing with relations excluded by constraints.  Without a defense,  
estimate_num_groups() can return zero, which leads to divisions by zero  
inside the planner as well as assertion failures in the executor.  
  
An alternative fix would be to change set_dummy_rel_pathlist() to make  
the size estimate for a dummy relation 1 row instead of 0, but that seemed  
pretty ugly; and probably someday we'll want to drop the convention that  
the minimum rowcount estimate is 1 row.  
  
Back-patch to 8.4, as the problem can be demonstrated that far back.  

commit   : fd262376e9d81f77bde73ab70fa9abdcbc9c6199    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 May 2013 13:06:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 May 2013 13:06:57 -0400    

Per report from Keith Fiske.  
  
Marko Kreen  

commit   : 56ac62570591615ed68137e4d3197e881ca3a405    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 May 2013 17:34:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 May 2013 17:34:45 -0400    

This helps guard against changes in the set of reserved keywords from  
one version to another.  In theory it should only be an issue if we  
de-reserve a keyword in a newer release, since that can create the type  
of problem shown in bug #8128.  
  
Back-patch to 9.1 where the --quote-all-identifiers option was added.  

commit   : 6f3ec222fca384a6b63724c4a64029960de969fc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 4 May 2013 13:15:54 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 4 May 2013 13:15:54 -0400    

Restore 4-byte designation for docs.  Fix 9.3 doc query to properly pad  
to four digits.  
  
Backpatch to all active branches  
  
Per suggestions from Ian Lawrence Barwick  

commit   : 8f80e35b55b83debc4cd08ec27510c05e08e2496    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 4 May 2013 11:09:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 4 May 2013 11:09:44 -0400    

Backpatch to 9.1 and earlier  
  
Report from Ian Lawrence Barwick  

commit   : e1d1d8099300bbc55cd44afa4ecab0cca1f33953    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 2 May 2013 18:08:43 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 2 May 2013 18:08:43 +0300    

WAL segment means a 16 MB physical WAL file; this comment meant a logical  
4 GB log file.  
  
Amit Langote. Apply to backbranches only, as the comment is gone in master.  

commit   : 424cc31a3785bd01108e6f4b20941c6442d3d2d0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Apr 2013 16:31:21 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Apr 2013 16:31:21 +0300    

This is a follow-up to the earlier fix, which changed the recycling logic  
to recycle WAL segments under the current recovery target timeline. That  
turns out to be a bad idea, because installing a recycled segment with  
a TLI higher than what we're recovering at the moment means that the recovery  
logic will find the recycled WAL segment and try to replay it. It will fail,  
but but the mere presence of such a WAL segment will mask any other, real,  
file with the same log/seg, but smaller TLI.  
  
Per report from Mitsumasa Kondo. Apply to 9.1 and 9.2, like the previous  
fix. Master was already doing this differently; this patch makes 9.1 and  
9.2 to do the same thing as master.  

commit   : 93641341f0993131dfb90aa7ac4add3305d00b9c    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Mon, 29 Apr 2013 13:06:28 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Mon, 29 Apr 2013 13:06:28 -0500    

Patch b19e4250b45e91c9cbdd18d35ea6391ab5961c8d attempted to  
preserve existing behavior regarding statistics generation in the  
case that a truncation attempt was canceled due to lock conflicts.  
It failed to do this accurately in two regards: (1) autovacuum had  
previously generated statistics if the truncate attempt failed to  
initially get the lock rather than having started the attempt, and  
(2) the VACUUM ANALYZE command had always generated statistics.  
  
Both of these changes were unintended, and are reverted by this  
patch.  On review, there seems to be consensus that the previous  
failure to generate statistics when the truncate was terminated  
was more an unfortunate consequence of how that effort was  
previously terminated than a feature we want to keep; so this  
patch generates statistics even when an autovacuum truncation  
attempt terminates early.  Another unintended change which is kept  
on the basis that it is an improvement is that when a VACUUM  
command is truncating, it will the new heuristic for avoiding  
blocking other processes, rather than keeping an  
AccessExclusiveLock on the table for however long the truncation  
takes.  
  
Per multiple reports, with some renaming per patch by Jeff Janes.  
  
Backpatch to 9.0, where problem was created.  

commit   : 359c8e4545a0d67465205353bd0b086aedbf5293    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Fri, 26 Apr 2013 11:54:59 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Fri, 26 Apr 2013 11:54:59 -0700    

Backpatched to 9.1 when the extension management facility was added.  

commit   : 32ad1d696a0e7b50074d57b25708ffd1dc82600f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Apr 2013 16:58:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Apr 2013 16:58:14 -0400    

There was a high probability of two or more concurrent C.I.C. commands  
deadlocking just before completion, because each would wait for the others  
to release their reference snapshots.  Fix by releasing the snapshot  
before waiting for other snapshots to go away.  
  
Per report from Paul Hinze.  Back-patch to all active branches.  

commit   : ae76795214437f042151906d7f6f000382c2291c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 25 Apr 2013 14:03:10 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 25 Apr 2013 14:03:10 +0300    

Peter Geoghegan  

commit   : c13ed70a4f26bae435c297ae09b1be9f50f2eede    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 20 Apr 2013 16:59:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 20 Apr 2013 16:59:31 -0400    

When creating or manipulating a cached plan for a transaction control  
command (particularly ROLLBACK), we must not perform any catalog accesses,  
since we might be in an aborted transaction.  However, plancache.c busily  
saved or examined the search_path for every cached plan.  If we were  
unlucky enough to do this at a moment where the path's expansion into  
schema OIDs wasn't already cached, we'd do some catalog accesses; and with  
some more bad luck such as an ill-timed signal arrival, that could lead to  
crashes or Assert failures, as exhibited in bug #8095 from Nachiket Vaidya.  
Fortunately, there's no real need to consider the search path for such  
commands, so we can just skip the relevant steps when the subject statement  
is a TransactionStmt.  This is somewhat related to bug #5269, though the  
failure happens during initial cached-plan creation rather than  
revalidation.  
  
This bug has been there since the plan cache was invented, so back-patch  
to all supported branches.  

commit   : d189deebd3c9e178c32c420a0df2b1ef9d445119    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Apr 2013 22:37:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Apr 2013 22:37:32 -0400    

There's been some confusion expressed about this point, so clarify.  
Extended version of a patch by David Wheeler.  

commit   : 7ef110757efeafd1201791166d65ae114aa1e3d0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 4 Apr 2013 21:14:21 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 4 Apr 2013 21:14:21 -0400    

commit   : 88b000c1b6daabd9044cd3c68b0b9e94eacb4c65    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 4 Apr 2013 19:04:57 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 4 Apr 2013 19:04:57 +0300    

Throw an error instead.  
  
Backpatch to all supported branches.  

commit   : 6ce083f08a7a30360695c0e9a927fe24f4c77143    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 4 Apr 2013 16:31:44 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 4 Apr 2013 16:31:44 +0300    

The old formula didn't take into account that each WAL sender process needs  
a spinlock. We had also already exceeded the fixed number of spinlocks  
reserved for misc purposes (10). Bump that to 30.  
  
Backpatch to 9.0, where WAL senders were introduced. If I counted correctly,  
9.0 had exactly 10 predefined spinlocks, and 9.1 exceeded that, but bump the  
limit in 9.0 too because 10 is uncomfortably close to the edge.  

commit   : 677fde06afd23f355e3d599eedc3ba7a66ef4e85    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Apr 2013 21:15:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Apr 2013 21:15:50 -0400    

Notice and complain about PQcancel() failures.  Also, don't dump core if  
an error PGresult doesn't contain severity and message subfields, as it  
might not if it was generated by libpq itself.  (We have a longstanding  
TODO item to improve that, but in the meantime isolationtester had better  
cope.)  
  
I tripped across the latter item while investigating a trouble report on  
buildfarm member spoonbill.  As for the former, there's no evidence that  
PQcancel failure is actually involved in spoonbill's problem, but it still  
seems like a bad idea to ignore an error return code.