PostgreSQL 9.2.5 commit log

commit   : 7800229b36d0444cf2c61f5c5895108ee5e8ee2a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 23:16:13 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 23:16:13 -0400    

commit   : e2ccba06ac73e0cd833c700467b0fead8b8bfdf2    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 22:42:26 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 22:42:26 -0400    

This reverts commit 565beb41bdd73611ddb26165b7f6bb8b6157e49d.  

commit   : 7a80aaf7a2c3c6aa0a5c1fa24da78fa5e9abc784    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 22:37:26 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 22:37:26 -0400    

This reverts commit dd9abd3c995dbc4d32cfc97fde03fe3583e2717c.  
  
pending resolution of  
http://www.postgresql.org/message-id/[email protected]  

commit   : df9ede9063915bca311a14a482d97ef51d2082d3    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2013 21:35:02 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2013 21:35:02 -0400    

commit   : 903784337d2531ce40fbdd10f0acd6333c6e1e44    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 7 Oct 2013 23:57:40 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
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   : 4dd5c312fc0c661ab6e4a8dc4f104ce0c1abfc36    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 16:17:51 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 7 Oct 2013 16:17:51 -0400    

commit   : 1f4cdf20e62b8371cce6f1cb326b4470ef94d26a    
  
author   : Kevin Grittner <[email protected]>    
date     : Mon, 7 Oct 2013 14:15:24 -0500    
  
committer: Kevin Grittner <[email protected]>    
date     : Mon, 7 Oct 2013 14:15:24 -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   : 565beb41bdd73611ddb26165b7f6bb8b6157e49d    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 6 Oct 2013 23:06:10 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 6 Oct 2013 23:06:10 -0400    

Cédric Villemain and me.  

commit   : d565ece23b28d5f076c0a4f1e7bf40cc62c94f4d    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 2 Oct 2013 21:33:26 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 2 Oct 2013 21:33:26 -0400    

commit   : dd9abd3c995dbc4d32cfc97fde03fe3583e2717c    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 30 Sep 2013 10:36:01 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 30 Sep 2013 10:36:01 -0400    

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

commit   : fc7a38f3250d3678fb2f64d8b6a18cd380f1dd6a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 30 Sep 2013 11:29:09 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
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   : 59d30d9ff19bcb4e7537b3b44e926939f1cbce58    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 30 Sep 2013 00:07:48 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 30 Sep 2013 00:07:48 -0400    

This reverts commit cd453fef0bcfdc3c79c884e971cb84b88cb9d28d.  

commit   : cd453fef0bcfdc3c79c884e971cb84b88cb9d28d    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sun, 29 Sep 2013 17:32:13 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sun, 29 Sep 2013 17:32:13 -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   : e04619453085e9d18885f6bcd78f82a93266be1b    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 26 Sep 2013 11:24:40 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
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   : db7e953adde14689e885659b5c20037f98eaf294    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 25 Sep 2013 16:02:00 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 25 Sep 2013 16:02:00 +0300    

B-tree operators are not allowed to leak memory into the current memory  
context. Range_cmp leaked detoasted copies of the arguments. That caused  
a quick out-of-memory error when creating an index on a range column.  
  
Reported by Marian Krucina, bug #8468.  

commit   : 769c36ad1c565a7ad5d0a36ff450ef591f0dd150    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 24 Sep 2013 18:19:14 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 24 Sep 2013 18:19:14 -0300    

commit   : c05e9ec1c4054a5a7a18872bb40602e417fbfd03    
  
author   : Noah Misch <[email protected]>    
date     : Mon, 23 Sep 2013 16:00:13 -0400    
  
committer: Noah Misch <[email protected]>    
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   : d707a8ccd87d2a3d307c7bd19b1d30d3cb9b3ca5    
  
author   : Stephen Frost <[email protected]>    
date     : Mon, 23 Sep 2013 08:33:41 -0400    
  
committer: Stephen Frost <[email protected]>    
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   : 4392db8df17188e0163306b6e63822d739deb911    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 11 Sep 2013 20:10:15 -0400    
  
committer: Noah Misch <[email protected]>    
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   : e8193088f12ecc221692af3cf5f51c782e815f46    
  
author   : Michael Meskes <[email protected]>    
date     : Sun, 8 Sep 2013 12:59:43 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Sun, 8 Sep 2013 12:59:43 +0200    

Found by Coverity.  

commit   : 7612553e75f9ffb940b16a53004bec75f31803be    
  
author   : Michael Meskes <[email protected]>    
date     : Sun, 8 Sep 2013 12:49:54 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Sun, 8 Sep 2013 12:49:54 +0200    

commit   : 1bb4b62d3e5209dae1f1e441b7f01a053b7587f4    
  
author   : Jeff Davis <[email protected]>    
date     : Wed, 4 Sep 2013 23:30:27 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Wed, 4 Sep 2013 23:30:27 -0700    

Make the examples self-contained to avoid confusion. Per bug report  
8367 from KOIZUMI Satoru.  

commit   : 9ac5f63cea2d88ed4a06c06399258c5d3ba04c57    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 3 Sep 2013 18:32:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 3 Sep 2013 18:32:26 -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   : bc63ff2401a34a4ec6547f2a03072b68a268f9ec    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Sep 2013 15:06:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 Sep 2013 15:06:21 -0400    

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

commit   : 7d0492f33737f29ff2b4267020bde726104a754f    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 2 Sep 2013 14:36:24 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 2 Sep 2013 14:36:24 -0400    

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

commit   : e912963a22ba5c1bd909d6ee53f41b8ae6c69166    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 26 Aug 2013 14:56:49 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 26 Aug 2013 14:56:49 -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   : 005f583ba4e6d4d19b62959ef8e70a3da4d188a5    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 24 Aug 2013 15:14:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 24 Aug 2013 15:14:24 -0400    

The previous coding in plancache.c essentially used 10% of the estimated  
runtime as its cost estimate for planning.  This can be pretty bogus,  
especially when the estimated runtime is very small, such as in a simple  
expression plan created by plpgsql, or a simple INSERT ... VALUES.  
  
While we don't have a really good handle on how planning time compares  
to runtime, it seems reasonable to use an estimate based on the number of  
relations referenced in the query, with a rather large multiplier.  This  
patch uses 1000 * cpu_operator_cost * (nrelations + 1), so that even a  
trivial query will be charged 1000 * cpu_operator_cost for planning.  
This should address the problem reported by Marc Cousin and others that  
9.2 and up prefer custom plans in cases where the planning time greatly  
exceeds what can be saved.  

commit   : 3979ff1fc6e9dd7847ff9bb24beb4d03ebe02cef    
  
author   : Magnus Hagander <[email protected]>    
date     : Sat, 24 Aug 2013 17:11:31 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Sat, 24 Aug 2013 17:11:31 +0200    

The backup will not work (without a logarchive, and that's the whole  
point of -x) in this case, this patch just changes it to throw an  
error instead of crashing when this happens.  
  
Noticed and diagnosed by TAKATSUKA Haruka  

commit   : bd5ab4b28745605493ab7061724ba0375ee9593a    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 23 Aug 2013 17:31:00 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 23 Aug 2013 17:31:00 -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   : b94c6c691e86a1d9c2a98e935f661c95924d8f37    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 17 Aug 2013 21:46:32 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 17 Aug 2013 21:46:32 -0400    

commit   : cbb565f7c397fa8a74b214e1765ed9db66c3d8a4    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 3 Aug 2013 12:39:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 3 Aug 2013 12:39:54 -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   : 08767878ca865a021763c8650b57df65b40094cd    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 2 Aug 2013 14:34:56 -0400    
  
committer: Alvaro Herrera <[email protected]>    
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   : 1e8e324326be8fa907b51ba262cf0a21cb015ca3    
  
author   : Stephen Frost <[email protected]>    
date     : Thu, 1 Aug 2013 15:42:07 -0400    
  
committer: Stephen Frost <[email protected]>    
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   : 9d7f66bc6c620f8c7548fc65d0e8e160615d5267    
  
author   : Stephen Frost <[email protected]>    
date     : Thu, 1 Aug 2013 01:15:45 -0400    
  
committer: Stephen Frost <[email protected]>    
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   : 8505ebf31eb50c20afeaca0e0dfa2fbb1cec001f    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 31 Jul 2013 11:31:30 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 31 Jul 2013 11:31:30 -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   : e73357c10b8ca7f38e83e73e57f09d774a83db2f    
  
author   : Fujii Masao <[email protected]>    
date     : Wed, 31 Jul 2013 22:37:11 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Wed, 31 Jul 2013 22:37:11 +0900    

Currently we don't need to update the pg_tablespace catalog  
after redefining the symbolic links to the tablespaces  
because pg_tablespace.spclocation column was removed in  
PostgreSQL 9.2.  
  
Back patch to 9.2 where pg_tablespace.spclocation was removed.  
  
Ian Barwick, with minor change by me.  

commit   : b3ddd1063567de4a4af8dae6cc96cb33466cf954    
  
author   : Noah Misch <[email protected]>    
date     : Tue, 30 Jul 2013 18:36:52 -0400    
  
committer: Noah Misch <[email protected]>    
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   : 9822dc38e193f5f9e6f088e6566cfcb1dba49db2    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 29 Jul 2013 10:42:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 29 Jul 2013 10:42:44 -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   : 8714465f0f5ca54b6ad8b1fc8320fad6b8e9e2aa    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2013 11:39:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2013 11:39:15 -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   : 9f8254c18cd73404abce53d832723fe104caef14    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 24 Jul 2013 00:44:09 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 980c24e1e80223ccd70e50d9d64c2b38cf50879e    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 23 Jul 2013 17:38:32 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 23 Jul 2013 17:38:32 -0400    

Per Coverity Scan  

commit   : 5fbc3130b3fe34ddd679ad5c91a4c9d4bc0b9691    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 23 Jul 2013 16:23:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 23 Jul 2013 16:23:08 -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   : c0977b465ad26857910cb0a37a2382e2429a7b9a    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 20 Jul 2013 12:44:37 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 20 Jul 2013 12:44:37 -0400    

If an error is thrown out of the datatype I/O functions called by this  
function, we need to do subtransaction cleanup, which the previous coding  
entirely failed to do.  Fortunately, both existing callers of this function  
already have proper cleanup logic, so re-throwing the exception is enough.  
  
Also, postpone creation of the resultset tupdesc until after the I/O  
conversions are complete, so that we won't leak memory in TopMemoryContext  
when such an error happens.  

commit   : e8ceb47bd3b86fea9fcf0c30bc3e0ec33ad6616b    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 19 Jul 2013 10:23:12 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 19 Jul 2013 10:23:12 -0400    

David Christensen  

commit   : c9351a9da5f0d8ef3a992452e727a5062d80adee    
  
author   : Michael Meskes <[email protected]>    
date     : Fri, 19 Jul 2013 08:59:20 +0200    
  
committer: Michael Meskes <[email protected]>    
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   : f1cb440d3eaab839bfa5c8f2db529b5c87025058    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 18 Jul 2013 21:22:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 18 Jul 2013 21:22:47 -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   : cce5d681be7abfd9f48c28151ebf2b242f8ba438    
  
author   : Stephen Frost <[email protected]>    
date     : Wed, 17 Jul 2013 10:50:39 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Wed, 17 Jul 2013 10:50:39 -0400    

The documentation for ALTER VIEW had a minor copy-and-paste error in  
defining the parameters.  Noticed when reviewing the WITH CHECK OPTION  
patch.  
  
Backpatch to 9.2 where this was first introduced.  

commit   : a3957ac156da7e31da46a2d8e3b6c7669333cc99    
  
author   : Stephen Frost <[email protected]>    
date     : Mon, 15 Jul 2013 10:42:27 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Mon, 15 Jul 2013 10:42:27 -0400    

In pg_basebackup.c:reached_end_position(), we're reading from an  
internal pipe with our own background process but we're possibly  
reading more bytes than will actually fit into our buffer due to  
an off-by-one error.  As we're reading from an internal pipe  
there's no real risk here, but it's good form to not depend on  
such convenient arrangements.  
  
Bug spotted by the Coverity scanner.  
  
Back-patch to 9.2 where this showed up.  

commit   : 89c09fe02d9aa77aea28525b97229f61f1d5e471    
  
author   : Stephen Frost <[email protected]>    
date     : Sun, 14 Jul 2013 16:43:23 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Sun, 14 Jul 2013 16:43:23 -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   : 129e9dd1a2527a5a69d9761f11991a1857bcd91d    
  
author   : Michael Meskes <[email protected]>    
date     : Thu, 27 Jun 2013 16:00:32 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Thu, 27 Jun 2013 16:00:32 +0200    

Thanks to MauMau <[email protected]> for finding and fixing this.  

commit   : 921a0b20138c73a3de3067c89cf7424b3d22c1ef    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 11 Jul 2013 09:43:17 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 11 Jul 2013 09:43:17 -0400    

commit   : 1bd25c03487dd2f96035f88c77fc0d89bb438fac    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 7 Jul 2013 22:37:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 7 Jul 2013 22:37:32 -0400    

The code in set_append_rel_pathlist() for building parameterized paths  
for append relations (inheritance and UNION ALL combinations) supposed  
that the cheapest regular path for a child relation would still be cheapest  
when reparameterized.  Which might not be the case, particularly if the  
added join conditions are expensive to compute, as in a recent example from  
Jeff Janes.  Fix it to compare child path costs *after* reparameterizing.  
We can short-circuit that if the cheapest pre-existing path is already  
parameterized correctly, which seems likely to be true often enough to be  
worth checking for.  
  
Back-patch to 9.2 where parameterized paths were introduced.  

commit   : 62ba0c12e599a377b3c1f1c94e0018a7c6f348ec    
  
author   : Magnus Hagander <[email protected]>    
date     : Sun, 7 Jul 2013 13:36:20 +0200    
  
committer: Magnus Hagander <[email protected]>    
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   : 08748b95e7baa52b7827b341fa988d268937d226    
  
author   : Michael Meskes <[email protected]>    
date     : Sat, 6 Jul 2013 22:08:53 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Sat, 6 Jul 2013 22:08:53 +0200    

commit   : 8a7de29002f5c111dbee94ffb98a8cd997ae30a9    
  
author   : Magnus Hagander <[email protected]>    
date     : Fri, 5 Jul 2013 16:21:08 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Fri, 5 Jul 2013 16:21:08 +0200    

Erikjan Rijkers  

commit   : da9fb7801d477c481c9265185be2192758db7743    
  
author   : Michael Meskes <[email protected]>    
date     : Fri, 5 Jul 2013 11:07:16 +0200    
  
committer: Michael Meskes <[email protected]>    
date     : Fri, 5 Jul 2013 11:07:16 +0200    

commit   : 74414bbd90a307c949489bcc630bdc9559cc5682    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 3 Jul 2013 14:19:43 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 3 Jul 2013 14:19:43 -0400    

commit   : ca871e71e6f082f20bdafba2450030f12f9d144c    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 2 Jul 2013 12:21:16 -0400    
  
committer: Alvaro Herrera <[email protected]>    
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  
[email protected]  
  
Author: Albe Laurenz  
Reviewed by: Abhijit Menon-Sen  

commit   : c4f386f51d30d14e9a21888795c207a59fd693a0    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 2 Jul 2013 17:23:42 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 2 Jul 2013 17:23:42 +0300    

With -Wtype-limits, gcc correctly points out that size_t can never be < 0.  
Backpatch to 9.3 and 9.2. It's been like this forever, but in <= 9.1 you got  
a lot other warnings with -Wtype-limits anyway (at least with my version of  
gcc).  
  
Andres Freund  

commit   : 538ecfad3c6031b8efe0644b9082af91760cf448    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 27 Jun 2013 13:54:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 27 Jun 2013 13:54:59 -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   : 2beeabcd0723ef5d39d02aca9cc8ee92588eb8af    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 27 Jun 2013 12:36:44 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 60d7edb835c11f15c1d88f8985795ec4abc480f4    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 27 Jun 2013 00:23:37 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 27 Jun 2013 00:23:37 -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   : 1f3fbced6502dbe0427331dfa47fed0f3c50b955    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 26 Jun 2013 19:51:56 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 26 Jun 2013 19:51:56 -0400    

Back-patch to all supported versions.  
  
Laurenz Albe  

commit   : 5734eb2c92a5efd665186c52b8eebdf2880868b5    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 25 Jun 2013 13:45:03 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 25 Jun 2013 13:45:03 -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   : bee4a4d361c054c531c3a27024f9ff3efef3635b    
  
author   : Fujii Masao <[email protected]>    
date     : Wed, 26 Jun 2013 02:19:26 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Wed, 26 Jun 2013 02:19:26 +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   : 99ee15b315c187045a95db7b27fd9d866aea93e0    
  
author   : Simon Riggs <[email protected]>    
date     : Sun, 23 Jun 2013 11:05:02 +0100    
  
committer: Simon Riggs <[email protected]>    
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   : 73c103dfa7970ea6e83a497b6d72af6f2df566a1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 19 Jun 2013 22:25:13 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 19 Jun 2013 22:25:13 -0400    

More languages than SQL and PL/pgSQL actually support parameter names.  

commit   : de31442b8b2818e211be3e334f778746705c5ab2    
  
author   : Kevin Grittner <[email protected]>    
date     : Wed, 19 Jun 2013 10:37:57 -0500    
  
committer: Kevin Grittner <[email protected]>    
date     : Wed, 19 Jun 2013 10:37:57 -0500    

In Danish collations, there are letter combinations which sort  
higher than 'Z'.  A test for values > 'WA' was picking up rows  
where the value started with 'AA', causing the test to fail.  
  
Backpatch to 9.2, where the failing test was added.  
  
Per report from Svenne Krap and analysis by Jeff Janes  

commit   : 20a562f9178b3d9118fe48950b4cf89f436ad020    
  
author   : Simon Riggs <[email protected]>    
date     : Tue, 18 Jun 2013 12:00:32 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Tue, 18 Jun 2013 12:00:32 +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   : 25f5487aba82601deb650870f5a67b5d1c4ee141    
  
author   : Fujii Masao <[email protected]>    
date     : Sun, 16 Jun 2013 05:13:58 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Sun, 16 Jun 2013 05:13:58 +0900    

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

commit   : cbabf50dccc29aed456a56ae8909d4d593c3ab38    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 14 Jun 2013 14:26:50 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 14 Jun 2013 14:26:50 -0400    

SP-GiST's original scheme for avoiding deadlocks during concurrent index  
insertions doesn't work, as per report from Hailong Li, and there isn't any  
evident way to make it work completely.  We could possibly lock individual  
inner tuples instead of their whole pages, but preliminary experimentation  
suggests that the performance penalty would be huge.  Instead, if we fail  
to get a buffer lock while descending the tree, just restart the tree  
descent altogether.  We keep the old tuple positioning rules, though, in  
hopes of reducing the number of cases where this can happen.  
  
Teodor Sigaev, somewhat edited by Tom Lane  

commit   : 7e0b9ed6c52bc19221c401859a2cfc3c8b07b43f    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2013 13:11:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2013 13:11:35 -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   : 40baa43588fed893644aac1a2606e6e29e8d6f75    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 12 Jun 2013 12:20:59 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Wed, 12 Jun 2013 12:20:59 -0400    

Patch by me, reviewed by Tatsuo Ishii.  

commit   : fd59974f2da79bee0599673358729e30d0f72359    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 11 Jun 2013 17:26:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 11 Jun 2013 17:26:48 -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   : c571b5168e55f2d98f5b3051ff56992edff506f5    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Tue, 11 Jun 2013 14:25:58 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Tue, 11 Jun 2013 14:25:58 +0900    

commit   : 1723df6e4ad4d6b0daeb3d917d3b6261af2ec379    
  
author   : Joe Conway <[email protected]>    
date     : Sun, 9 Jun 2013 17:31:26 -0700    
  
committer: Joe Conway <[email protected]>    
date     : Sun, 9 Jun 2013 17:31:26 -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   : 5cd77baab32a54da7534ca92e195dc0bc2e44ff4    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 9 Jun 2013 18:39:27 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 9 Jun 2013 18:39:27 -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   : 5f4a3116865c6482f6e62f4ec4c9152053bc28ca    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 9 Jun 2013 15:26:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 9 Jun 2013 15:26:48 -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   : a9ec978eb730e0ee9a0aa329009b15f1ead78386    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 9 Jun 2013 13:47:00 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 9 Jun 2013 13:47:00 -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   : a56c92f938f81df6b9d59b5bb7edc44008f0e06c    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 8 Jun 2013 10:21:06 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 8 Jun 2013 10:21:06 -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   : cd4fe9514f31cb56a471b1f8b2380f4ff5fc2f91    
  
author   : Kevin Grittner <[email protected]>    
date     : Fri, 7 Jun 2013 09:23:01 -0500    
  
committer: Kevin Grittner <[email protected]>    
date     : Fri, 7 Jun 2013 09:23:01 -0500    

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

commit   : 58855fbf105701cec8c5cbc65635447c00ccf711    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 7 Jun 2013 00:08:02 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 7e775be6d2cd414fa26e026bed50a9a5f2cd4a4d    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 6 Jun 2013 18:25:26 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 6 Jun 2013 18:25:26 +0300    

commit   : 17fa4c321ccf9693de406faffe6b235e949aa25f    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 6 Jun 2013 10:15:45 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 6 Jun 2013 10:15:45 -0400    

Andres Freund  

commit   : 4c641d994e19676ef2fec574d52d2156ffc2b3ce    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 6 Jun 2013 10:14:46 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 6 Jun 2013 10:14:46 -0400    

Andres' fix for XLOG_HEAP2_VISIBLE on unitialized pages requires  
this.  

commit   : 6ab834fde7b18f8189a05c754901fc99f4b1f9d9    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 6 Jun 2013 10:13:54 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 6 Jun 2013 10:13:54 -0400    

commit   : 341757bdcbeea0fa0df410aca377347f22de3645    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 5 Jun 2013 23:44:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 5 Jun 2013 23:44:08 -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   : 48b5120977e20aef92a080002966ee95e4005d39    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 5 Jun 2013 13:32:53 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 75b161d015c49e211224cbe3c8c8a009bfea368e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 7 May 2013 21:23:21 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 7 May 2013 21:23:21 -0400    

Karl O. Pinc  

commit   : 2ff74efa40adac394f11070af8d2ee8c79ba96c0    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 4 Jun 2013 17:22:29 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 612ecf311bf253cdb0c54252854c5298aa668203    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 4 Jun 2013 15:42:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 4 Jun 2013 15:42:02 -0400    

Use the same gcc atomic functions as we do on newer ARM chips.  
(Basically this is a copy and paste of the __arm__ code block,  
but omitting the SWPB option since that definitely won't work.)  
  
Back-patch to 9.2.  The patch would work further back, but we'd also  
need to update config.guess/config.sub in older branches to make them  
build out-of-the-box, and there hasn't been demand for it.  
  
Mark Salter  

commit   : 81fe138ba252987815506caa57719822709b730f    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 4 Jun 2013 14:58:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 4 Jun 2013 14:58:52 -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   : cc510d97afe63cacb3129d4bd19b14118cada6bb    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 3 Jun 2013 14:19:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 3 Jun 2013 14:19:32 -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   : 17a22a74a73a0fc11ef7a590aecebd98982a7169    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 2 Jun 2013 20:09:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 2 Jun 2013 20:09:26 -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   : 47ebaba6b4d0da3613253b2b2f7647413be278db    
  
author   : Robert Haas <[email protected]>    
date     : Wed, 29 May 2013 07:11:21 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Wed, 29 May 2013 07:11:21 -0400    

Tomas Vondra  

commit   : 02230d3cd01c99834fcb1bc468091f1c27362127    
  
author   : Stephen Frost <[email protected]>    
date     : Mon, 27 May 2013 11:12:54 -0400    
  
committer: Stephen Frost <[email protected]>    
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   : 6e83fc6d05793691d795814e55168783874721de    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 23 May 2013 11:34:30 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 23 May 2013 11:34:30 -0400    

Pavan Deolasee  

commit   : fcf91c06e0f836b0db52f2d6f40dd735dd42c7e3    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 23 May 2013 07:49:59 -0400    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 23 May 2013 07:49:59 -0400    

When COPY uses the multi-insert method to insert a batch of tuples into the  
heap at a time, incorrect line number was printed if something went wrong in  
inserting the index tuples (primary key failure, for exampl), or processing  
after row triggers.  
  
Fixes bug #8173 reported by Lloyd Albin. Backpatch to 9.2, where the multi-  
insert code was added.  

commit   : e7e005ed90f7e417696a9388717f91b55fd195bb    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 16 May 2013 15:04:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 16 May 2013 15:04:38 -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   : 630a8af5933f090cb24b0fb9da0296d0a32a5675    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 13 May 2013 15:40:16 -0400    
  
committer: Tom Lane <[email protected]>    
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   : 4a3613f930a1c895c2fdf83fa83a0f31b0c77e3b    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 11 May 2013 12:07:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 11 May 2013 12:07:47 -0400    

The 9.2 patch that added argument name support in SQL-language functions  
missed updating a parenthetical comment about that in the CREATE FUNCTION  
reference page.  Noted by Erwin Brandstetter.  

commit   : 4ebbbf3c483a47e1627fae50c41f650b2a1d549f    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 10 May 2013 17:15:35 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 10 May 2013 17:15:35 -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   : a184461aa750ca7d63c126774d2d24ec207645b5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 10 May 2013 13:06:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 10 May 2013 13:06:52 -0400    

Per report from Keith Fiske.  
  
Marko Kreen  

commit   : eb6cc854adbcf08778c31441f7aab053168928e6    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 9 May 2013 23:08:25 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 9 May 2013 23:08:25 -0400    

Commit d22a09dc70f9830fa78c1cd1a3a453e4e473d354 introduced official support  
for GiST consistentFns that want to cache data using the FmgrInfo fn_extra  
pointer: the idea was to preserve the cached values across gistrescan(),  
whereas formerly they'd been leaked.  However, there was an oversight in  
that, namely that multiple scan keys might reference the same column's  
consistentFn; the code would result in propagating the same cache value  
into multiple scan keys, resulting in crashes or wrong answers.  Use a  
separate array instead to ensure that each scan key keeps its own state.  
  
Per bug #8143 from Joel Roller.  Back-patch to 9.2 where the bug was  
introduced.  

commit   : 44f5bb245ce497ef052d93b5c17e368ffaac83a8    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 9 May 2013 17:34:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 9 May 2013 17:34:40 -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   : 3a33d5689b5e5c39afd68d2e32153c4e9d6a9a96    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 8 May 2013 17:01:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 8 May 2013 17:01:19 -0400    

This reverts commit 15b0421002624919c62ae3c6574af2a8452bf6c4.  Per  
complaint from Robert Haas, that patch caused crashes on appendrel  
cases, and it didn't fix all forms of the problem anyway.  Consensus  
is we'll leave this problem alone in the back branches, at least  
for now.  

commit   : edc8e85984116a2e93b2c6bcddccf378096b85a8    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 4 May 2013 13:15:54 -0400    
  
committer: Bruce Momjian <[email protected]>    
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   : 4aea429050289c2707bd8f1f63344569791645bd    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 4 May 2013 11:05:16 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 4 May 2013 11:05:16 -0400    

Backpatch to 9.2.  
  
Report from Ian Lawrence Barwick  

commit   : 7fa56e636e42d1bc969483ed1f2c93d47abe39ba    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 2 May 2013 18:08:43 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
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   : 15b0421002624919c62ae3c6574af2a8452bf6c4    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 1 May 2013 18:26:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 1 May 2013 18:26:58 -0400    

A view defined as "select <something> where false" had the curious property  
that the system wouldn't check whether users had the privileges necessary  
to select from it.  More generally, permissions checks could be skipped  
for tables referenced in sub-selects or views that were proven empty by  
constraint exclusion (although some quick testing suggests this seldom  
happens in cases of practical interest).  This happened because the planner  
failed to include rangetable entries for such tables in the finished plan.  
  
This was noticed in connection with erroneous handling of materialized  
views, but actually the issue is quite unrelated to matviews.  Therefore,  
revert commit 200ba1667b3a8d7a9d559d2f05f83d209c9d8267 in favor of a more  
direct test for the real problem.  
  
Back-patch to 9.2 where the bug was introduced (by commit  
7741dd6590073719688891898e85f0cb73453159).  

commit   : 4aed94f1660fb55bc825bf7f3135379dab28eb55    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 30 Apr 2013 16:31:21 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
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   : 841c9b6ba151ed5a41733ec345bf9bf32a55f4dc    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 29 Apr 2013 14:49:16 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 29 Apr 2013 14:49:16 -0400    

This patch gets rid of the concept of, and infrastructure for,  
non-canonical PathKeys; we now only ever create canonical pathkey lists.  
  
The need for non-canonical pathkeys came from the desire to have  
grouping_planner initialize query_pathkeys and related pathkey lists before  
calling query_planner.  However, since query_planner didn't actually *do*  
anything with those lists before they'd been made canonical, we can get rid  
of the whole mess by just not creating the lists at all until the point  
where we formerly canonicalized them.  
  
There are several ways in which we could implement that without making  
query_planner itself deal with grouping/sorting features (which are  
supposed to be the province of grouping_planner).  I chose to add a  
callback function to query_planner's API; other alternatives would have  
required adding more fields to PlannerInfo, which while not bad in itself  
would create an ABI break for planner-related plugins in the 9.2 release  
series.  This still breaks ABI for anything that calls query_planner  
directly, but it seems somewhat unlikely that there are any such plugins.  
  
I had originally conceived of this change as merely a step on the way to  
fixing bug #8049 from Teun Hoogendoorn; but it turns out that this fixes  
that bug all by itself, as per the added regression test.  The reason is  
that now get_eclass_for_sort_expr is adding the ORDER BY expression at the  
end of EquivalenceClass creation not the start, and so anything that is in  
a multi-member EquivalenceClass has already been created with correct  
em_nullable_relids.  I am suspicious that there are related scenarios in  
which we still need to teach get_eclass_for_sort_expr to compute correct  
nullable_relids, but am not eager to risk destabilizing either 9.2 or 9.3  
to fix bugs that are only hypothetical.  So for the moment, do this and  
stop here.  
  
Back-patch to 9.2 but not to earlier branches, since they don't exhibit  
this bug for lack of join-clause-movement logic that depends on  
em_nullable_relids being correct.  (We might have to revisit that choice  
if any related bugs turn up.)  In 9.2, don't change the signature of  
make_pathkeys_for_sortclauses nor remove canonicalize_pathkeys, so as  
not to risk more plugin breakage than we have to.  

commit   : 95909f3be1501b4b1e051d590c28e67a33ba9744    
  
author   : Kevin Grittner <[email protected]>    
date     : Mon, 29 Apr 2013 13:05:56 -0500    
  
committer: Kevin Grittner <[email protected]>    
date     : Mon, 29 Apr 2013 13:05:56 -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   : 4dbe52d3bf4d17fd1389f987126db67650085255    
  
author   : Joe Conway <[email protected]>    
date     : Fri, 26 Apr 2013 11:54:14 -0700    
  
committer: Joe Conway <[email protected]>    
date     : Fri, 26 Apr 2013 11:54:14 -0700    

Backpatched to 9.1 when the extension management facility was added.  

commit   : 9e859a9150cabd44e91ed80a90d45223b1e3986e    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 25 Apr 2013 16:58:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 25 Apr 2013 16:58:10 -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   : 719845b5a76477ab28ee12633c7ea07f777649d9    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 25 Apr 2013 14:03:10 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 25 Apr 2013 14:03:10 +0300    

Peter Geoghegan  

commit   : dbfeb8240631a893642dbd4112da73cc87f47dd8    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 21 Apr 2013 22:16:12 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 21 Apr 2013 22:16:12 -0400    

LANGUAGE 'plpgsql' no longer works.  The single quotes need to be  
removed.  
  
Erwin Brandstetter  

commit   : c37ec840cfe80e8fde05bc87417ced2765ab17dd    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 20 Apr 2013 16:59:27 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 20 Apr 2013 16:59:27 -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   : e3a7675e671803345f20c826a5807f57f599e0a1    
  
author   : Magnus Hagander <[email protected]>    
date     : Wed, 10 Apr 2013 21:37:49 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Wed, 10 Apr 2013 21:37:49 +0200    

Remove references to "one click", as we're not supposed to call  
them that anymore.  

commit   : 9d695fc7db91d3d9fb9d58d491c31b58e9bdcdfa    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 6 Apr 2013 22:28:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 6 Apr 2013 22:28:53 -0400    

Per report from Jaime Casanova.  Very curious that no one else has seen  
this failure ... but the code is clearly wrong as-is.  

commit   : 4cf2115072b5bdc31748872cfc6ba0c32ba36f6f    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 4 Apr 2013 22:37:29 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 4 Apr 2013 22:37:29 -0400    

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

commit   : 39d4c764da3d4dd74238d82b0e5ccd1030ebf9f7    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 4 Apr 2013 12:56:21 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 4 Apr 2013 12:56:21 -0400    

'strdup' the PSQLRC environment variable value before calling a routine  
that might free() it.  
  
Backpatch to 9.2, where the bug first appeared.  

commit   : c99e0d382f811cf0fbad50e912183ed4eb7b8de8    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 4 Apr 2013 19:04:57 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Thu, 4 Apr 2013 19:04:57 +0300    

Throw an error instead.  
  
Backpatch to all supported branches.  

commit   : 9508754ed7e3b5688c97a26bbe15af7e11d7f06a    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Thu, 4 Apr 2013 16:31:44 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
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   : a0c2492b957a7e89b997d03d0d62f37fee7aafdf    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 3 Apr 2013 14:13:34 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 3 Apr 2013 14:13:34 -0400    

The point of turning off track_activities is to avoid this reporting  
overhead, but a thinko in commit 4f42b546fd87a80be30c53a0f2c897acb826ad52  
caused pgstat_report_activity() to perform half of its updates anyway.  
Fix that, and also make sure that we clear all the now-disabled fields  
when transitioning to the non-reporting state.  

commit   : e084b1446ffa9ec09c3774221011ed686a8b1e7d    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 2 Apr 2013 21:15:45 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 2 Apr 2013 21:15:45 -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.