PostgreSQL 9.3.0 commit log

commit   : da645b3a73580ac30cf02e932b42d06157b98229    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Sep 2013 16:53:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 Sep 2013 16:53:17 -0400    

commit   : e3d02a10ec1831216f6d63a48e390a53a01b0927    
  
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   : 4e1e5d3bad9d51e5695c8a42612343662e886a64    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 2 Sep 2013 14:37:53 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 2 Sep 2013 14:37:53 -0400    

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

commit   : c7ef895f697627f60c51f44d8a9d64431840b4da    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 2 Sep 2013 02:28:21 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 2 Sep 2013 02:28:21 -0400    

commit   : b9a06c9329822259bab45f34ecc6a5839f0ffc53    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 1 Sep 2013 19:43:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 1 Sep 2013 19:43:02 -0400    

It seems like a good idea to update these examples since some fairly  
basic planner behaviors have changed in 9.3; notably that the startup cost  
for an indexscan plan node is no longer invariably estimated at 0.00.  

commit   : 3234a64f454cf9f2f6b8df24a551bec0ecfdd74b    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 31 Aug 2013 23:53:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 31 Aug 2013 23:53:33 -0400    

Some corrections, a lot of copy-editing.  
  
Set projected release date as 2013-09-09.  

commit   : 3c2a425da71d56edade2d7e2734305e8af778c9a    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 30 Aug 2013 21:40:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 30 Aug 2013 21:40:21 -0400    

The previous version of the query disregarded the result of the MergeAppend  
instead of checking its results.  
  
Andres Freund  

commit   : ce58aad2ba13885e2c5fa50e31ee5945e883096b    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 30 Aug 2013 19:27:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 30 Aug 2013 19:27:40 -0400    

Per Andres Freund.  

commit   : 16e8e36cebba8909ec01ca259f32e8dd40090657    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 30 Aug 2013 19:15:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 30 Aug 2013 19:15:21 -0400    

Failing to do so can cause queries to return wrong data, error out or crash.  
This requires adding a new binaryheap_reset() method to binaryheap.c,  
but that probably should have been there anyway.  
  
Per bug #8410 from Terje Elde.  Diagnosis and patch by Andres Freund.  

commit   : dfed97b744a4706d7c7b410667c0c5bc92d0eb8d    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 29 Aug 2013 12:33:50 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 29 Aug 2013 12:33:50 -0400    

commit   : e536d47ab7eb447ef0be849a8b2e06ae9080017c    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 26 Aug 2013 14:58:14 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 26 Aug 2013 14:58:14 -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   : a5f11e24a4d1afb213c780812a3df14c04d7f845    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 24 Aug 2013 15:14:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 24 Aug 2013 15:14:21 -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   : 3cf89057b5bced4478a285e0b49e321996b40044    
  
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   : c19617d5355e41074623bbb7c3efda532c20f637    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 23 Aug 2013 17:30:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 23 Aug 2013 17:30:56 -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   : e6d3f5b35edad5452936bf4842167fa00c8b64b8    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 21 Aug 2013 13:38:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 21 Aug 2013 13:38:20 -0400    

We should account for the per-group hashtable entry overhead when  
considering whether to use a hash aggregate to implement DISTINCT.  The  
comparable logic in choose_hashed_grouping() gets this right, but I think  
I omitted it here in the mistaken belief that there would be no overhead  
if there were no aggregate functions to be evaluated.  This can result in  
more than 2X underestimate of the hash table size, if the tuples being  
aggregated aren't very wide.  Per report from Tomas Vondra.  
  
This bug is of long standing, but per discussion we'll only back-patch into  
9.3.  Changing the estimation behavior in stable branches seems to carry too  
much risk of destabilizing plan choices for already-tuned applications.  

commit   : c9d7c192c06d0dd998067494c3be291ea6a52745    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 20 Aug 2013 09:39:00 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 20 Aug 2013 09:39:00 -0400    

Backpatch to 9.3.  
  
Pavel Stehule  

commit   : ce52c6fe243665e0f4d84414f9341b9719415551    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 19 Aug 2013 19:45:10 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 19 Aug 2013 19:45:10 -0400    

commit   : 59bc4a43ec588d25fe976774bd1194f1b90251fa    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 19 Aug 2013 19:36:06 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 19 Aug 2013 19:36:06 -0400    

sscanf isn't the easiest thing to use for exact pattern checks ...  
also, don't use strncmp where strcmp will do.  

commit   : db5b49cdd4f481828b227f03b373fbc9bde4301a    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 19 Aug 2013 17:48:17 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 19 Aug 2013 17:48:17 -0400    

Instead of deleting all files in stats_temp_directory and the permanent  
directory on a crash, only remove those files that match the pattern of  
files we actually write in them, to avoid possibly clobbering existing  
unrelated contents of the temporary directory.  Per complaint from Jeff  
Janes, and subsequent discussion, starting at message  
CAMkU[email protected]  
  
Also, fix a bug in the same routine to avoid removing files from the  
permanent directory twice (instead of once from that directory and then  
from the temporary directory), also per report from Jeff Janes, in  
message  
CAMk[email protected]  

commit   : 38c69237c21186038f6902373a0f06af1c2f7cfb    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 19 Aug 2013 20:57:53 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 19 Aug 2013 20:57:53 +0300    

This keeps the usual trigger file name unchanged from 9.2, avoiding nasty  
issues if you use a pre-9.3 pg_ctl binary with a 9.3 server or vice versa.  
The fallback behavior of creating a full checkpoint before starting up is now  
triggered by a file called "fallback_promote". That can be useful for  
debugging purposes, but we don't expect any users to have to resort to that  
and we might want to remove that in the future, which is why the fallback  
mechanism is undocumented.  

commit   : b19e5a696ab28be5d55949048194922152091aa1    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 19 Aug 2013 13:19:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 19 Aug 2013 13:19:28 -0400    

In an example such as  
SELECT * FROM  
  i LEFT JOIN LATERAL (SELECT * FROM j WHERE i.n = j.n) j ON true;  
it is safe to pull up the LATERAL subquery into its parent, but we must  
then treat the "i.n = j.n" clause as a qual clause of the LEFT JOIN.  The  
previous coding in deconstruct_recurse mistakenly labeled the clause as  
"is_pushed_down", resulting in wrong semantics if the clause were applied  
at the join node, as per an example submitted awhile ago by Jeremy Evans.  
To fix, postpone processing of such clauses until we return back up to  
the appropriate recursion depth in deconstruct_recurse.  
  
In addition, tighten the is-safe-to-pull-up checks in is_simple_subquery;  
we previously missed the possibility that the LATERAL subquery might itself  
contain an outer join that makes lateral references in lower quals unsafe.  
  
A regression test case equivalent to Jeremy's example was already in my  
commit of yesterday, but was giving the wrong results because of this  
bug.  This patch fixes the expected output for that, and also adds a  
test case for the second problem.  

commit   : b3c55ae0daf230555cb1932ac2c903c3fe7643db    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 19 Aug 2013 12:33:07 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 19 Aug 2013 12:33:07 -0400    

When upgrading from servers of versions 9.2 and older, and MultiXactIds  
have been used in the old server beyond the first page (that is, 2048  
multis or more in the default 8kB-page build), pg_upgrade would set the  
next multixact offset to use beyond what has been allocated in the new  
cluster.  This would cause a failure the first time the new cluster  
needs to use this value, because the pg_multixact/offsets/ file wouldn't  
exist or wouldn't be large enough.  To fix, ensure that the transient  
server instances launched by pg_upgrade extend the file as necessary.  
  
Per report from Jesse Denardo in  
CANi[email protected]  

commit   : 064eb5098be5ee74a9dfb6bf090fea699a1be45f    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 19 Aug 2013 12:26:22 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 19 Aug 2013 12:26:22 -0400    

Etsuro Fujita  

commit   : 3e5dd599666f00b45311e42433ba68d0b9b89aed    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 18 Aug 2013 23:36:20 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 18 Aug 2013 23:36:20 -0400    

commit   : 5a91ea7a000295a7898f96cad6f0c3c288d41039    
  
author   : Kevin Grittner <[email protected]>    
date     : Sun, 18 Aug 2013 16:24:59 -0500    
  
committer: Kevin Grittner <[email protected]>    
date     : Sun, 18 Aug 2013 16:24:59 -0500    

This was added as part of the attempt to support unlogged matviews  
along with a populated status.  It got missed when unlogged  
support was removed pre-commit.  
  
Noticed by Noah Misch.  Back-patched to 9.3 branch.  

commit   : 7c8de5d3e587a31279771f32291a5d4b94bd2514    
  
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   : 8820b502367de2669a8d3ed02a1cc485dd84fc4b    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 17 Aug 2013 20:36:29 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 17 Aug 2013 20:36:29 -0400    

commit   : 517db4945560358a82b9152d01cfad3bbd2af17e    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 17 Aug 2013 20:22:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 17 Aug 2013 20:22:41 -0400    

The planner largely failed to consider the possibility that a  
PlaceHolderVar's expression might contain a lateral reference to a Var  
coming from somewhere outside the PHV's syntactic scope.  We had a previous  
report of a problem in this area, which I tried to fix in a quick-hack way  
in commit 4da6439bd8553059766011e2a42c6e39df08717f, but Antonin Houska  
pointed out that there were still some problems, and investigation turned  
up other issues.  This patch largely reverts that commit in favor of a more  
thoroughly thought-through solution.  The new theory is that a PHV's  
ph_eval_at level cannot be higher than its original syntactic level.  If it  
contains lateral references, those don't change the ph_eval_at level, but  
rather they create a lateral-reference requirement for the ph_eval_at join  
relation.  The code in joinpath.c needs to handle that.  
  
Another issue is that createplan.c wasn't handling nested PlaceHolderVars  
properly.  
  
In passing, push knowledge of lateral-reference checks for join clauses  
into join_clause_is_movable_to.  This is mainly so that FDWs don't need  
to deal with it.  
  
This patch doesn't fix the original join-qual-placement problem reported by  
Jeremy Evans (and indeed, one of the new regression test cases shows the  
wrong answer because of that).  But the PlaceHolderVar problems need to be  
fixed before that issue can be addressed, so committing this separately  
seems reasonable.  

commit   : 2505aaed7be290018f999f6e9250c24b26db97d0    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2013 18:01:04 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2013 18:01:04 -0400    

Backpatch to 9.3.  

commit   : c359ff298a537f9f481ca7928c655b84c17e5456    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2013 16:54:18 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2013 16:54:18 -0400    

Backpatch to 9.3, of course.  

commit   : 8e2eca46dbd3bb8efa56ef0aebd60eadcbcc5dd4    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 16 Aug 2013 15:28:03 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 16 Aug 2013 15:28:03 -0400    

Commit 2dee7998f93062e2ae7fcc9048ff170e528d1724 renames these  
functions in master, for consistency; per discussion, backport  
just the renaming portion of that commit to 9.3 to keep the  
branches in sync.  
  
Michael Paquier  

commit   : ae3c8c57cbaa8d88be61dc26f7b5c138c3c98dd7    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2013 11:09:09 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 16 Aug 2013 11:09:09 -0400    

Register atexit() server shutdown if pg_ctl successfully started the  
server, but we can't connect to it.  
  
Backpatch to 9.3.  
  
Pavel Raiskup  

commit   : cdcddc4a5a06952eafc65907c25c21510c7d54c0    
  
author   : Kevin Grittner <[email protected]>    
date     : Thu, 15 Aug 2013 13:16:45 -0500    
  
committer: Kevin Grittner <[email protected]>    
date     : Thu, 15 Aug 2013 13:16:45 -0500    

Was accidentally allowed, but not documented and lacked support  
for rename or drop once created.  
  
Per report from Noah Misch.  

commit   : d2fa20acdd67db00b48fcc4b9a13b998c1c8bb54    
  
author   : Magnus Hagander <[email protected]>    
date     : Thu, 15 Aug 2013 18:24:25 +0200    
  
committer: Magnus Hagander <[email protected]>    
date     : Thu, 15 Aug 2013 18:24:25 +0200    

commit   : 3ed990b6ffe18e794b5020a5e5e841aacd72524e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 14 Aug 2013 23:18:49 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 14 Aug 2013 23:18:49 -0400    

Timeline IDs are unsigned ints everywhere, except the replication parser  
treated them as signed ints.  

commit   : 9e3f42ff3f6af6b4474340175572c76fe35d9e3b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 14 Aug 2013 23:00:34 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 14 Aug 2013 23:00:34 -0400    

Avoid using the term "updatable" in confusing ways.  Suggest a trigger  
first, before a rule.  

commit   : 6c5f68ea1a836f8c5cf9711f24d285067e67f23f    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 14 Aug 2013 18:38:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 14 Aug 2013 18:38:36 -0400    

The planner logic that attempted to make a preliminary estimate of the  
ph_needed levels for PlaceHolderVars seems to be completely broken by  
lateral references.  Fortunately, the potential join order optimization  
that this code supported seems to be of relatively little value in  
practice; so let's just get rid of it rather than trying to fix it.  
  
Getting rid of this allows fairly substantial simplifications in  
placeholder.c, too, so planning in such cases should be a bit faster.  
  
Issue noted while pursuing bugs reported by Jeremy Evans and Antonin  
Houska, though this doesn't in itself fix either of their reported cases.  
What this does do is prevent an Assert crash in the kind of query  
illustrated by the added regression test.  (I'm not sure that the plan for  
that query is stable enough across platforms to be usable as a regression  
test output ... but we'll soon find out from the buildfarm.)  
  
Back-patch to 9.3.  The problem case can't arise without LATERAL, so  
no need to touch older branches.  

commit   : 85052376a8cc4bbbfc08a50ca3bd137c1e3cda9a    
  
author   : Kevin Grittner <[email protected]>    
date     : Wed, 14 Aug 2013 12:43:01 -0500    
  
committer: Kevin Grittner <[email protected]>    
date     : Wed, 14 Aug 2013 12:43:01 -0500    

We don't want to prevent an extension which creates a matview from  
being installed in pg_catalog.  
  
Issue was raised by Hitoshi Harada.  
Backpatched to 9.3.  

commit   : 6d8186ff779fd46f0251eb252e7489fd38ab793b    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 13 Aug 2013 15:24:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 13 Aug 2013 15:24:56 -0400    

We've seen multiple cases of people looking at the postmaster's original  
stderr output to try to diagnose problems, not realizing/remembering that  
their logging configuration is set up to send log messages somewhere else.  
This seems particularly likely to happen in prepackaged distributions,  
since many packagers patch the code to change the factory-standard logging  
configuration to something more in line with their platform conventions.  
  
In hopes of reducing confusion, emit a LOG message about this at the point  
in startup where we are about to switch log output away from the original  
stderr, providing a pointer to where to look instead.  This message will  
appear as the last thing in the original stderr output.  (We might later  
also try to emit such link messages when logging parameters are changed  
on-the-fly; but that case seems to be both noticeably harder to do nicely,  
and much less frequently a problem in practice.)  
  
Per discussion, back-patch to 9.3 but not further.  

commit   : 7cf5540c831460476d24566845422b8c81bd6581    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 13 Aug 2013 12:51:26 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 13 Aug 2013 12:51:26 -0400    

Move item about foreign data wrappers supporting inserts/updates/deletes  
to object manipulation.  
  
Backpatch to 9.3.  
  
From Etsuro Fujita  

commit   : 7f288a23484971dca7f75d866d0f1edb332fbc4b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 11 Aug 2013 09:17:04 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 11 Aug 2013 09:17:04 -0400    

Similar to 2cfb1c6f77734db81b6e74bcae630f93b94f69be, the order in which  
dictionary elements are printed is not reliable.  This reappeared in the  
tests of the string representation of result objects.  Reduce the test  
case to one result set column so that there is no question of order.  

commit   : 2edaee01129f3494be71c7bbc7e5414ae0c37501    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 9 Aug 2013 21:46:13 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 9 Aug 2013 21:46:13 -0400    

commit   : 95b5f5e1e75b22b1aa741b7545435d2af16f78d5    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 9 Aug 2013 19:25:51 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 9 Aug 2013 19:25:51 -0400    

commit   : 646cbc1f01b3104fb8e9ad68ea4df16bd9b4e16f    
  
author   : Fujii Masao <[email protected]>    
date     : Fri, 9 Aug 2013 22:14:26 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Fri, 9 Aug 2013 22:14:26 +0900    

commit   : 595f52f8171e9805c5753510a180faeb68165055    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 9 Aug 2013 07:59:53 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 9 Aug 2013 07:59:53 -0400    

commit   : 92d003fcbfb73eebf0c1782dbd53c6e2f14d5cc4    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 7 Aug 2013 22:48:40 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 7 Aug 2013 22:48:40 -0400    

commit   : b5a20ab3e0310103ff11337faeed3c521f5eb917    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 3 Aug 2013 12:39:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 3 Aug 2013 12:39:51 -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   : 69fdc9577b09dce732153c33c2484dac7d506ad9    
  
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   : 0009462e985b90d07dc430bb3c4f1e6f57e0c318    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 2 Aug 2013 12:49:03 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 2 Aug 2013 12:49:03 -0400    

My tweak of these error messages in commit c359a1b082 contained the  
thinko that a query would always have rowMarks set for a query  
containing a locking clause.  Not so: when declaring a cursor, for  
instance, rowMarks isn't set at the point we're checking, so we'd be  
dereferencing a NULL pointer.  
  
The fix is to pass the lock strength to the function raising the error,  
instead of trying to reverse-engineer it.  The result not only is more  
robust, but it also seems cleaner overall.  
  
Per report from Robert Haas.  

commit   : 820739cba95622033527f60467a264db0ee91f76    
  
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   : 55754380f36d098551bd55dd49e27f64dd1c8d2f    
  
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   : 603c4a90c15f601ccf44cad3d3b04b39e4dc34eb    
  
author   : Alvaro Herrera <[email protected]>    
date     : Wed, 31 Jul 2013 17:57:15 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Wed, 31 Jul 2013 17:57:15 -0400    

Per Coverity  

commit   : 5d9951a65037fe2b7bdca8ed20c8775594672e34    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 31 Jul 2013 11:31:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 31 Jul 2013 11:31:26 -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   : fe136ba6fc31760efe7ac53e662395a71a92dc03    
  
author   : Fujii Masao <[email protected]>    
date     : Wed, 31 Jul 2013 22:36:39 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Wed, 31 Jul 2013 22:36:39 +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   : 9a78f66fdccbc85442f992f2928b4a58ae451208    
  
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   : e243e3a42887f82be6dc5a6bf6e8534a733b8bc8    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 30 Jul 2013 09:23:31 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 30 Jul 2013 09:23:31 -0400    

commit   : 8cbf8dfcaf9972b723dc48359df5be0a364b2e5f    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 29 Jul 2013 10:42:41 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 29 Jul 2013 10:42:41 -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   : faee8f1a714f24e85ba5fa1018b22f9681b5d657    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 28 Jul 2013 06:59:09 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 28 Jul 2013 06:59:09 -0400    

commit   : d83940a7f60f48292b3ae58dfda81b146eab1c50    
  
author   : Bruce Momjian <[email protected]>    
date     : Sat, 27 Jul 2013 15:00:58 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sat, 27 Jul 2013 15:00:58 -0400    

commit   : 61edd524017c4a3fa5f35e72e49f70f058be7a99    
  
author   : Bruce Momjian <[email protected]>    
date     : Fri, 26 Jul 2013 13:52:01 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Fri, 26 Jul 2013 13:52:01 -0400    

commit   : 89bb2c76e4fec135df19e0d4e3135a3cf7a44a8a    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2013 16:45:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2013 16:45:47 -0400    

plpgsql often just remembers SPI-result tuple tables in local variables,  
and has no mechanism for freeing them if an ereport(ERROR) causes an escape  
out of the execution function whose local variable it is.  In the original  
coding, that wasn't a problem because the tuple table would be cleaned up  
when the function's SPI context went away during transaction abort.  
However, once plpgsql grew the ability to trap exceptions, repeated  
trapping of errors within a function could result in significant  
intra-function-call memory leakage, as illustrated in bug #8279 from  
Chad Wagner.  
  
We could fix this locally in plpgsql with a bunch of PG_TRY/PG_CATCH  
coding, but that would be tedious, probably slow, and prone to bugs of  
omission; moreover it would do nothing for similar risks elsewhere.  
What seems like a better plan is to make SPI itself responsible for  
freeing tuple tables at subtransaction abort.  This patch attacks the  
problem that way, keeping a list of live tuple tables within each SPI  
function context.  Currently, such freeing is automatic for tuple tables  
made within the failed subtransaction.  We might later add a SPI call to  
mark a tuple table as not to be freed this way, allowing callers to opt  
out; but until someone exhibits a clear use-case for such behavior, it  
doesn't seem worth bothering.  
  
A very useful side-effect of this change is that SPI_freetuptable() can  
now defend itself against bad calls, such as duplicate free requests;  
this should make things more robust in many places.  (In particular,  
this reduces the risks involved if a third-party extension contains  
now-redundant SPI_freetuptable() calls in error cleanup code.)  
  
Even though the leakage problem is of long standing, it seems imprudent  
to back-patch this into stable branches, since it does represent an API  
semantics change for SPI users.  We'll patch this in 9.3, but live with  
the leakage in older branches.  

commit   : 7f0bc6b448e70f18b9ff35be3a90444542d09d08    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2013 11:39:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 25 Jul 2013 11:39:11 -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   : 830d0e0edd73c015ca07423c402a3b1f79118d8f    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 25 Jul 2013 11:33:14 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 25 Jul 2013 11:33:14 -0400    

commit   : b48f1dc2d35279b0814d60c24e488df2c295bb85    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 24 Jul 2013 22:01:14 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 24 Jul 2013 22:01:14 -0400    

commit   : cf707aa70da6729a00593c49d5eb8a35ab27dd11    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 24 Jul 2013 17:42:03 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 24 Jul 2013 17:42:03 -0400    

Previously one had to use slist_delete(), implying an additional scan of  
the list, making this infrastructure considerably less efficient than  
traditional Lists when deletion of element(s) in a long list is needed.  
Modify the slist_foreach_modify() macro to support deleting the current  
element in O(1) time, by keeping a "prev" pointer in addition to "cur"  
and "next".  Although this makes iteration with this macro a bit slower,  
no real harm is done, since in any scenario where you're not going to  
delete the current list element you might as well just use slist_foreach  
instead.  Improve the comments about when to use each macro.  
  
Back-patch to 9.3 so that we'll have consistent semantics in all branches  
that provide ilist.h.  Note this is an ABI break for callers of  
slist_foreach_modify().  
  
Andres Freund and Tom Lane  

commit   : 4a67a9ac13495d69b4d3b560b63cafda9318b4f4    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 24 Jul 2013 13:15:47 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 24 Jul 2013 13:15:47 -0400    

commit   : 38afb907afccb4fac10f367a77c421172c04685d    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 24 Jul 2013 10:00:37 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 24 Jul 2013 10:00:37 -0400    

commit   : 808d1f8122223a19d7796e2b50878b1b42450263    
  
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   : 7f5cfe914de49130d86b2e1e9636b7135e577ef1    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 23 Jul 2013 17:54:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 23 Jul 2013 17:54:24 -0400    

After further thought about implicit coercions appearing in a joinaliasvars  
list, I realized that they represent an additional reason why we might need  
to reference the join output column directly instead of referencing an  
underlying column.  Consider SELECT x FROM t1 LEFT JOIN t2 USING (x) where  
t1.x is of type date while t2.x is of type timestamptz.  The merged output  
variable is of type timestamptz, but it won't go to null when t2 does,  
therefore neither t1.x nor t2.x is a valid substitute reference.  
  
The code in get_variable() actually gets this case right, since it knows  
it shouldn't look through a coercion, but we failed to ensure that the  
unqualified output column name would be globally unique.  To fix, modify  
the code that trawls for a dangerous situation so that it actually scans  
through an unnamed join's joinaliasvars list to see if there are any  
non-simple-Var entries.  

commit   : 5ef42547c3c55a0d743ea3fabe165ce3bcc3d3c8    
  
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   : b81d0691b9c6cc249511b92bb4b96f3a99a91eb0    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 23 Jul 2013 16:23:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 23 Jul 2013 16:23:04 -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   : 5712eeb2e7cf8e4236acffd4a403e7f14a48866f    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 23 Jul 2013 14:03:09 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 23 Jul 2013 14:03:09 -0400    

In commit 0ac5ad5134 I changed some error messages from "FOR  
UPDATE/SHARE" to a rather long gobbledygook which nobody liked.  Then,  
in commit cb9b66d31 I changed them again, but the alternative chosen  
there was deemed suboptimal by Peter Eisentraut, who in message  
13739[email protected] proposed an alternative  
involving a dynamically-constructed string based on the actual locking  
strength specified in the SQL command.  This patch implements that  
suggestion.  

commit   : 026bc46da33ab6a6f720b0d0500e8a95d075ab92    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 22 Jul 2013 15:41:44 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 22 Jul 2013 15:41:44 -0400    

Commit 7f7485a0cde92aa4ba235a1ffe4dda0ca0b6cc9a made these changes  
in master; per discussion, backport the API changes (but not the  
functional changes), so that people don't get used to the 9.3 API  
only to see it get broken in the next release.  There are already  
some people coding to the original 9.3 API, and this will cause  
minor breakage, but there will be even more if we wait until next  
year to roll out these changes.  

commit   : 295f9bbf1d2d1e985471bd523c7c9bfd3d134759    
  
author   : Robert Haas <[email protected]>    
date     : Mon, 22 Jul 2013 14:13:00 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Mon, 22 Jul 2013 14:13:00 -0400    

Per discussion on pgsql-hackers, these aren't really needed.  Interim  
versions of the background worker patch had the worker starting with  
signals already unblocked, which would have made this necessary.  
But the final version does not, so we don't really need it; and it  
doesn't work well with the new facility for starting dynamic background  
workers, so just rip it out.  
  
Also per discussion on pgsql-hackers, back-patch this change to 9.3.  
It's best to get the API break out of the way before we do an  
official release of this facility, to avoid more pain for extension  
authors later.  

commit   : 15b9bdf4d46e5b2858c7666dd4a39040aa12e668    
  
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   : ef8321a57d38c00592614a6d8f0872a721d301c3    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 20 Jul 2013 06:38:31 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 20 Jul 2013 06:38:31 -0400    

The new JSON API uses a bit of an unusual typedef scheme, where for  
example OkeysState is a pointer to okeysState.  And that's not applied  
consistently either.  Change that to the more usual PostgreSQL style  
where struct typedefs are upper case, and use pointers explicitly.  

commit   : 0b3859f3b607b375cfabb0a95bb4c58a4c1b37ee    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 19 Jul 2013 18:35:07 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 19 Jul 2013 18:35:07 -0400    

By using only the macro that checks infomask bits  
HEAP_XMAX_IS_LOCKED_ONLY to verify whether a multixact is not an  
updater, and not the full HeapTupleHeaderIsOnlyLocked, it would come to  
the wrong result in case of a multixact containing an aborted update;  
therefore returning the wrong result code.  This would cause predicate.c  
to break completely (as in bug report #8273 from David Leverton), and  
certain index builds would misbehave.  As far as I can tell, other  
callers of the bogus routine would make harmless mistakes or not be  
affected by the difference at all; so this was a pretty narrow case.  
  
Also, no other user of the HEAP_XMAX_IS_LOCKED_ONLY macro is as  
careless; they all check specifically for the HEAP_XMAX_IS_MULTI case,  
and they all verify whether the updater is InvalidXid before concluding  
that it's a valid updater.  So there doesn't seem to be any similar bug.  

commit   : a9f8fe06bc38c9eb3e99191590713de903a91cfa    
  
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   : 24780e00d2bb10c6942edf579b60186ec469c77b    
  
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   : f8463fba2434d083bb699d1cc8a7d7159d614a7b    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 18 Jul 2013 21:22:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 18 Jul 2013 21:22:43 -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   : dd8ea2eb5e996f3f3dfd928e20aa2462c4bd9c63    
  
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   : bdbb1d673834ef7af16d97158d9d0006b17949f7    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 15 Jul 2013 20:04:14 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 15 Jul 2013 20:04:14 -0400    

The returned error message already includes a newline, but the callers  
were adding their own when printing it out.  

commit   : 22b7f5c5aa1dc2909e110b171b03d6e0c85dcd43    
  
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   : 8126bfb5b5f0b413455edd23ff3bf08d83f1cddc    
  
author   : Stephen Frost <[email protected]>    
date     : Sun, 14 Jul 2013 21:17:59 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Sun, 14 Jul 2013 21:17:59 -0400    

In pg_dump.c:getEventTriggers, check what major version we are on  
before calling createPQExpBuffer() to avoid leaking that bit of  
memory.  
  
Leak discovered by the Coverity scanner.  
  
Back-patch to 9.3 where support for dumping event triggers was  
added.  

commit   : b68a1fc7ff1a50a7282e8edff7c51333274c3334    
  
author   : Stephen Frost <[email protected]>    
date     : Sun, 14 Jul 2013 17:25:47 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Sun, 14 Jul 2013 17:25:47 -0400    

In receivelog.c:writeTimeLineHistoryFile(), we were not properly  
closing the open'd file descriptor in error cases.  While this  
wouldn't matter much if we were about to exit due to such an  
error, that's not the case with pg_receivexlog as it can be a  
long-running process and these errors are non-fatal.  
  
This resource leak was found by the Coverity scanner.  
  
Back-patch to 9.3 where this issue first appeared.  

commit   : e9010b992640d1dbf212cbbab40a00093515f16f    
  
author   : Stephen Frost <[email protected]>    
date     : Sun, 14 Jul 2013 16:42:58 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Sun, 14 Jul 2013 16:42:58 -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   : 5ab811106b58b06242047ee5dc69001bc983c3a1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 14 Jul 2013 15:53:56 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 14 Jul 2013 15:53:56 -0400    

commit   : f5acde9380e164eab10b2dc3281bb1c07f690803    
  
author   : Stephen Frost <[email protected]>    
date     : Sun, 14 Jul 2013 15:31:23 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Sun, 14 Jul 2013 15:31:23 -0400    

In streamutil.c:GetConnection(), upgrade failure to parse the  
connection string to an exit(1) instead of simply returning NULL.  
Most callers already immediately exited, but pg_receivexlog would  
loop on this case, continually trying to re-parse the connection  
string (which can't be changed after pg_receivexlog has started).  
  
GetConnection() was already expected to exit(1) in some cases  
(eg: failure to allocate memory or if unable to determine the  
integer_datetimes flag), so this change shouldn't surprise anyone.  
  
Began looking at this due to the Coverity scanner complaining that  
we were leaking err_msg in this case- no longer an issue since we  
just exit(1) immediately.  

commit   : 8839e7362c68470f8db66acdfa60b95a1c5312cf    
  
author   : Stephen Frost <[email protected]>    
date     : Sun, 14 Jul 2013 14:35:26 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Sun, 14 Jul 2013 14:35:26 -0400    

The command strings read by the child processes during parallel  
pg_dump, after being read and handled, were not being free'd.  
This patch corrects this relatively minor memory leak.  
  
Leak found by the Coverity scanner.  
  
Back patch to 9.3 where parallel pg_dump was introduced.  

commit   : fb7c0ac42e1a8e3cde74e83e2c758ada8c62a35e    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 12 Jul 2013 18:21:22 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 12 Jul 2013 18:21:22 -0400    

This makes superuser-issued REFRESH MATERIALIZED VIEW safe regardless of  
the object's provenance.  REINDEX is an earlier example of this pattern.  
As a downside, functions called from materialized views must tolerate  
running in a security-restricted operation.  CREATE MATERIALIZED VIEW  
need not change user ID.  Nonetheless, avoid creation of materialized  
views that will invariably fail REFRESH by making it, too, start a  
security-restricted operation.  
  
Back-patch to 9.3 so materialized views have this from the beginning.  
  
Reviewed by Kevin Grittner.  

commit   : 7484f89daa33477e0027a86ae772f44fa99224ed    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 11 Jul 2013 21:48:09 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 11 Jul 2013 21:48:09 -0400    

commit   : 02e61a8488de1ac559306db888901f8fa6db0755    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 11 Jul 2013 09:43:19 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 11 Jul 2013 09:43:19 -0400    

commit   : 583435d079767a73e1e7581bc354387c49e208ad    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 10 Jul 2013 22:40:41 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 10 Jul 2013 22:40:41 -0400    

From: Ian Lawrence Barwick <[email protected]>  

commit   : bf470b37cc7c9e018e9f789996ef45e35b442487    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 9 Jul 2013 20:49:44 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 9 Jul 2013 20:49:44 -0400    

commit   : d0450f1fa60e1d3485e7ec52bdc5e51a03b00cfa    
  
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   : 469feb7afb5ee9958c50a8b3000df027a1be8e19    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 8 Jul 2013 17:11:55 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 8 Jul 2013 17:11:55 -0400    

It's htup_details.h now.  
  
Jeff Janes  

commit   : 8b6191e1d5e48d521c42d5f6bdbf8413874f7206    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 7 Jul 2013 22:37:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 7 Jul 2013 22:37:28 -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   : 95b4e8761e3aac9d27c59b89eb3ca5c90d93f9da    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 7 Jul 2013 16:01:29 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 7 Jul 2013 16:01:29 -0400    

commit   : 8ca0e6870c4534f3cc36899f613928b5557c22be    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 7 Jul 2013 15:56:23 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 7 Jul 2013 15:56:23 -0400    

Use "MXID" as placeholder for -m option, instead of just "XID".  

commit   : bf8d8ddc08b9573d1b6ed2ef24c83db5fef18d8c    
  
author   : Bruce Momjian <[email protected]>    
date     : Sun, 7 Jul 2013 15:57:24 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Sun, 7 Jul 2013 15:57:24 -0400    

commit   : 9f8830dbe203e1dde3e8aea594e4a23577e4d340    
  
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   : 7428a260f6ad32f3f02a98842f6f09fd8092d393    
  
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   : e407192c937d993be1a4f5636a1afa57cf492f6f    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 6 Jul 2013 11:16:53 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 6 Jul 2013 11:16:53 -0400    

Commit 31a891857a128828d47d93c63e041f3b69cbab70 added some tests in  
plpgsql.sql that used a function rather unthinkingly named "foo()".  
However, rangefuncs.sql has some much older tests that create a function  
of that name, and since these test scripts run in parallel, there is a  
chance of failures if the timing is just right.  Use another name to  
avoid that.  Per buildfarm (failure seen today on "hamerkop", but  
probably it's happened before and not been noticed).  

commit   : 7d114fb46fd2b88cfab05f8e36ba9e9762cd576a    
  
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   : cf183732d2b2bda2f6fd927481f787ecb1f054fa    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 5 Jul 2013 15:25:51 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 5 Jul 2013 15:25:51 -0400    

All instances of the verbiage lagging the code.  Back-patch to 9.3,  
where materialized views were introduced.  

commit   : 462b562ab294dc15d6a578ebf424020f0a54e835    
  
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   : 8b4c798973033156db58dbca3b605e1045cc587d    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 4 Jul 2013 11:33:08 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 4 Jul 2013 11:33:08 -0400    

commit   : cdaf7bde971b592839cbc3794ead1740d1a2125a    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 4 Jul 2013 11:11:56 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 4 Jul 2013 11:11:56 -0400    

BGWORKER_BACKEND_DATABASE_CONNECTION can only be used if  
BGWORKER_SHMEM_ACCESS is also used.  
  
Michael Paquier, with some tweaks by me.  

commit   : f960fae017635a8c212ccd2168f091ea73564150    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 4 Jul 2013 10:27:33 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 4 Jul 2013 10:27:33 -0400    

From: Dimitri Fontaine <[email protected]>  

commit   : 775a9f3025b16dcc9804cca82e744f41e1523a6e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 3 Jul 2013 21:06:20 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 3 Jul 2013 21:06:20 -0400    

From: Dimitri Fontaine <[email protected]>  

commit   : d3cc1b2ff087cd68f281dad33743640dffbe01d1    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 3 Jul 2013 14:25:06 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 3 Jul 2013 14:25:06 -0400    

commit   : 654b702a1c01fa047a363a887f957886503ea67c    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 3 Jul 2013 12:26:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 3 Jul 2013 12:26:33 -0400    

An INSERT into such a view should work just like an INSERT into its base  
table, ie the insertion should go directly into that table ... not be  
duplicated into each child table, as was happening before, per bug #8275  
from Rushabh Lathia.  On the other hand, the current behavior for  
UPDATE/DELETE seems reasonable: the update/delete traverses the child  
tables, or not, depending on whether the view specifies ONLY or not.  
Add some regression tests covering this area.  
  
Dean Rasheed  

commit   : c21bb48d6fc1827e117e2667e0a5d9d96d984f46    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 3 Jul 2013 07:29:23 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 3 Jul 2013 07:29:23 -0400    

Specifically, permit attaching them to the error in RAISE and retrieving  
them from a caught error in GET STACKED DIAGNOSTICS.  RAISE enforces  
nothing about the content of the fields; for its purposes, they are just  
additional string fields.  Consequently, clarify in the protocol and  
libpq documentation that the usual relationships between error fields,  
like a schema name appearing wherever a table name appears, are not  
universal.  This freedom has other applications; consider a FDW  
propagating an error from an RDBMS having no schema support.  
  
Back-patch to 9.3, where core support for the error fields was  
introduced.  This prevents the confusion of having a release where libpq  
exposes the fields and PL/pgSQL does not.  
  
Pavel Stehule, lexical revisions by Noah Misch.  

commit   : a74a977fb0ea535aeae06fe67ee1f9491c30b619    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 2 Jul 2013 20:32:09 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 2 Jul 2013 20:32:09 -0400    

The web site is dead, and the Wayback Machine shows that it didn't have  
much useful content before.  

commit   : 7f3cd29f8f2bd447a34748afa6dedeeba5d463db    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 2 Jul 2013 20:12:58 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 2 Jul 2013 20:12:58 -0400    

commit   : 061c7a3c7adbf366707dd4c7fdfdb606d00b0dd7    
  
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   : ae8fc624066398b8a14a97c5f950ddc844657d24    
  
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   : 4d6ae6aaec5744f734735b9ab8acf29a4e97f151    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 1 Jul 2013 14:52:56 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 1 Jul 2013 14:52:56 -0400    

commit   : 95ffbce9a197a434bc1d5bd42268f05d3bfa8168    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sun, 30 Jun 2013 10:25:43 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sun, 30 Jun 2013 10:25:43 -0400    

C++ is more picky about comparing signed and unsigned integers.  

commit   : 452d0c21825dd52c10af4538d850991bf6a00e38    
  
author   : Simon Riggs <[email protected]>    
date     : Sat, 29 Jun 2013 00:57:25 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Sat, 29 Jun 2013 00:57:25 +0100    

Set errcode to ERRCODE_LOCK_NOT_AVAILABLE  
  
Zoltán Bsöszörményi  

commit   : 5e1ed63ac2ccb3d8e605ce2e428816c8487fe683    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 27 Jun 2013 15:31:04 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 27 Jun 2013 15:31:04 -0400    

I added some more functionality to it in 0ac5ad5134f27 but neglected to  
add it to the docs.  
  
Per Peter Eisentraut in message  
[email protected]  

commit   : deac50021beded05ab98f973b6a66a58e42a06f9    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 27 Jun 2013 15:20:33 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 27 Jun 2013 15:20:33 -0400    

I introduced these new fields in 0ac5ad5134f27 but neglected to add them  
to the system catalogs section of the docs.  
  
Per Thom Brown in message  
CAA-[email protected]  

commit   : fc469af248a32560f6959b4ed29dc38477ab0ab0    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 27 Jun 2013 13:54:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 27 Jun 2013 13:54:55 -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   : 0b173ced93ee7a0da0d38fa13926e7ec4925075e    
  
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   : 4b2deb72564a35c54c01323f91ca3a6be56b02bc    
  
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   : 40265e3446b0c037510bb05dfe80e4131e77b754    
  
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   : dc22b34f86a29d393c6407861a6865e88736c22c    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 25 Jun 2013 23:50:14 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 25 Jun 2013 23:50:14 -0400    

The code checking the WAL file name contained a logic error and wouldn't  
actually catch some bad names.  

commit   : cb687c751c8d2e9eb097339f8920ca8fcf29fc47    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 25 Jun 2013 16:36:29 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 25 Jun 2013 16:36:29 -0400    

Clang 3.3 correctly complains that a variable of type enum  
MultiXactStatus cannot hold a value of -1, which makes sense.  Change  
the declared type of the variable to int instead, and apply casting as  
necessary to avoid the warning.  
  
Per notice from Andres Freund  

commit   : a20d7c3bc3517e0c390a08d4f589fded953c9710    
  
author   : Andrew Dunstan <[email protected]>    
date     : Tue, 25 Jun 2013 13:46:10 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Tue, 25 Jun 2013 13:46:10 -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   : 0b958f3efcfcc3d9b0e39d550b705a28763bc9e2    
  
author   : Fujii Masao <[email protected]>    
date     : Wed, 26 Jun 2013 02:18:26 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Wed, 26 Jun 2013 02:18: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   : 09bd2acbe5ac866ce93d7c0e6ed90b426a576f1b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 24 Jun 2013 14:55:41 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 24 Jun 2013 14:55:41 -0400    

commit   : 060ffab6b9f3e684c3a36b74af7bff4c1cfc4bc2    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 24 Jun 2013 14:16:15 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 24 Jun 2013 14:16:15 -0400    

commit   : 7b2c9d682957418778dfb7217a536c5a99635a2b    
  
author   : Simon Riggs <[email protected]>    
date     : Sun, 23 Jun 2013 11:09:24 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Sun, 23 Jun 2013 11:09:24 +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   : 0b5a5c8e05e6ebc5923375b056885c6e9934ee31    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 21 Jun 2013 22:48:06 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 21 Jun 2013 22:48:06 -0400    

If there is no <date> element, the publication date for the EPUB  
manifest is taken from the copyright year.  But something like  
"1996-2013" is not a legal date specification.  So the EPUB output  
currently fails epubcheck.  
  
Put in a separate <date> element with the current year.  Put it in  
legal.sgml, because copyright.pl already instructs to update that  
manually, so it hopefully won't be missed.  

commit   : b3b2ea4ad799f5b0e9e0711d23a884102f2d9a66    
  
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   : 75555da10bbf9b8d7e4c8f509255331a7e20865b    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 18 Jun 2013 21:56:13 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 18 Jun 2013 21:56:13 -0400    

This maintains the logical grouping of the output better.  

commit   : 854ebd0f5fb069a6c96e14cff4965350fb5374a6    
  
author   : Kevin Grittner <[email protected]>    
date     : Wed, 19 Jun 2013 10:37:39 -0500    
  
committer: Kevin Grittner <[email protected]>    
date     : Wed, 19 Jun 2013 10:37:39 -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   : 0ae1bf8c1be7eccc54792a9c211345f97a11f78e    
  
author   : Simon Riggs <[email protected]>    
date     : Tue, 18 Jun 2013 12:10:10 +0100    
  
committer: Simon Riggs <[email protected]>    
date     : Tue, 18 Jun 2013 12:10:10 +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   : 7558c1c00a2195e9de88121e2af5119b609a8600    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 17 Jun 2013 21:53:33 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 17 Jun 2013 21:53:33 -0400    

commit   : 20723ce80121d99b07c93e5bb9b32b7e09d75231    
  
author   : Jeff Davis <[email protected]>    
date     : Mon, 17 Jun 2013 08:02:12 -0700    
  
committer: Jeff Davis <[email protected]>    
date     : Mon, 17 Jun 2013 08:02:12 -0700    

MarkBufferDirtyHint() writes WAL, and should know if it's got a  
standard buffer or not. Currently, the only callers where buffer_std  
is false are related to the FSM.  
  
In passing, rename XLOG_HINT to XLOG_FPI, which is more descriptive.  
  
Back-patch to 9.3.  

commit   : 7b5d712d08df978d7345a7bbf14786ce3879f317    
  
author   : Fujii Masao <[email protected]>    
date     : Sun, 16 Jun 2013 09:39:16 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Sun, 16 Jun 2013 09:39:16 +0900    

commit   : c38b64c2959662298f23ad5d86246009e7853b75    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 15 Jun 2013 16:22:29 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 15 Jun 2013 16:22:29 -0400    

This avoids platform-dependent behavior wherein pg_sleep() might fail to be  
interrupted by statement timeout, query cancel, SIGTERM, etc.  Also, since  
there's no reason to wake up once a second any more, we can reduce the  
power consumption of a sleeping backend a tad.  
  
Back-patch to 9.3, since use of SA_RESTART for SIGALRM makes this a bigger  
issue than it used to be.  

commit   : fc02d2b245e82a385785bb4a0f49d8b617680779    
  
author   : Fujii Masao <[email protected]>    
date     : Sun, 16 Jun 2013 05:12:39 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Sun, 16 Jun 2013 05:12:39 +0900    

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

commit   : 61f3ada319038e7597c81f7f454982852bf02de3    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 15 Jun 2013 15:39:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 15 Jun 2013 15:39:51 -0400    

The exclusion of SIGALRM dates back to Berkeley days, when Postgres used  
SIGALRM in only one very short stretch of code.  Nowadays, allowing it to  
interrupt kernel calls doesn't seem like a very good idea, since its use  
for statement_timeout means SIGALRM could occur anyplace in the code, and  
there are far too many call sites where we aren't prepared to deal with  
EINTR failures.  When third-party code is taken into consideration, it  
seems impossible that we ever could be fully EINTR-proof, so better to  
use SA_RESTART always and deal with the implications of that.  One such  
implication is that we should not assume pg_usleep() will be terminated  
early by a signal.  Therefore, long sleeps should probably be replaced  
by WaitLatch operations where practical.  
  
Back-patch to 9.3 so we can get some beta testing on this change.  

commit   : e472b921406407794bab911c64655b8b82375196    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 14 Jun 2013 14:26:43 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 14 Jun 2013 14:26:43 -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   : c62866eeafd52822ec61a0d2db9428c05e97d3cc    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2013 23:15:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2013 23:15:15 -0400    

elog.c has historically treated LOG messages as low-priority during  
bootstrap and standalone operation.  This has led to confusion and even  
masked a bug, because the normal expectation of code authors is that  
elog(LOG) will put something into the postmaster log, and that wasn't  
happening during initdb.  So get rid of the special-case rule and make  
the priority order the same as it is in normal operation.  To keep from  
cluttering initdb's output and the behavior of a standalone backend,  
tweak the severity level of three messages routinely issued by xlog.c  
during startup and shutdown so that they won't appear in these cases.  
Per my proposal back in December.  

commit   : f04216341dd1cc235e975f93ac806d9d3729a344    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2013 22:35:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2013 22:35:56 -0400    

pg_filedump and other external utility programs are likely to want to be  
able to check Postgres page checksums.  To avoid messy duplication of code,  
move the checksumming functionality into an exported header file, much as  
we did awhile back for the CRC code.  
  
In passing, get rid of an unportable assumption that a static char[] array  
will be word-aligned, and do some other minor code beautification.  

commit   : fa2fc066f34f1b631b5f92f11e7cda9f60a25330    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 13 Jun 2013 21:42:42 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 13 Jun 2013 21:42:42 -0400    

Memory was allocated based on the sizeof a type that was not the type of  
the pointer that the result was being assigned to.  The types happen to  
be of the same size, but it's still wrong.  

commit   : 629b3e96dd64fa081d8b4610c5a723ef68af09d7    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2013 13:11:29 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 13 Jun 2013 13:11:29 -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   : 66008564f8ce570f7ad6368fbde2138e946d328b    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 12 Jun 2013 19:51:12 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 12 Jun 2013 19:51:12 -0400    

Several loops in the JSON parser examined a byte in memory just before  
checking whether its address was in-bounds, so they could read one byte  
beyond the datum's allocation.  A SIGSEGV is possible.  New in 9.3, so  
no back-patch.  

commit   : 3a5d0c55338e6beb4c01ed5fadb1462e90db7545    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 12 Jun 2013 19:50:52 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 12 Jun 2013 19:50:52 -0400    

We would wrongly overwrite the prior stack byte if it happened to  
contain '\n' or '\r'.  New in 9.3, so no back-patch.  

commit   : 813895e4acfa646c6c0405a0a8c5d05637f42865    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 12 Jun 2013 19:50:37 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 12 Jun 2013 19:50:37 -0400    

Since the structure ends with a flexible array, doing so truncates any  
vector having more than one element.  New in 9.3, so no back-patch.  

commit   : fb435f40d5e34f85076a0af56b2f3bf7b86122b8    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 12 Jun 2013 19:50:14 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 12 Jun 2013 19:50:14 -0400    

Since commit f21bb9cfb5646e1793dcc9c0ea697bab99afa523, this function  
ignores the caller-provided length and loops until it finds a  
terminator, which GetVirtualXIDsDelayingChkpt() never adds.  Restore the  
previous loop control logic.  In passing, revert the addition of an  
unused variable by the same commit, presumably a debugging relic.  

commit   : ff53890f687c7f6b2a10db6661e9c32faf832636    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 12 Jun 2013 19:49:50 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 12 Jun 2013 19:49:50 -0400    

Consumers are entitled to read the full 64 bytes pertaining to a Name;  
using a shorter NULL-terminated string leads to reading beyond the end  
its allocation; a SIGSEGV is possible.  Use the frequent idiom of  
copying to a NameData on the stack.  New in 9.3, so no back-patch.  

commit   : dc3eb5638349e74a6628130a5101ce866455f4a3    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2013 17:52:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 12 Jun 2013 17:52:54 -0400    

Extend the FDW API (which we already changed for 9.3) so that an FDW can  
report whether specific foreign tables are insertable/updatable/deletable.  
The default assumption continues to be that they're updatable if the  
relevant executor callback function is supplied by the FDW, but finer  
granularity is now possible.  As a test case, add an "updatable" option to  
contrib/postgres_fdw.  
  
This patch also fixes the information_schema views, which previously did  
not think that foreign tables were ever updatable, and fixes  
view_is_auto_updatable() so that a view on a foreign table can be  
auto-updatable.  
  
initdb forced due to changes in information_schema views and the functions  
they rely on.  This is a bit unfortunate to do post-beta1, but if we don't  
change this now then we'll have another API break for FDWs when we do  
change it.  
  
Dean Rasheed, somewhat editorialized on by Tom Lane  

commit   : 78ed8e03c67d7333708f5c1873ec1d239ae2d7e0    
  
author   : Andrew Dunstan <[email protected]>    
date     : Wed, 12 Jun 2013 13:35:24 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Wed, 12 Jun 2013 13:35:24 -0400    

Per discussion  on -hackers. We treat Unicode escapes when unescaping  
them similarly to the way we treat them in PostgreSQL string literals.  
Escapes in the ASCII range are always accepted, no matter what the  
database encoding. Escapes for higher code points are only processed in  
UTF8 databases, and attempts to process them in other databases will  
result in an error. \u0000 is never unescaped, since it would result in  
an impermissible null byte.  

commit   : c1d729b419ee876c32ddf4ac3a85fa89a6b4a89b    
  
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   : e262755bfc97f31442cc0def8098b1a7d2913355    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 11 Jun 2013 17:26:42 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 11 Jun 2013 17:26:42 -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   : ecdec470e7a39316df185d387aeaeceab7155ada    
  
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   : 941c4ece98d08113b557bc8e7dbd8a9ac0ffac3e    
  
author   : Fujii Masao <[email protected]>    
date     : Tue, 11 Jun 2013 03:03:16 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Tue, 11 Jun 2013 03:03:16 +0900    

pg_isready displays the host name and the port number that it uses to connect  
to the server. So far, pg_isready didn't use the conninfo specified in -d option  
for calculating those host name and port number. This can lead to wrong display  
to a user. This commit changes pg_isready so that it uses the conninfo for that  
calculation.  
  
Original patch by Phil Sorber, modified by me.  

commit   : 33a4466f767be8b153ef1ef78433ad9b1867dab8    
  
author   : Joe Conway <[email protected]>    
date     : Sun, 9 Jun 2013 17:30:39 -0700    
  
committer: Joe Conway <[email protected]>    
date     : Sun, 9 Jun 2013 17:30:39 -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   : e0b451e43250558b3c1ac830e067b39e25e0e348    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 9 Jun 2013 19:41:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 9 Jun 2013 19:41:52 -0400    

Autovacuum occurring while the test runs could allow some of the inserts to  
go into recycled space, thus changing the output ordering of later queries.  
While we could complicate those queries to force sorting of their output  
rows, it doesn't seem like that would make the test better in any  
meaningful way, and conceivably it could hide unexpected diffs.  Instead,  
tweak the affected queries so that the inserted rows aren't updated by the  
following UPDATE.  Per buildfarm.  

commit   : a4424c57c3da52efa212b21521abff4bf129b19e    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 9 Jun 2013 18:39:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 9 Jun 2013 18:39:20 -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   : f3839ea117fba6fdb69c75a1fe145aa86a4c8ae3    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 9 Jun 2013 15:26:40 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 9 Jun 2013 15:26:40 -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   : 007556bf08e6153c442fe3742adb3685fca3a0e0    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 9 Jun 2013 13:46:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 9 Jun 2013 13:46:54 -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   : d535136b5d60b19f7ffa777b97ed301739c15a9d    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 8 Jun 2013 10:00:09 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 8 Jun 2013 10:00:09 -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   : 94e3311b97448324d67ba9a527854271373329d9    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 8 Jun 2013 09:12:48 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 8 Jun 2013 09:12:48 -0400    

In 9.2, Unicode escape sequences are not analysed at all other than  
to make sure that they are in the form \uXXXX. But in 9.3 many of the  
new operators and functions try to turn JSON text values into text in  
the server encoding, and this includes de-escaping Unicode escape  
sequences. This processing had not taken into account the possibility  
that this might contain a surrogate pair to designate a character  
outside the BMP. That is now handled correctly.  
  
This also enforces correct use of surrogate pairs, something that is not  
done by the type's input routines. This fact is noted in the docs.  

commit   : c99d5d1bcc137c15058458bbdcdd2789b56e4c66    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 7 Jun 2013 22:00:59 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 7 Jun 2013 22:00:59 -0400    

Although the DTD technically allows this, the resulting HTML is invalid  
because it puts block elements inside inline elements.  DocBook 5.0 also  
doesn't allow it anymore, so it's fair to assume that this was never  
really intended to work.  Replace <synopsis> with <literal>, which is  
the markup used elsewhere in the documentation in similar cases.  

commit   : 734fbbd1d2d1babfbd195414e2445024ad549ae3    
  
author   : Kevin Grittner <[email protected]>    
date     : Fri, 7 Jun 2013 08:04:22 -0500    
  
committer: Kevin Grittner <[email protected]>    
date     : Fri, 7 Jun 2013 08:04:22 -0500    

It claimed the value was always zero; it is really always -1.  
  
Per report from Hari Babu  

commit   : 7b1e893acd4b7637de93631781f82e0f6834b621    
  
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   : 58617e4dc131561f4b6ba492d6a404b05bd0b968    
  
author   : Peter Eisentraut <[email protected]>    
date     : Thu, 6 Jun 2013 21:03:04 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Thu, 6 Jun 2013 21:03:04 -0400    

Greg Smith  

commit   : f73cb5567c2e27d9a02c7ddba9da8d8557cf08dd    
  
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   : a6370fd9ed3dbad6070b789eae916d6a037e4773    
  
author   : Robert Haas <[email protected]>    
date     : Thu, 6 Jun 2013 10:03:37 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Thu, 6 Jun 2013 10:03:37 -0400    

Andres Freund  

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

commit   : 964c0d0f80e485dd3a4073e073ddfd9bfdda90b2    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 5 Jun 2013 23:44:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 5 Jun 2013 23:44:02 -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   : a3bd6096bdc6db70ec267116ba52a4cccbd34c2a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 5 Jun 2013 22:05:18 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 5 Jun 2013 22:05:18 -0400    

commit   : 3f783c882712db5a5e0056f271ff765edeb2571a    
  
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   : 530acda4dabe26a4345eccd28a92dd23b1e7a94a    
  
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   : 5c7603c318872a42e1665b228f68fdf58714d945    
  
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   : dbc6eb1f4b840d252031419d4bf694316812124f    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 4 Jun 2013 14:58:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 4 Jun 2013 14:58:46 -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   : 79e15c7d86d3f781cc390a5a04db18254ce97b79    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Tue, 4 Jun 2013 18:51:43 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Tue, 4 Jun 2013 18:51:43 +0300    

Because of the bug, -r would not accept the rmgr with the highest ID.  

commit   : 035a5e1e8c346efe25df6be4627b5f24cc3736b1    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 3 Jun 2013 14:19:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 3 Jun 2013 14:19:26 -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   : 15386281a62071f322155b74cb32c2fea92e8350    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 3 Jun 2013 17:22:31 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 3 Jun 2013 17:22:31 +0300    

This reverts commit a475c6036752c26dca538632b68fd2cc592976b7.  
  
Erik Rijkers reported back in January 2013 that after the patch, if you do  
"pg_dump -t myschema.mytable" to dump a single table, and restore that in  
a database where myschema does not exist, the table is silently created in  
pg_catalog instead. That is because pg_dump uses  
"SET search_path=myschema, pg_catalog" to set schema the table is created  
in. While allow_system_table_mods is not a very elegant solution to this,  
we can't leave it as it is, so for now, revert it back to the way it was  
previously.  

commit   : f129615fe72f70868a86862b663dd7d78dd5cb71    
  
author   : Stephen Frost <[email protected]>    
date     : Mon, 3 Jun 2013 08:40:27 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Mon, 3 Jun 2013 08:40:27 -0400    

A few more minor spelling corrections, no functional changes.  
  
Thom Brown  

commit   : e1e2bb34f1237cbec396bcaa795f0fa955af0e72    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 3 Jun 2013 09:25:12 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 3 Jun 2013 09:25:12 +0300    

Seems cleaner to get the currently-replayed TLI in the same call to  
GetXLogReplayRecPtr that we get the WAL position. Make it more clear in the  
comment what the code does when recovery has already ended  
(RecoveryInProgress() will set ThisTimeLineID in that case). Finally, make  
resetting ThisTimeLineID afterwards more explicit.  

commit   : 2c92edad48796119c83d7dbe6c33425d1924626d    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 2 Jun 2013 20:09:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 2 Jun 2013 20:09:20 -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   : 22b36412c73fdae960cc6bef58eb16a26d14b700    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 1 Jun 2013 22:22:02 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 1 Jun 2013 22:22:02 -0400    

commit   : 93874ce064836e45220978e2656cbf62eba766ed    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 1 Jun 2013 22:03:02 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 1 Jun 2013 22:03:02 -0400    

See 00b0c73f1f2b98a7d09de63aaa14d6498ac521ae for an explanation.  

commit   : a149d8bd56edc2f06643118ed8aac8bce6ebad6d    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 1 Jun 2013 13:58:23 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 1 Jun 2013 13:58:23 -0400    

Must cast char argument to unsigned to avoid doing the wrong thing  
with high-bit-set characters.  Oversight in commit  
30b5ede7157e34e77c7914b8ecfd55aa8da6edc3.  

commit   : c9fc28a7f12e27d530e2657c9dc6080fbfbe8a14    
  
author   : Stephen Frost <[email protected]>    
date     : Sat, 1 Jun 2013 10:18:59 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Sat, 1 Jun 2013 10:18:59 -0400    

Fix a few spelling mistakes.  
  
Per bug report #8193 from Lajos Veres.  

commit   : 551938ae2284975b53d665fa8a82a7e1f3514dda    
  
author   : Stephen Frost <[email protected]>    
date     : Sat, 1 Jun 2013 09:38:15 -0400    
  
committer: Stephen Frost <[email protected]>    
date     : Sat, 1 Jun 2013 09:38:15 -0400    

Make slightly better decisions about indentation than what pgindent  
is capable of.  Mostly breaking out long function calls into one  
line per argument, with a few other minor adjustments.  
  
No functional changes- all whitespace.  
pgindent ran cleanly (didn't change anything) after.  
Passes all regressions.  

commit   : dedf7e9919a2dc42370c0b218728e1556985de6a    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 31 May 2013 22:42:27 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 31 May 2013 22:42:27 -0400    

They no longer match reality with the web site style sheets, and it is  
difficult to keep the up to date in a CSS world.  

commit   : 97c4d9b7c71519d9dc281394af2c4bcb28bdf136    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 31 May 2013 21:50:59 -0400    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 31 May 2013 21:50:59 -0400    

Dean Rasheed  

commit   : 01497e738e58b0a5d87706353f28eccc5bea9591    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 31 May 2013 20:03:39 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 31 May 2013 20:03:39 -0400