PostgreSQL 9.4.0 commit log

commit   : 8ca336f4ac3f08a5f23e76c6e9a5f2c8064f5883    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Dec 2014 20:07:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Dec 2014 20:07:34 -0500    

commit   : 84b76f2b62bd34c40533931b9547d7d411a62128    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 15 Dec 2014 19:27:12 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 15 Dec 2014 19:27:12 -0300    

commit   : 38a8323bdbb7524a96955fbaac90b12c94996b60    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Dec 2014 16:18:13 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Dec 2014 16:18:13 -0500    

commit   : a666dfa99b750e22c9b91c05c0e3492b170a8fb4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 15 Dec 2014 16:49:41 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 15 Dec 2014 16:49:41 -0300    

commit   : e208b51f5491c85e0e967fe9798ace3f041fe0b7    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Dec 2014 00:23:25 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 15 Dec 2014 00:23:25 -0500    

commit   : 93a5b1ff7842d91e1ce32c44660cc1e3e5a55317    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 14 Dec 2014 20:02:04 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 14 Dec 2014 20:02:04 -0500    

commit   : f4ec02c7cfd755be81dc0fe5dd0ccf2d49c2c30d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Dec 2014 18:09:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Dec 2014 18:09:55 -0500    

The ALTER SYSTEM ref page hadn't been held to a very high standard, nor  
was the feature well integrated into section 18.1 (parameter setting).  
Also, though commit 4c4654afe had improved the structure of 18.1, it also  
introduced a lot of poor wording, imprecision, and outright falsehoods.  
Try to clean that up.  

commit   : 76547289b5b351799198c8ea6fae3f0e52d576e7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Dec 2014 14:58:06 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 14 Dec 2014 14:58:06 -0500    

Set release date, do a final pass of wordsmithing, improve some other  
new-in-9.4 documentation.  

commit   : 5fc34ba880e1223268ffbbe8be8621342c883151    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Dec 2014 13:46:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Dec 2014 13:46:46 -0500    

Commit 815d71dee hadn't bothered to update the documentation to match the  
behavioral change, and a lot of other text in this section was badly in  
need of copy-editing.  

commit   : 9ccae6360df4a8be845e28b0ab9042ab09e8c397    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Dec 2014 11:49:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Dec 2014 11:49:20 -0500    

The code for advancing through the input rows overlooked the case that we  
might already be past the first row of the row pair now being considered,  
in case the previous percentile also fell between the same two input rows.  
  
Report and patch by Andrew Gierth; logic rewritten a bit for clarity by me.  

commit   : 1a1fb46da4ca6ac0385bdd43a33e15b64370dfdd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Dec 2014 12:41:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 12 Dec 2014 12:41:52 -0500    

In commit 462bd95705a0c23ba0b0ba60a78d32566a0384c1, I changed postgres_fdw  
to rely on get_plan_rowmark() instead of get_parse_rowmark().  I still  
think that's a good idea in the long run, but as Etsuro Fujita pointed out,  
it doesn't work today because planner.c forces PlanRowMarks to have  
markType = ROW_MARK_COPY for all foreign tables.  There's no urgent reason  
to change this in the back branches, so let's just revert that part of  
yesterday's commit rather than trying to design a better solution under  
time pressure.  
  
Also, add a regression test case showing what postgres_fdw does with FOR  
UPDATE/SHARE.  I'd blithely assumed there was one already, else I'd have  
realized yesterday that this code didn't work.  

commit   : f2e20542dac2e25bc37440e66fd2769c29f2836b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Dec 2014 21:02:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Dec 2014 21:02:28 -0500    

Ordinarily we can omit checking of a WHERE condition that matches a partial  
index's condition, when we are using an indexscan on that partial index.  
However, in SELECT FOR UPDATE we must include the "redundant" filter  
condition in the plan so that it gets checked properly in an EvalPlanQual  
recheck.  The planner got this mostly right, but improperly omitted the  
filter condition if the index in question was on an inheritance child  
table.  In READ COMMITTED mode, this could result in incorrectly returning  
just-updated rows that no longer satisfy the filter condition.  
  
The cause of the error is using get_parse_rowmark() when get_plan_rowmark()  
is what should be used during planning.  In 9.3 and up, also fix the same  
mistake in contrib/postgres_fdw.  It's currently harmless there (for lack  
of inheritance support) but wrong is wrong, and the incorrect code might  
get copied to someplace where it's more significant.  
  
Report and fix by Kyotaro Horiguchi.  Back-patch to all supported branches.  

commit   : 0c12be853a4e0367164dd59437598c7078809e4d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Dec 2014 19:37:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Dec 2014 19:37:03 -0500    

In READ COMMITTED mode, if a SELECT FOR UPDATE discovers it has to redo  
WHERE-clause checking on rows that have been updated since the SELECT's  
snapshot, it invokes EvalPlanQual processing to do that.  If this first  
occurs within a non-first child table of an inheritance tree, the previous  
coding could accidentally re-return a matching row from an earlier,  
already-scanned child table.  (And, to add insult to injury, I think this  
could make it miss returning a row that should have been returned, if the  
updated row that this happens on should still have passed the WHERE qual.)  
Per report from Kyotaro Horiguchi; the added isolation test is based on his  
test case.  
  
This has been broken for quite awhile, so back-patch to all supported  
branches.  

commit   : 390ed56eb7fb8cc4ba2a7cd6360b41883601908e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Dec 2014 15:41:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Dec 2014 15:41:20 -0500    

In passing, also make some debugging elog's in pgstat.c a bit more  
consistently worded.  
  
Back-patch as far as applicable (9.3 or 9.4; none of these mistakes are  
really old).  
  
Mark Dilger identified and patched the type violations; the message  
rewordings are mine.  

commit   : d0f8d0ded4e2d9bf77fd638c0cac281f83429c4d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 Dec 2014 20:55:30 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 Dec 2014 20:55:30 -0500    

Author: Fabrízio de Royes Mello <fabriziomello@gmail.com>  

commit   : 49b60a4be7cb8bbfb9d954cc5b81d0dc18b077df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Dec 2014 19:06:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Dec 2014 19:06:27 -0500    

The amount of space to reserve for the value's varlena header is  
VARHDRSZ, not sizeof(VARHDRSZ).  The latter coding accidentally  
failed to fail because of the way the VARHDRSZ macro is currently  
defined; but if we ever change it to return size_t (as one might  
reasonably expect it to do), convertToJsonb() would have failed.  
  
Spotted by Mark Dilger.  

commit   : eadd80c08ddfc485db84b9af7cca54a0d50ebe6d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 5 Dec 2014 14:27:56 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 5 Dec 2014 14:27:56 +0200    

Used to say just "could not read password from file "...": Success", which  
isn't very informative.  
  
Mats Erik Andersson. Backpatch to all supported versions.  

commit   : 463dde8def8befec1e8f1f3c106c1ce1108ad54f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 5 Dec 2014 11:58:24 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 5 Dec 2014 11:58:24 +0200    

It was an oversight in the original commit.  
  
Also note in the sample config file that changing wal_log_hints requires a  
restart.  
  
Michael Paquier. Backpatch to 9.4, where wal_log_hints was added.  

commit   : f3d7077dad94d6ac864647eaa50f5dd0590a6c8d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 4 Dec 2014 17:02:02 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 4 Dec 2014 17:02:02 -0500    

PGXS computes srcdir from VPATH, PostgreSQL proper computes VPATH from  
srcdir, and doing both results in an error from make.  Conditionalize so  
only one of these takes effect.  

commit   : e907997f42faada60e5a26b116cc0b79b69309d1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 19 Nov 2014 21:51:30 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 19 Nov 2014 21:51:30 -0500    

The user can just set VPATH directly.  There is no need to invent  
another variable.  

commit   : 4e4b9002498b72c7000a675216470e8918fc0420    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 4 Dec 2014 07:58:12 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 4 Dec 2014 07:58:12 -0500    

dblink and postgres_fdw use SHLIB_PREREQS = submake-libpq to build libpq  
first.  This doesn't work in a PGXS build, because there is no libpq to  
build.  So just omit setting SHLIB_PREREQS in this case.  
  
Note that PGXS users can still use SHLIB_PREREQS (although it is not  
documented).  The problem here is only that contrib modules can be built  
in-tree or using PGXS, and the prerequisite is only applicable in the  
former case.  
  
Commit 6697aa2bc25c83b88d6165340348a31328c35de6 previously attempted to  
address this by creating a somewhat fake submake-libpq target in  
Makefile.global.  That was not the right fix, and it was also done in a  
nonportable way, so revert that.  

commit   : 3e2dc9703a4835ace14310f82369df0a4e8528f2    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 Dec 2014 19:54:01 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 3 Dec 2014 19:54:01 -0500    

Since this is not something that a user should change,  
pg_config_manual.h was an inappropriate place for it.  
  
In initdb.c, remove the use of the macro, because utils/guc.h can't be  
included by non-backend code.  But we hardcode all the other  
configuration file names there, so this isn't a disaster.  

commit   : 567737822a004dd23a105c5b7129ff98b2805ac7    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 3 Dec 2014 11:52:16 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 3 Dec 2014 11:52:16 -0300    

commit   : 7a0be6782b5fc050ec93e386aec13f3100f498a7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Dec 2014 18:23:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Dec 2014 18:23:20 -0500    

Make the error messages issued by array_in() uniformly follow the style  
	ERROR: malformed array literal: "actual input string"  
	DETAIL: specific complaint here  
and rewrite many of the specific complaints to be clearer.  
  
The immediate motivation for doing this is a complaint from Josh Berkus  
that json_to_record() produced an unintelligible error message when  
dealing with an array item, because it tries to feed the JSON-format  
array value to array_in().  Really it ought to be smart enough to  
perform JSON-to-Postgres array conversion, but that's a future feature  
not a bug fix.  In the meantime, this change is something we agreed  
we could back-patch into 9.4, and it should help de-confuse things a bit.  

commit   : 10f1f93d8ae2d70fcaf350c62972fb6bac42ffc9    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 2 Dec 2014 23:42:26 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 2 Dec 2014 23:42:26 +0100    

The logical decoding patchset introduced PROC_IN_LOGICAL_DECODING flag  
PGXACT flag, that allows such backends to be skipped when computing  
the xmin horizon/snapshots. That's fine and sensible for walsenders  
streaming out logical changes, but not at all fine for SQL backends  
doing logical decoding. If the latter set that flag any change they  
have performed outside of logical decoding will not be regarded as  
visible - which e.g. can lead to that change being vacuumed away.  
  
Note that not setting the flag for SQL backends isn't particularly  
bothersome - the SQL backend doesn't do streaming, so it only runs for  
a limited amount of time.  
  
Per buildfarm member 'tick' and Alvaro.  
  
Backpatch to 9.4, where logical decoding was introduced.  

commit   : f0eeba6f83ed16687d8743b34e519de45c3915ec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Dec 2014 15:02:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Dec 2014 15:02:40 -0500    

Davide S. reported that json_agg() sometimes produced multiple trailing  
right brackets.  This turns out to be because json_agg_finalfn() attaches  
the final right bracket, and was doing so by modifying the aggregate state  
in-place.  That's verboten, though unfortunately it seems there's no way  
for nodeAgg.c to check for such mistakes.  
  
Fix that back to 9.3 where the broken code was introduced.  In 9.4 and  
HEAD, likewise fix json_object_agg(), which had copied the erroneous logic.  
Make some cosmetic cleanups as well.  

commit   : ac0aa07e96b3ebf7b8b2bebfc56fc86fb90c14f5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Dec 2014 15:25:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 1 Dec 2014 15:25:05 -0500    

We were not checking to see if the supplied dscale was valid for the given  
digit array when receiving binary-format numeric values.  While dscale can  
validly be more than the number of nonzero fractional digits, it shouldn't  
be less; that case causes fractional digits to be hidden on display even  
though they're there and participate in arithmetic.  
  
Bug #12053 from Tommaso Sala indicates that there's at least one broken  
client library out there that sometimes supplies an incorrect dscale value,  
leading to strange behavior.  This suggests that simply throwing an error  
might not be the best response; it would lead to failures in applications  
that might seem to be working fine today.  What seems the least risky fix  
is to truncate away any digits that would be hidden by dscale.  This  
preserves the existing behavior in terms of what will be printed for the  
transmitted value, while preventing subsequent arithmetic from producing  
results inconsistent with that.  
  
In passing, throw a specific error for the case of dscale being outside  
the range that will fit into a numeric's header.  Before you got "value  
overflows numeric format", which is a bit misleading.  
  
Back-patch to all supported branches.  

commit   : f82132f4a15e2a02d984b3ba0ef5b10da1f489bd    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 1 Dec 2014 11:28:45 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 1 Dec 2014 11:28:45 -0500    

We expose a function IsValidJsonNumber that internally calls the lexer  
for json numbers. That allows us to use the same test everywhere,  
instead of inventing a broken test for hstore conversions. The new  
function is also used in datum_to_json, replacing the code that is now  
moved to the new function.  
  
Backpatch to 9.3 where hstore_to_json_loose was introduced.  

commit   : 76394810f87d3c03f8a135cc6e9801acc6b0ad8d    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 1 Dec 2014 12:12:07 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 1 Dec 2014 12:12:07 +0100    

Ian Barwick  

commit   : 2e2c8455fa9f9bae80a1e1edd780b78362b82404    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Nov 2014 12:20:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 30 Nov 2014 12:20:47 -0500    

Coverity complained that the "else" added to fillPGconn() was unreachable,  
which it was.  Remove the dead code.  In passing, rearrange the tests so as  
not to bother trying to fetch values for options that can't be assigned.  
  
Pre-9.3 did not have that issue, but it did have a "return" that should be  
"goto oom_error" to ensure that a suitable error message gets filled in.  

commit   : 6bb6958fa2614a5f18e9ac992f8f9956db59e9d1    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 29 Nov 2014 15:53:05 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 29 Nov 2014 15:53:05 -0500    

Back-patch to 9.4, like the feature's removal.  

commit   : 36e52479852ee3343b901c1744faa690f5fac242    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 29 Nov 2014 12:31:43 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 29 Nov 2014 12:31:43 -0500    

Apart from ignoring "hostaddr" set to the empty string, this behaves  
identically to its predecessor.  Back-patch to 9.4, where the original  
commit first appeared.  
  
Reviewed by Fujii Masao.  

commit   : 27b6f9ce7b12f82599f95f296abe7bb8942a6041    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 29 Nov 2014 12:31:21 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 29 Nov 2014 12:31:21 -0500    

This reverts commit 9f80f4835a55a1cbffcda5d23a617917f3286c14.  The  
function returned the raw value of a connection parameter, a task served  
by PQconninfo().  The next commit will reimplement the psql \conninfo  
change that way.  Back-patch to 9.4, where that commit first appeared.  

commit   : 866c6ab456f97478ad7b316a8c9fbf7c9e9a3143    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 28 Nov 2014 18:06:18 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 28 Nov 2014 18:06:18 -0300    

Multixacts are now maintained during recovery, but the README didn't get  
the memo.  Backpatch to 9.3, where the divergence was introduced.  

commit   : 19b1511a48f2ebdce94fe5f85a89dd6c36da1ba5    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 28 Nov 2014 21:29:45 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 28 Nov 2014 21:29:45 +0900    

Back-patch to 9.4 where ALTER TABLE ALTER CONSTRAINT was added.  
  
Michael Paquier, bug reported by Andrey Lizenko.  

commit   : 0ec68a083b0619eaf48f7249a6659216c9fe5e35    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 28 Nov 2014 02:42:43 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 28 Nov 2014 02:42:43 +0900    

Previously \watch always ignored the user's \pset null setting.  
\pset null setting should be ignored for \d and similar queries.  
For those, the code can reasonably have an opinion about what  
the presentation should be like, since it knows what SQL query  
it's issuing. This argument surely doesn't apply to \watch,  
so this commit makes \watch use the user's \pset null setting.  
  
Back-patch to 9.3 where \watch was added.  

commit   : 6e9d43eb02583ce29ffbbf732ab8f26e2a58e4cf    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 28 Nov 2014 02:12:45 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 28 Nov 2014 02:12:45 +0900    

Back-patch to 9.3 where pg_isready was added.  
  
Mats Erik Andersson  

commit   : e2d0c25917bef8c25bf6e9b1bcf2a75dbf8f07f0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Nov 2014 11:12:47 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 27 Nov 2014 11:12:47 -0500    

Mark Simonetti reported that libxslt sometimes crashes for him, and that  
swapping xslt_process's object-freeing calls around to do them in reverse  
order of creation seemed to fix it.  I've not reproduced the crash, but  
valgrind clearly shows a reference to already-freed memory, which is  
consistent with the idea that shutdown of the xsltTransformContext is  
trying to reference the already-freed stylesheet or input document.  
With this patch, valgrind is no longer unhappy.  
  
I have an inquiry in to see if this is a libxslt bug or if we're just  
abusing the library; but even if it's a library bug, we'd want to adjust  
our code so it doesn't fail with unpatched libraries.  
  
Back-patch to all supported branches, because we've been doing this in  
the wrong(?) order for a long time.  

commit   : 6c1d521af35e496639bbb39764c30115879af47f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 25 Nov 2014 17:12:07 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 25 Nov 2014 17:12:07 +0200    

If the "dbname" attribute in PQconnectDBParams contained a connection string  
or URI (and expand_dbname = TRUE), the database name from the connection  
string could not be overridden by a subsequent "dbname" keyword in the  
array. That was not intentional; all other options can be overridden.  
Furthermore, any subsequent "dbname" caused the connection string from the  
first dbname value to be processed again, overriding any values for the same  
options that were given between the connection string and the second dbname  
option.  
  
In the passing, clarify in the docs that only the first dbname option in the  
array is parsed as a connection string.  
  
Alex Shulgin. Backpatch to all supported versions.  

commit   : 811015ff9aafd2d5e03fbd931f7c6102b3d6516a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 25 Nov 2014 12:55:00 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 25 Nov 2014 12:55:00 +0200    

An out-of-memory in most of these would lead to strange behavior, like  
connecting to a different database than intended, but some would lead to  
an outright segfault.  
  
Alex Shulgin and me. Backpatch to all supported versions.  

commit   : 3852eaba10bdcd8eafa5e64dbd853dc5c50e134c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Nov 2014 16:01:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 22 Nov 2014 16:01:08 -0500    

postgres_fdw would send query conditions involving system columns to the  
remote server, even though it makes no effort to ensure that system  
columns other than CTID match what the remote side thinks.  tableoid,  
in particular, probably won't match and might have some use in queries.  
Hence, prevent sending conditions that include non-CTID system columns.  
  
Also, create_foreignscan_plan neglected to check local restriction  
conditions while determining whether to set fsSystemCol for a foreign  
scan plan node.  This again would bollix the results for queries that  
test a foreign table's tableoid.  
  
Back-patch the first fix to 9.3 where postgres_fdw was introduced.  
Back-patch the second to 9.2.  The code is probably broken in 9.1 as  
well, but the patch doesn't apply cleanly there; given the weak state  
of support for FDWs in 9.1, it doesn't seem worth fixing.  
  
Etsuro Fujita, reviewed by Ashutosh Bapat, and somewhat modified by me  

commit   : 0632eff4389a2682c49db7fbe16968bb076060a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Nov 2014 16:00:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 19 Nov 2014 16:00:27 -0500    

In bug #12000, Andreas Kunert complained that the documentation was  
misleading in saying "FROM T1 CROSS JOIN T2 is equivalent to FROM T1, T2".  
That's correct as far as it goes, but the equivalence doesn't hold when  
you consider three or more tables, since JOIN binds more tightly than  
comma.  I added a <note> to explain this, and ended up rearranging some  
of the existing text so that the note would make sense in context.  
  
In passing, rewrite the description of JOIN USING, which was unnecessarily  
vague, and hadn't been helped any by somebody's reliance on markup as a  
substitute for clear writing.  (Mostly this involved reintroducing a  
concrete example that was unaccountably removed by commit 032f3b7e166cfa28.)  
  
Back-patch to all supported branches.  

commit   : a9f3280efee0d3c4f697ef33f28cbc8e626f9e86    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 19 Nov 2014 11:57:54 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 19 Nov 2014 11:57:54 -0500    

This can cause problems on Windows, where files that are still open  
can't be unlinked.  
  
Jeff Janes  

commit   : 78f91f1a888008f329b1a6db673713d25bbd819b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 19 Nov 2014 19:11:03 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 19 Nov 2014 19:11:03 +0900    

In pg_receivexlog, in order to check whether the current WAL file is  
being opened or not, its file descriptor has to be checked against -1  
as an invalid value. But, oops, 7900e94 added the incorrect test  
checking the descriptor against 1. This commit fixes that bug.  
  
Back-patch to 9.4 where the bug was added.  
  
Spotted by Magnus Hagander  

commit   : 7900e94fbb2d36fe798f2deda56d71071957c0e0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 19 Nov 2014 14:11:48 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 19 Nov 2014 14:11:48 +0900    

When pg_receivexlog --slot is connecting to the server, at the shutdown  
of the server, walsender keeps waiting for the last WAL record to be  
replicated and flushed in pg_receivexlog. But previously pg_receivexlog  
issued sync command only when WAL file was switched. So there was  
the case where the last WAL was never flushed and walsender had to  
keep waiting infinitely. This caused the server shutdown to get stuck.  
  
pg_recvlogical handles this problem by calling fsync() when it receives  
the request of immediate reply from the server. That is, at shutdown,  
walsender sends the request, pg_recvlogical receives it, flushes the last  
WAL record, and sends the flush location back to the server. Since  
walsender can see that the last WAL record is successfully flushed, it can  
exit cleanly.  
  
This commit introduces the same logic as pg_recvlogical has,  
to pg_receivexlog.  
  
Back-patch to 9.4 where pg_receivexlog was changed so that it can use  
the replication slot.  
  
Original patch by Michael Paquier, rewritten by me.  
Bug report by Furuya Osamu.  

commit   : e1ab2fa823692e13b2302ba2959f297acb4f1758    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Nov 2014 21:36:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Nov 2014 21:36:43 -0500    

The regression test cases added in commits b2cbced9e et al depended in part  
on the Russian timezone offset changes of Oct 2014.  While this is of no  
particular concern for a default Postgres build, it was possible for a  
build using --with-system-tzdata to fail the tests if the system tzdata  
database wasn't au courant.  Bjorn Munch and Christoph Berg both complained  
about this while packaging 9.4rc1, so we probably shouldn't insist on the  
system tzdata being up-to-date.  Instead, make an equivalent test using a  
zone change that occurred in Venezuela in 2007.  With this patch, the  
regression tests should pass using any tzdata set from 2012 or later.  
(I can't muster much sympathy for somebody using --with-system-tzdata  
on a machine whose system tzdata is more than three years out-of-date.)  

commit   : 3aa3ae8e1d959681d3396fe176cd8086e3b26c55    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Nov 2014 13:28:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 18 Nov 2014 13:28:09 -0500    

pg_dump/parallel.c was using realloc() directly with no error check.  
While the odds of an actual failure here seem pretty low, Coverity  
complains about it, so fix by using pg_realloc() instead.  
  
While looking for other instances, I noticed a couple of places in  
psql that hadn't gotten the memo about the availability of pg_realloc.  
These aren't bugs, since they did have error checks, but verbosely  
inconsistent code is not a good thing.  
  
Back-patch as far as 9.3.  9.2 did not have pg_dump/parallel.c, nor  
did it have pg_realloc available in all frontend code.  

commit   : d5bea1fbcc24a9880ddc2ede29a6fedb41de9292    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Nov 2014 15:54:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Nov 2014 15:54:40 -0500    

commit   : c7b412380d5507fbaf1e4ff54844ac9bde9771c5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Nov 2014 14:47:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Nov 2014 14:47:13 -0500    

commit   : ddf7db58420375c75e3fb1f5fc6cbb90c5ee9b0c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Nov 2014 12:08:02 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Nov 2014 12:08:02 -0500    

DST law changes in the Turks & Caicos Islands (America/Grand_Turk) and  
in Fiji.  New zone Pacific/Bougainville for portions of Papua New Guinea.  
Historical changes for Korea and Vietnam.  

commit   : 8607fdf0337051ca1da493ded5db15c41da08d66    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 17 Nov 2014 18:42:04 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 17 Nov 2014 18:42:04 +0200    

There was some confusion on how to record the case that the operation  
unlinks the last non-leaf page in the branch being deleted.  
_bt_unlink_halfdead_page set the "topdead" field in the WAL record to  
the leaf page, but the redo routine assumed that it would be an invalid  
block number in that case. This commit fixes _bt_unlink_halfdead_page to  
do what the redo routine expected.  
  
This code is new in 9.4, so backpatch there.  

commit   : d8a7cdde585c49037cdfdc624223dd53cd868a30    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 16 Nov 2014 21:31:08 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 16 Nov 2014 21:31:08 -0500    

commit   : e668b366304b526a354f8ff5a3eed683c818f7a9    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 16 Nov 2014 15:48:30 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 16 Nov 2014 15:48:30 +0100    

Daniel Gustafsson  

commit   : 6d301af4c023ac5655d88acbe55f7f49036ee50c    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 16 Nov 2014 15:47:10 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 16 Nov 2014 15:47:10 +0100    

Patch from Michael Paquier, mistake spotted by KOIZUMI Satoru  

commit   : f52b3c44632f99d53973be57e5c729cfc3d6430f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 14 Nov 2014 18:22:12 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 14 Nov 2014 18:22:12 +0100    

630cd14426dc added initdb --sync-only, for use by pg_upgrade, by just  
exposing the existing fsync code. That's wrong, because initdb so far  
had absolutely no reason to deal with tablespaces.  
  
Fix --sync-only by additionally explicitly syncing each of the  
tablespaces.  
  
Backpatch to 9.3 where --sync-only was introduced.  
  
Abhijit Menon-Sen and Andres Freund  

commit   : e26a920acb77b953d1034e243d6a8c7294dbd25d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 14 Nov 2014 18:21:30 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 14 Nov 2014 18:21:30 +0100    

Unlogged relations are only reset when performing a unclean  
restart. That means they have to be synced to disk during clean  
shutdowns. During normal processing that's achieved by registering a  
buffer's file to be fsynced at the next checkpoint when flushed. But  
ResetUnloggedRelations() doesn't go through the buffer manager, so  
nothing will force reset relations to disk before the next shutdown  
checkpoint.  
  
So just make ResetUnloggedRelations() fsync the newly created main  
forks to disk.  
  
Discussion: 20140912112246.GA4984@alap3.anarazel.de  
  
Backpatch to 9.1 where unlogged tables were introduced.  
  
Abhijit Menon-Sen and Andres Freund  

commit   : 1a2cb1ea84a1745247a7b41f1b0188889e815794    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 14 Nov 2014 18:20:59 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 14 Nov 2014 18:20:59 +0100    

Unlogged relations are reset at the end of crash recovery as they're  
only synced to disk during a proper shutdown. Unfortunately that and  
later steps can fail, e.g. due to running out of space. This reset  
was, up to now performed after marking the database as having finished  
crash recovery successfully. As out of space errors trigger a crash  
restart that could lead to the situation that not all unlogged  
relations are reset.  
  
Once that happend usage of unlogged relations could yield errors like  
"could not open file "...": No such file or directory". Luckily  
clusters that show the problem can be fixed by performing a immediate  
shutdown, and starting the database again.  
  
To fix, just call ResetUnloggedRelations(UNLOGGED_RELATION_INIT)  
earlier, before marking the database as having successfully recovered.  
  
Discussion: 20140912112246.GA4984@alap3.anarazel.de  
  
Backpatch to 9.1 where unlogged tables were introduced.  
  
Abhijit Menon-Sen and Andres Freund  

commit   : df3e23e1b509001ac9336763404406bdcad04dcc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Nov 2014 17:19:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Nov 2014 17:19:29 -0500    

The SELECT reference page didn't really address the question of when  
aggregate function evaluation occurs, nor did the "expression evaluation  
rules" documentation mention that CASE can't be used to control whether  
an aggregate gets evaluated or not.  Improve that.  
  
Per discussion of bug #11661.  Original text by Marti Raudsepp and Michael  
Paquier, rewritten significantly by me.  

commit   : 2113f7215d2e13f07c277a86efae900b25d94dc1    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 14 Nov 2014 15:16:01 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 14 Nov 2014 15:16:01 -0500    

When ALTER TABLESPACE MOVE ALL was changed to be ALTER TABLE ALL IN  
TABLESPACE, the ALTER TABLESPACE summary should have been adjusted back  
to its original definition.  
  
Patch by Thom Brown (thanks!).  

commit   : 137e4da6df75a671d53bcc1e66097533c93c8732    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Nov 2014 15:14:02 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 14 Nov 2014 15:14:02 -0300    

This function has a loop which can lead to uninterruptible process  
"stalls" (actually infinite loops) when some bugs are triggered.  Avoid  
that unpleasant situation by adding a check for interrupts in a place  
that shouldn't degrade performance in the normal case.  
  
Backpatch to 9.3.  Older branches have an identical loop here, but the  
aforementioned bugs are only a problem starting in 9.3 so there doesn't  
seem to be any point in backpatching any further.  

commit   : 16695d601e73792c3e49f324b48ff25af96c83d9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 13 Nov 2014 20:43:55 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 13 Nov 2014 20:43:55 -0500    

suggestions from Robert Haas  

commit   : 2c267e47afa4f9a7cc8f04f43e440dfdf9fd3ed7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Nov 2014 18:19:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Nov 2014 18:19:28 -0500    

Fix breakage induced by commits d8d3d2a4f37f6df5d0118b7f5211978cca22091a  
and 463f2625a5fb183b6a8925ccde98bb3889f921d9: pg_dumpall has crashed when  
attempting to dump from pre-8.1 servers since then, due to faulty  
construction of the query used for dumping roles from older servers.  
The query was erroneous as of the earlier commit, but it wasn't exposed  
unless you tried to use --binary-upgrade, which you presumably wouldn't  
with a pre-8.1 server.  However commit 463f2625a made it fail always.  
  
In HEAD, also fix additional breakage induced in the same query by  
commit 491c029dbc4206779cf659aa0ff986af7831d2ff, which evidently wasn't  
tested against pre-8.1 servers either.  
  
The bug is only latent in 9.1 because 463f2625a hadn't landed yet, but  
it seems best to back-patch all branches containing the faulty query.  
  
Gilles Darold  

commit   : 11868e1704cae36ee13303eaf9f5f5f656870426    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 13 Nov 2014 19:06:43 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 13 Nov 2014 19:06:43 +0100    

There are basically three situations in which logical decoding needs  
to perform cache invalidation. During/After replaying a transaction  
with catalog changes, when skipping a uninteresting transaction that  
performed catalog changes and when erroring out while replaying a  
transaction. Unfortunately these three cases were all done slightly  
differently - partially because 8de3e410fa, which greatly simplifies  
matters, got committed in the midst of the development of logical  
decoding.  
  
The actually problematic case was when logical decoding skipped  
transaction commits (and thus processed invalidations). When used via  
the SQL interface cache invalidation could access the catalog - bad,  
because we didn't set up enough state to allow that correctly. It'd  
not be hard to setup sufficient state, but the simpler solution is to  
always perform cache invalidation outside a valid transaction.  
  
Also make the different cache invalidation cases look as similar as  
possible, to ease code review.  
  
This fixes the assertion failure reported by Antonin Houska in  
53EE02D9.7040702@gmail.com. The presented testcase has been expanded  
into a regression test.  
  
Backpatch to 9.4, where logical decoding was introduced.  

commit   : da668a5d8f92af33d1f01b20993f4e1cf3735973    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 13 Nov 2014 19:06:43 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 13 Nov 2014 19:06:43 +0100    

When building the initial historic catalog snapshot there were  
scenarios where snapbuild.c would use incorrect xmin/xmax values when  
starting from a xl_running_xacts record. The values used were always a  
bit suspect, but happened to be correct in the easy to test  
cases. Notably the values used when the the initial snapshot was  
computed while no other transactions were running were correct.  
  
This is likely to be the cause of the occasional buildfarm failures on  
animals markhor and tick; but it's quite possible to reproduce  
problems without CLOBBER_CACHE_ALWAYS.  
  
Backpatch to 9.4, where logical decoding was introduced.  

commit   : 8fc23a9ed0a040d039431ef79b1bf166395ed180    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 13 Nov 2014 19:47:44 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 13 Nov 2014 19:47:44 +0200    

There was a window in RestoreBackupBlock where a page would be zeroed out,  
but not yet locked. If a backend pinned and locked the page in that window,  
it saw the zeroed page instead of the old page or new page contents, which  
could lead to missing rows in a result set, or errors.  
  
To fix, replace RBM_ZERO with RBM_ZERO_AND_LOCK, which atomically pins,  
zeroes, and locks the page, if it's not in the buffer cache already.  
  
In stable branches, the old RBM_ZERO constant is renamed to RBM_DO_NOT_USE,  
to avoid breaking any 3rd party extensions that might use RBM_ZERO. More  
importantly, this avoids renumbering the other enum values, which would  
cause even bigger confusion in extensions that use ReadBufferExtended, but  
haven't been recompiled.  
  
Backpatch to all supported versions; this has been racy since hot standby  
was introduced.  

commit   : 955b4ba7f6948359efcef1c47035d382f937e9f3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Nov 2014 14:45:58 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Nov 2014 14:45:58 -0300    

Move the meat of locking levels to mvcc.sgml, leaving only a link to it  
in the SELECT reference page.  
  
Michael Paquier, with some tweaks by Álvaro  

commit   : a3408059dd66b3b9929e04b3697213b31ccb5253    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 13 Nov 2014 11:57:16 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 13 Nov 2014 11:57:16 -0500    

commit   : 40b85a3ab11e99096dc4489153cfdd4884cdecd3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Nov 2014 15:58:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Nov 2014 15:58:40 -0500    

This only happens if a client issues a Parse message with an empty query  
string, which is a bit odd; but since it is explicitly called out as legal  
by our FE/BE protocol spec, we'd probably better continue to allow it.  
  
Fix by adding tests everywhere that the raw_parse_tree field is passed to  
functions that don't or shouldn't accept NULL.  Also make it clear in the  
relevant comments that NULL is an expected case.  
  
This reverts commits a73c9dbab0165b3395dfe8a44a7dfd16166963c4 and  
2e9650cbcff8c8fb0d9ef807c73a44f241822eee, which fixed specific crash  
symptoms by hacking things at what now seems to be the wrong end, ie the  
callee functions.  Making the callees allow NULL is superficially more  
robust, but it's not always true that there is a defensible thing for the  
callee to do in such cases.  The caller has more context and is better  
able to decide what the empty-query case ought to do.  
  
Per followup discussion of bug #11335.  Back-patch to 9.2.  The code  
before that is sufficiently different that it would require development  
of a separate patch, which doesn't seem worthwhile for what is believed  
to be an essentially cosmetic change.  

commit   : 5005469cb2f2bf8a57344b43f97969292ebebb76    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 12 Nov 2014 18:52:49 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 12 Nov 2014 18:52:49 +0100    

Heikki noticed in 544E23C0.8090605@vmware.com that slot.c and  
snapbuild.c were missing the FIN_CRC32 call when computing/checking  
checksums of on disk files. That doesn't lower the the error detection  
capabilities of the checksum, but is inconsistent with other usages.  
  
In a followup mail Heikki also noticed that, contrary to a comment,  
the 'version' and 'length' struct fields of replication slot's on disk  
data where not covered by the checksum. That's not likely to lead to  
actually missed corruption as those fields are cross checked with the  
expected version and the actual file length. But it's wrong  
nonetheless.  
  
As fixing these issues makes existing on disk files unreadable, bump  
the expected versions of on disk files for both slots and logical  
decoding historic catalog snapshots.  This means that loading old  
files will fail with  
ERROR: "replication slot file ... has unsupported version 1"  
and  
ERROR: "snapbuild state file ... has unsupported version 1 instead of  
2" respectively. Given the low likelihood of anybody already using  
these new features in a production setup that seems acceptable.  
  
Fixing these issues made me notice that there's no regression test  
covering the loading of historic snapshot from disk - so add one.  
  
Backpatch to 9.4 where these features were introduced.  

commit   : 57b2e1049e7fdb0ca7882c74520e409507462eb2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 12 Nov 2014 18:52:49 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 12 Nov 2014 18:52:49 +0100    

Currently the extension's pg_prewarm() function didn't check  
interrupts once it started "warming" data. Since individual calls can  
take a long while it's important for them to be interruptible.  
  
Backpatch to 9.4 where pg_prewarm was introduced.  

commit   : c4d360d18259690442036c1ee07a899cbe4022a0    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 12 Nov 2014 07:33:17 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 12 Nov 2014 07:33:17 -0500    

On Windows, DROP TABLESPACE has a race condition when run concurrently  
with other processes having opened files in the tablespace.  This led to  
a rare failure on buildfarm member frogmouth.  Back-patch to 9.4, where  
the reconnection was introduced.  

commit   : 8fb4218ef41da0baff4909c5d74f23513bac9950    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 11 Nov 2014 20:00:58 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 11 Nov 2014 20:00:58 -0500    

commit   : 1c73485c695af2dfa7a7f7bec6e1ab8d4eaab7ab    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Nov 2014 17:22:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Nov 2014 17:22:15 -0500    

This fixes a scenario in which pgp_sym_decrypt() failed with "Wrong key  
or corrupt data" on messages whose length is 6 less than a power of 2.  
  
Per bug #11905 from Connor Penhale.  Fix by Marko Tiikkaja, regression  
test case from Jeff Janes.  

commit   : 951c2f6faf00a00ab824699c96376d1d8f5acc57    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Nov 2014 17:00:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 11 Nov 2014 17:00:18 -0500    

When the recursive search in dependency.c visits a column and then later  
visits the whole table containing the column, it needs to propagate the  
drop-context flags for the table to the existing target-object entry for  
the column.  Otherwise we might refuse the DROP (if not CASCADE) on the  
incorrect grounds that there was no automatic drop pathway to the column.  
Remarkably, this has not been reported before, though it's possible at  
least when an extension creates both a datatype and a table using that  
datatype.  
  
Rather than just marking the column as allowed to be dropped, it might  
seem good to skip the DROP COLUMN step altogether, since the later DROP  
of the table will surely get the job done.  The problem with that is that  
the datatype would then be dropped before the table (since the whole  
situation occurred because we visited the datatype, and then recursed to  
the dependent column, before visiting the table).  That seems pretty risky,  
and the case is rare enough that it doesn't seem worth expending a lot of  
effort or risk to make the drops happen in a safe order.  So we just play  
dumb and delete the column separately according to the existing drop  
ordering rules.  
  
Per report from Petr Jelinek, though this is different from his proposed  
patch.  
  
Back-patch to 9.1, where extensions were introduced.  There's currently  
no evidence that such cases can arise before 9.1, and in any case we would  
also need to back-patch cb5c2ba2d82688d29b5902d86b993a54355cad4d to 9.0  
if we wanted to back-patch this.  

commit   : f449873623605bc1906f2a5daa56f2343c473e1b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Nov 2014 15:21:14 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Nov 2014 15:21:14 -0500    

At one time it wasn't terribly important what column names were associated  
with the fields of a composite Datum, but since the introduction of  
operations like row_to_json(), it's important that looking up the rowtype  
ID embedded in the Datum returns the column names that users would expect.  
That did not work terribly well before this patch: you could get the column  
names of the underlying table, or column aliases from any level of the  
query, depending on minor details of the plan tree.  You could even get  
totally empty field names, which is disastrous for cases like row_to_json().  
  
To fix this for whole-row Vars, look to the RTE referenced by the Var, and  
make sure its column aliases are applied to the rowtype associated with  
the result Datums.  This is a tad scary because we might have to return  
a transient RECORD type even though the Var is declared as having some  
named rowtype.  In principle it should be all right because the record  
type will still be physically compatible with the named rowtype; but  
I had to weaken one Assert in ExecEvalConvertRowtype, and there might be  
third-party code containing similar assumptions.  
  
Similarly, RowExprs have to be willing to override the column names coming  
from a named composite result type and produce a RECORD when the column  
aliases visible at the site of the RowExpr differ from the underlying  
table's column names.  
  
In passing, revert the decision made in commit 398f70ec070fe601 to add  
an alias-list argument to ExecTypeFromExprList: better to provide that  
functionality in a separate function.  This also reverts most of the code  
changes in d68581483564ec0f, which we don't need because we're no longer  
depending on the tupdesc found in the child plan node's result slot to be  
blessed.  
  
Back-patch to 9.4, but not earlier, since this solution changes the results  
in some cases that users might not have realized were buggy.  We'll apply a  
more restricted form of this patch in older branches.  

commit   : ef52e3a7b4fbcddd64afb5b528f945d6bb21aeb1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 7 Nov 2014 20:47:38 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 7 Nov 2014 20:47:38 -0500    

Work around accidental test failures because the working directory path  
is too long by creating a temporary directory in the (hopefully shorter)  
system location, symlinking that to the working directory, and creating  
the tablespaces using the shorter path.  

commit   : 342bcee4aa142ce4b119838a4c5d6debd694539f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 7 Nov 2014 20:15:22 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 7 Nov 2014 20:15:22 -0500    

The old note about how to use pg_receivexlog as an alternative to  
archive_command was obsoleted by replication slots.  

commit   : f36f4fbdca3de615acb2fc232f6bc72d6db19bde    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Nov 2014 21:14:35 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 7 Nov 2014 21:14:35 +0200    

I broke these in 8776faa81cb651322b8993422bdd4633f1f6a487. Backpatch to  
9.4, where that was done.  

commit   : eed245a113c299976e548f018c758617bc20efd0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Nov 2014 20:52:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Nov 2014 20:52:40 -0500    

dict_thesaurus stored phrase IDs in uint16 fields, so it would get confused  
and even crash if there were more than 64K entries in the configuration  
file.  It turns out to be basically free to widen the phrase IDs to uint32,  
so let's just do so.  
  
This was complained of some time ago by David Boutin (in bug #7793);  
he later submitted an informal patch but it was never acted on.  
We now have another complaint (bug #11901 from Luc Ouellette) so it's  
time to make something happen.  
  
This is basically Boutin's patch, but for future-proofing I also added a  
defense against too many words per phrase.  Note that we don't need any  
explicit defense against overflow of the uint32 counters, since before that  
happens we'd hit array allocation sizes that repalloc rejects.  
  
Back-patch to all supported branches because of the crash risk.  

commit   : 42020f5deb5d3a3b6593152cc1a95dbfa5250275    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Nov 2014 11:41:06 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 6 Nov 2014 11:41:06 -0500    

The default JSONB GIN opclass (jsonb_ops) converts numeric data values  
to strings for storage in the index.  It must ensure that numeric values  
that would compare equal (such as 12 and 12.00) produce identical strings,  
else index searches would have behavior different from regular JSONB  
comparisons.  Unfortunately the function charged with doing this was  
completely wrong: it could reduce distinct numeric values to the same  
string, or reduce equivalent numeric values to different strings.  The  
former type of error would only lead to search inefficiency, but the  
latter type of error would cause index entries that should be found by  
a search to not be found.  
  
Repairing this bug therefore means that it will be necessary for 9.4 beta  
testers to reindex GIN jsonb_ops indexes, if they care about getting  
correct results from index searches involving numeric data values within  
the comparison JSONB object.  
  
Per report from Thomas Fanghaenel.  

commit   : cc76577873945183352fa6e1e82cc14606c28fd3    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 6 Nov 2014 21:24:40 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 6 Nov 2014 21:24:40 +0900    

Previously .ready file was created for the timeline history file at the end  
of an archive recovery even when WAL archiving was not enabled.  
This creation is unnecessary and causes .ready file to remain infinitely.  
  
This commit changes an archive recovery so that it creates .ready file for  
the timeline history file only when WAL archiving is enabled.  
  
Backpatch to all supported versions.  

commit   : 26a95a1e521e4ae1a2ebdcc0db5745ee8d1285cc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Nov 2014 11:34:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 5 Nov 2014 11:34:13 -0500    

In general, datatype I/O functions are supposed to be immutable or at  
worst stable.  Some contrib I/O functions were, through oversight, not  
marked with any volatility property at all, which made them VOLATILE.  
Since (most of) these functions actually behave immutably, the erroneous  
marking isn't terribly harmful; but it can be user-visible in certain  
circumstances, as per a recent bug report from Joe Van Dyk in which a  
cast to text was disallowed in an expression index definition.  
  
To fix, just adjust the declarations in the extension SQL scripts.  If we  
were being very fussy about this, we'd bump the extension version numbers,  
but that seems like more trouble (for both developers and users) than the  
problem is worth.  
  
A fly in the ointment is that chkpass_in actually is volatile, because  
of its use of random() to generate a fresh salt when presented with a  
not-yet-encrypted password.  This is bad because of the general assumption  
that I/O functions aren't volatile: the consequence is that records or  
arrays containing chkpass elements may have input behavior a bit different  
from a bare chkpass column.  But there seems no way to fix this without  
breaking existing usage patterns for chkpass, and the consequences of the  
inconsistency don't seem bad enough to justify that.  So for the moment,  
just document it in a comment.  
  
Since we're not bumping version numbers, there seems no harm in  
back-patching these fixes; at least future installations will get the  
functions marked correctly.  

commit   : 63ff971e06461e67b8108cf360c4a6eb03adb160    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 4 Nov 2014 16:10:58 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 4 Nov 2014 16:10:58 -0500    

commit   : a192d5d05dd943d8fde0c52f4a924690696daec1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Nov 2014 13:24:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 4 Nov 2014 13:24:10 -0500    

The previous coding assumed that we could just let buffers for the  
database's old tablespace age out of the buffer arena naturally.  
The folly of that is exposed by bug #11867 from Marc Munro: the user could  
later move the database back to its original tablespace, after which any  
still-surviving buffers would match lookups again and appear to contain  
valid data.  But they'd be missing any changes applied while the database  
was in the new tablespace.  
  
This has been broken since ALTER SET TABLESPACE was introduced, so  
back-patch to all supported branches.  

commit   : 21495a2bb7599fb7546b146ca33bd7c6157c1472    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Nov 2014 11:11:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Nov 2014 11:11:34 -0500    

pgp_sym_encrypt's option is spelled "sess-key", not "enable-session-key".  
Spotted by Jeff Janes.  
  
In passing, improve a comment in pgp-pgsql.c to make it clearer that  
the debugging options are intentionally undocumented.  

commit   : f229170c75f0ce64b1b9a0a362571d1f19089de4    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 2 Nov 2014 21:43:30 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 2 Nov 2014 21:43:30 -0500    

The reasons behind commit 0d147e43adcf5d2bff9caa073608f381a27439bf still  
stand, so this reverts the non-cosmetic portion of commit  
a7983e989d9cafc9cef49becfee054e34b1ed9b4.  Back-patch to 9.4, where the  
latter commit first appeared.  

commit   : 63d2c0c573ff2a9ba0391576dc569260b4de5dd9    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 2 Nov 2014 21:43:25 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 2 Nov 2014 21:43:25 -0500    

Cygwin builds require this of dependencies pertaining to pattern rules.  
On Cygwin, stat("foo") in the absence of a file with that exact name can  
locate foo.exe.  While GNU make uses stat() for dependencies of ordinary  
rules, it uses readdir() to assess dependencies of pattern rules.  
Therefore, a pattern rule dependency should match any underlying file  
name exactly.  Back-patch to 9.4, where the dependency was introduced.  

commit   : 94c1dec0d9c1da40ab956520ae093cdad478fcd4    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 2 Nov 2014 21:43:20 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 2 Nov 2014 21:43:20 -0500    

Back-patch to 9.2, like commit db29620d4d16e08241f965ccd70d0f65883ff0de.  

commit   : 25ca2a69eab63729ed3195afbe0d175cf0e54d19    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 2 Nov 2014 20:17:32 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 2 Nov 2014 20:17:32 -0500    

commit   : 16381b2a78e5a3477b5a7ac956b7afc36efdcc58    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 2 Nov 2014 09:14:36 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 2 Nov 2014 09:14:36 -0500    

Don't skip the TAP tests anymore when IPC::Run is not found.  This will  
fail normally now.  

commit   : 4ffa8806ee5187526b592e1918cd17c1cdde802d    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 1 Nov 2014 11:31:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 1 Nov 2014 11:31:35 -0400    

Revert "6f6b46c9c0ca3d96acbebc5499c32ee6369e1eec", which was broken.  
  
Reported-by: Jonathan Rogers <jrogers@socialserve.com>  

commit   : f41ed7b66a621134d5c7c39c74458fbfb1214255    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 31 Oct 2014 08:11:06 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 31 Oct 2014 08:11:06 -0400    

per Andres Freund  

commit   : 1414868d088cfb6cb85d57946f4a460efa7d31c6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 30 Oct 2014 22:52:21 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 30 Oct 2014 22:52:21 -0400    

commit   : 7dacab976917c26cd9b6c4b36e53dbbf8261473b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 30 Oct 2014 22:50:02 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 30 Oct 2014 22:50:02 -0400    

Similar to 590eb0c14eebe834f716721a9659b77899cf3084, remove the options  
list from the synopsis and elaborate in the main description.  

commit   : 7f4ece03d675a2a6cb6cec14f564744b5c01e5a4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Oct 2014 13:03:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Oct 2014 13:03:25 -0400    

As noted by Noah Misch, my initial cut at fixing bug #11638 didn't cover  
all cases where ANALYZE might be invoked in an unsafe context.  We need to  
test the result of IsInTransactionChain not IsTransactionBlock; which is  
notationally a pain because IsInTransactionChain requires an isTopLevel  
flag, which would have to be passed down through several levels of callers.  
I chose to pass in_outer_xact (ie, the result of IsInTransactionChain)  
rather than isTopLevel per se, as that seemed marginally more apropos  
for the intermediate functions to know about.  

commit   : 1c49dae165bcee69bf3327d6ae20271d82cdf6bf    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Oct 2014 11:35:55 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 30 Oct 2014 11:35:55 -0400    

Nobody seemed concerned about this naming when it originally went in,  
but there's a pending patch that implements the opposite of  
dsm_keep_mapping, and the term "unkeep" was judged unpalatable.  
"unpin" has existing precedent in the PostgreSQL code base, and the  
English language, so use this terminology instead.  
  
Per discussion, back-patch to 9.4.  

commit   : ae3eb9b8ef5638610da05038e40229d4f4e5c1fd    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 29 Oct 2014 19:41:19 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 29 Oct 2014 19:41:19 -0400    

They turned out to be too much of a portability headache, because they  
need a fairly new version of Test::More to work properly.  

commit   : 22b3003d70a88644f36cd91446631f474dfbfe41    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Oct 2014 18:12:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Oct 2014 18:12:04 -0400    

VACUUM and ANALYZE update the target table's pg_class row in-place, that is  
nontransactionally.  This is OK, more or less, for the statistical columns,  
which are mostly nontransactional anyhow.  It's not so OK for the DDL hint  
flags (relhasindex etc), which might get changed in response to  
transactional changes that could still be rolled back.  This isn't a  
problem for VACUUM, since it can't be run inside a transaction block nor  
in parallel with DDL on the table.  However, we allow ANALYZE inside a  
transaction block, so if the transaction had earlier removed the last  
index, rule, or trigger from the table, and then we roll back the  
transaction after ANALYZE, the table would be left in a corrupted state  
with the hint flags not set though they should be.  
  
To fix, suppress the hint-flag updates if we are InTransactionBlock().  
This is safe enough because it's always OK to postpone hint maintenance  
some more; the worst-case consequence is a few extra searches of pg_index  
et al.  There was discussion of instead using a transactional update,  
but that would change the behavior in ways that are not all desirable:  
in most scenarios we're better off keeping ANALYZE's statistical values  
even if the ANALYZE itself rolls back.  In any case we probably don't want  
to change this behavior in back branches.  
  
Per bug #11638 from Casey Shobe.  This has been broken for a good long  
time, so back-patch to all supported branches.  
  
Tom Lane and Michael Paquier, initial diagnosis by Andres Freund  

commit   : fcca871203568a4d34bc026029bee51e8d246ae2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 29 Oct 2014 14:32:01 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 29 Oct 2014 14:32:01 +0200    

If you call PQreset() repeatedly, and the connection cannot be  
re-established, the error messages from the failed connection attempts  
kept accumulating in the error string.  
  
Fixes bug #11455 reported by Caleb Epstein. Backpatch to all supported  
versions.  

commit   : d1f8e7a01501c71db3ee0bcd19aab79b1ddc662e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Oct 2014 18:36:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 28 Oct 2014 18:36:02 -0400    

Since we got rid of non-MVCC catalog scans, the fourth reason given for  
using a non-transactional update in index_update_stats() is obsolete.  
The other three are still good, so we're not going to change the code,  
but fix the comment.  

commit   : 3345ba4d0d28435518b5979120618a610dea4e13    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 28 Oct 2014 20:26:20 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 28 Oct 2014 20:26:20 +0200    

Reported by MauMau.  

commit   : c68bff644357c743d14065b8085dbb04d1505c72    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 27 Oct 2014 19:59:39 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 27 Oct 2014 19:59:39 -0400    

Newer toolchains append the extension implicitly if missing, but  
buildfarm member narwhal (gcc 3.4.2, ld 2.15.91 20040904) does not.  
This affects most core libraries having an exports.txt file, namely  
libpq and the ECPG support libraries.  On Windows Server 2003, Windows  
API functions that load and unload DLLs internally will mistakenly  
unload a libpq whose DLL header reports "LIBPQ" instead of "LIBPQ.dll".  
When, subsequently, control would return to libpq, the backend crashes.  
Back-patch to 9.4, like commit 846e91e0223cf9f2821c3ad4dfffffbb929cb027.  
Before that commit, we used a different linking technique that yielded  
"libpq.dll" in the DLL header.  
  
Commit 53566fc0940cf557416b13252df57350a4511ce4 worked around this by  
eliminating a call to a function that loads and unloads DLLs internally.  
That commit is no longer necessary for correctness, but its improving  
consistency with the MSVC build remains valid.  

commit   : 89fbe97fcad3cfbc5d09d2a9f66aaf31e3164b94    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 27 Oct 2014 08:53:16 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 27 Oct 2014 08:53:16 -0400    

Michael Paquier  

commit   : c366e1d169481a780857458f1064ae93007fd140    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Oct 2014 10:50:41 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 27 Oct 2014 10:50:41 +0200    

1. The comparison for matching terms used only the CRC to decide if there's  
a match. Two different terms with the same CRC gave a match.  
  
2. It assumed that if the second operand has more terms than the first, it's  
never a match. That assumption is bogus, because there can be duplicate  
terms in either operand.  
  
Rewrite the implementation in a way that doesn't have those bugs.  
  
Backpatch to all supported versions.  

commit   : c53a82b99d98df393d7ba308bf1586b2201d0d65    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Oct 2014 19:17:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Oct 2014 19:17:57 -0400    

The malloc request was 1 byte too small for the worst-case output.  
This seems relatively unlikely to cause any problems in practice,  
as the worst case only occurs if the input string contains no  
characters other than single-quote or newline, and even then  
malloc alignment padding would probably save the day.  But it's  
definitely a bug.  
  
David Rowley  

commit   : 859e2b9dd4de94ef9a9ad34da3e39572e4f1d66f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Oct 2014 16:12:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Oct 2014 16:12:26 -0400    

Since we taught btree to handle ScalarArrayOpExpr quals natively (commit  
9e8da0f75731aaa7605cf4656c21ea09e84d2eb1), the planner has always included  
ScalarArrayOpExpr quals in index conditions if possible.  However, if the  
qual is for a non-first index column, this could result in an inferior plan  
because we can no longer take advantage of index ordering (cf. commit  
807a40c551dd30c8dd5a0b3bd82f5bbb1e7fd285).  It can be better to omit the  
ScalarArrayOpExpr qual from the index condition and let it be done as a  
filter, so that the output doesn't need to get sorted.  Indeed, this is  
true for the query introduced as a test case by the latter commit.  
  
To fix, restructure get_index_paths and build_index_paths so that we  
consider paths both with and without ScalarArrayOpExpr quals in non-first  
index columns.  Redesign the API of build_index_paths so that it reports  
what it found, saving useless second or third calls.  
  
Report and patch by Andrew Gierth (though rather heavily modified by me).  
Back-patch to 9.2 where this code was introduced, since the issue can  
result in significant performance regressions compared to plans produced  
by 9.1 and earlier.  

commit   : 76e190d52225fc1124efc7d77f773643405b263e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 26 Oct 2014 10:26:36 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 26 Oct 2014 10:26:36 -0400    

Perl 5.12 ships with a somewhat broken version of Test::Simple, so skip  
the tests if that is found.  
  
The relevant fix is  
  
    0.98  Wed, 23 Feb 2011 14:38:02 +1100  
        Bug Fixes  
        * subtest() should not fail if $? is non-zero. (Aaron Crane)  

commit   : 6b531cd077eeacce25106f5456876b57ad68a834    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 26 Oct 2014 09:47:01 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 26 Oct 2014 09:47:01 -0400    

The prove program included in Perl 5.8 does not support the --ext  
option, so don't use that and use wildcards on the command line instead.  
  
Note that the tests will still all be skipped, because, for instance,  
the version of Test::More is too old, but at least the regular  
mechanisms for handling that will apply, instead of failing to call  
prove altogether.  

commit   : c3c2d986977b60e3db26601d44ab029ef99156cc    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 24 Oct 2014 19:56:03 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 24 Oct 2014 19:56:03 +0300    

Windows has one a locale whose name contains a non-ASCII character:  
"Norwegian (Bokmål)" (that's an 'a' with a ring on top). That causes  
trouble; when passing it setlocale(), it's not clear what encoding the  
argument should be in. Another problem is that the locale name is stored in  
pg_database catalog table, and the encoding used there depends on what  
server encoding happens to be in use when the database is created. For  
example, if you issue the CREATE DATABASE when connected to a UTF-8  
database, the locale name is stored in pg_database in UTF-8. As long as all  
locale names are pure ASCII, that's not a problem.  
  
To work around that, map the troublesome locale name to a pure-ASCII alias  
of the same locale, "norwegian-bokmal".  
  
Now, this doesn't change the existing values that are already in  
pg_database and in postgresql.conf. Old clusters will need to be fixed  
manually. Instructions for that need to be put in the release notes.  
  
This fixes bug #11431 reported by Alon Siman-Tov. Backpatch to 9.2;  
backpatching further would require more work than seems worth it.  

commit   : 4bdf5e57552456d0d12e33ead0dbfc124f4d4b81    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 24 Oct 2014 19:26:44 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 24 Oct 2014 19:26:44 +0300    

If the locale names are not equal, try to canonicalize both of them by  
passing them to setlocale(). Before, we only canonicalized the old cluster's  
locale if upgrading from a 8.4-9.2 server, but we also need to canonicalize  
when upgrading from a pre-8.4 server. That was an oversight in the code. But  
we should also canonicalize on newer server versions, so that we cope if the  
canonical form changes from one release to another. I'm about to do just  
that to fix bug #11431, by mapping a locale name that contains non-ASCII  
characters to a pure-ASCII alias of the same locale.  
  
This is partial backpatch of commit 33755e8edf149dabfc0ed9b697a84f70b0cca0de  
in master. Apply to 9.2, 9.3 and 9.4. The canonicalization code didn't exist  
before 9.2. In 9.2 and 9.3, this effectively also back-patches the changes  
from commit 58274728fb8e087049df67c0eee903d9743fdeda, to be more lax about  
the spelling of the encoding in the locale names.  

commit   : 1cf54b00ba2100083390223a8244430643c1ec07    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Oct 2014 13:11:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Oct 2014 13:11:31 -0400    

Don't crash if an ispell dictionary definition contains flags but not  
any compound affixes.  (This isn't a security issue since only superusers  
can install affix files, but still it's a bad thing.)  
  
Also, be more careful about detecting whether an affix-file FLAG command  
is old-format (ispell) or new-format (myspell/hunspell).  And change the  
error message about mixed old-format and new-format commands into something  
intelligible.  
  
Per bug #11770 from Emre Hasegeli.  Back-patch to all supported branches.  

commit   : 6d12cc1f01c867fd7317ac5580b02c04f313d9ce    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 23 Oct 2014 16:21:27 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 23 Oct 2014 16:21:27 +0900    

Previously the archive recovery always created .ready file for  
the last WAL file of the old timeline at the end of recovery even when  
it's restored from the archive and has .done file. That is, there was  
the case where the WAL file had both .ready and .done files.  
This caused the already-archived WAL file to be archived again.  
  
This commit prevents the archive recovery from creating .ready file  
for the last WAL file if it has .done file, in order to prevent it from  
being archived again.  
  
This bug was added when cascading replication feature was introduced,  
i.e., the commit 5286105800c7d5902f98f32e11b209c471c0c69c.  
So, back-patch to 9.2, where cascading replication was added.  
  
Reviewed by Michael Paquier  

commit   : b53942e59644d79c2df7951523a50dc4d2d97668    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Oct 2014 18:41:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Oct 2014 18:41:47 -0400    

The EOF-detection logic in pqReadData was a bit confused about who should  
set up the error message in case the kernel gives us read-ready-but-no-data  
rather than ECONNRESET or some other explicit error condition.  Since the  
whole point of this situation is that the lower-level functions don't know  
there's anything wrong, pqReadData itself must set up the message.  But  
keep the assumption that if an errno was reported, a message was set up at  
lower levels.  
  
Per bug #11712 from Marko Tiikkaja.  It's been like this for a very long  
time, so back-patch to all supported branches.  

commit   : 2f51f424bb362dadeb4fabf03845961e563da4ba    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 21 Oct 2014 22:55:47 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 21 Oct 2014 22:55:47 -0400    

When commit 846e91e0223cf9f2821c3ad4dfffffbb929cb027 switched the linker  
driver from dlltool/dllwrap to gcc, it became possible for linking to  
choose shared libgcc.  Backends having loaded a module dynamically  
linked to libgcc can exit abnormally, which the postmaster treats like a  
crash.  Resume use of static libgcc exclusively, like 9.3 and earlier.  
Back-patch to 9.4.  

commit   : 9e02e20ab6df093e1ab751157dfb5c51a420187b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 21 Oct 2014 22:55:43 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 21 Oct 2014 22:55:43 -0400    

This improves consistency with the MSVC build.  On buildfarm member  
narwhal, since commit 846e91e0223cf9f2821c3ad4dfffffbb929cb027,  
shfolder.dll:SHGetFolderPath() crashes when dblink calls it by way of  
pqGetHomeDirectory().  Back-patch to 9.4, where that commit first  
appeared.  How it caused this regression remains a mystery.  This is a  
partial revert of commit 889f03812916b146ae504c0fad5afdc7bf2e8a2a, which  
adopted shfolder.dll for Windows NT 4.0 compatibility.  PostgreSQL 8.2  
dropped support for that operating system.  

commit   : 7a14edb83e1c5c3c683cf0c8a90870e3bda9d22c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Oct 2014 18:26:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Oct 2014 18:26:01 -0400    

The last three updates to the sequence regression test have all forgotten  
to touch the alternate expected-output file.  Sigh.  
  
Michael Paquier  

commit   : 5607e996f4ba93a4c56ea94f10d1fcc876b4bf42    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 20 Oct 2014 23:43:46 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 20 Oct 2014 23:43:46 +0200    

CREATE DATABASE and ALTER DATABASE .. SET TABLESPACE copy the source  
database directory on the filesystem level. To ensure the on disk  
state is consistent they block out users of the affected database and  
force a checkpoint to flush out all data to disk. Unfortunately, up to  
now, that checkpoint didn't flush out dirty buffers from unlogged  
relations.  
  
That bug means there could be leftover dirty buffers in either the  
template database, or the database in its old location. Leading to  
problems when accessing relations in an inconsistent state; and to  
possible problems during shutdown in the SET TABLESPACE case because  
buffers belonging files that don't exist anymore are flushed.  
  
This was reported in bug #10675 by Maxim Boguk.  
  
Fix by Pavan Deolasee, modified somewhat by me. Reviewed by MauMau and  
Fujii Masao.  
  
Backpatch to 9.1 where unlogged tables were introduced.  

commit   : 6e0a053a963024698de8ba315eed7455520d1a92    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 20 Oct 2014 14:55:35 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 20 Oct 2014 14:55:35 -0400    

json_agg and json_object_agg and their associated transition functions  
should have been marked as stable rather than immutable, as they call IO  
functions indirectly. Changing this probably isn't going to make much  
difference, as you can't use an aggregate function in an index  
expression, but we should be correct nevertheless.  
  
json_object, on the other hand, should be marked immutable rather than  
stable, as it does not call IO functions.  
  
As discussed on -hackers, this change is being made without bumping the  
catalog version, as we don't want to do that at this stage of the  cycle,  
and  the changes are very unlikely to affect anyone.  

commit   : 33343b862ce17ff51699789625684d0cccd60ede    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Oct 2014 12:23:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Oct 2014 12:23:44 -0400    

If an inline-able SQL function taking a composite argument is used in a  
LATERAL subselect, and the composite argument is a lateral reference,  
the planner could fail with "variable not found in subplan target list",  
as seen in bug #11703 from Karl Bartel.  (The outer function call used in  
the bug report and in the committed regression test is not really necessary  
to provoke the bug --- you can get it if you manually expand the outer  
function into "LATERAL (SELECT inner_function(outer_relation))", too.)  
  
The cause of this is that we generate the reltargetlist for the referenced  
relation before doing eval_const_expressions() on the lateral sub-select's  
expressions (cf find_lateral_references()), so what's scheduled to be  
emitted by the referenced relation is a whole-row Var, not the simplified  
single-column Var produced by optimizing the function's FieldSelect on the  
whole-row Var.  Then setrefs.c fails to match up that lateral reference to  
what's available from the outer scan.  
  
Preserving the FieldSelect optimization in such cases would require either  
major planner restructuring (to recursively do expression simplification  
on sub-selects much earlier) or some amazingly ugly kluge to change the  
reltargetlist of a possibly-already-planned relation.  It seems better  
just to skip the optimization when the Var is from an upper query level;  
the case is not so common that it's likely anyone will notice a few  
wasted cycles.  
  
AFAICT this problem only occurs for uplevel LATERAL references, so  
back-patch to 9.3 where LATERAL was added.  

commit   : 48b2d88c10746257c77a8c4c2f645ccfc6bb0afe    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 18 Oct 2014 21:58:17 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 18 Oct 2014 21:58:17 -0400    

Revert the output of the individual backslash commands that change print  
settings back to the 9.3 way (not showing the command name in  
parentheses).  Implement \pset without arguments separately, showing all  
settings with values in a table form.  

commit   : 5c8758e6ed54ff9e2c5ec72af619bbd52578659c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 18 Oct 2014 09:10:12 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 18 Oct 2014 09:10:12 -0400    

This needed a general cleanup of wording, typos, outdated terminology,  
formatting, and hard-to-understand and borderline incorrect information.  
  
Also tweak the pg_receivexlog page a bit to make the two more  
consistent.  

commit   : b45f048ed899502c982f249d90608ca09b7939e7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Oct 2014 22:55:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Oct 2014 22:55:23 -0400    

Follow our usual style of providing an "extern" for a standard library  
function only when we're also providing the implementation.  This avoids  
issues when the system headers declare the function slightly differently  
than we do, as noted by Caleb Welton.  
  
We might have to go to the extent of probing to see if the system headers  
declare the function, but let's not do that until it's demonstrated to be  
necessary.  
  
Oversight in commit 9e6b1bf258170e62dac555fc82ff0536dfe01d29.  Back-patch  
to all supported branches, as that was.  

commit   : 16bbe5a3cc937096a4ad0dab050360eb87e0c813    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Oct 2014 22:33:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Oct 2014 22:33:04 -0400    

Nearly all Paths have parents, but a ResultPath representing an empty FROM  
clause does not.  Avoid a core dump in such cases.  I believe this is only  
a hazard for debugging usage, not for production, else we'd have heard  
about it before.  Nonetheless, back-patch to 9.1 where the troublesome code  
was introduced.  Noted while poking at bug #11703.  

commit   : 3205b30bb7a82c8228230a15308a56b302603521    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Oct 2014 12:49:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Oct 2014 12:49:03 -0400    

This reverts nearly all of commit 28f6cab61ab8958b1a7dfb019724687d92722538  
in favor of just using the typrelid we already have in pg_dump's TypeInfo  
struct for the composite type.  As coded, it'd crash if the composite type  
had no attributes, since then the query would return no rows.  
  
Back-patch to all supported versions.  It seems to not really be a problem  
in 9.0 because that version rejects the syntax "create type t as ()", but  
we might as well keep the logic similar in all affected branches.  
  
Report and fix by Rushabh Lathia.  

commit   : 4b3b44b141a0163ca15fd3eb38589a5aefc499bd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Oct 2014 15:22:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Oct 2014 15:22:13 -0400    

Up to now, PG has assumed that any given timezone abbreviation (such as  
"EDT") represents a constant GMT offset in the usage of any particular  
region; we had a way to configure what that offset was, but not for it  
to be changeable over time.  But, as with most things horological, this  
view of the world is too simplistic: there are numerous regions that have  
at one time or another switched to a different GMT offset but kept using  
the same timezone abbreviation.  Almost the entire Russian Federation did  
that a few years ago, and later this month they're going to do it again.  
And there are similar examples all over the world.  
  
To cope with this, invent the notion of a "dynamic timezone abbreviation",  
which is one that is referenced to a particular underlying timezone  
(as defined in the IANA timezone database) and means whatever it currently  
means in that zone.  For zones that use or have used daylight-savings time,  
the standard and DST abbreviations continue to have the property that you  
can specify standard or DST time and get that time offset whether or not  
DST was theoretically in effect at the time.  However, the abbreviations  
mean what they meant at the time in question (or most recently before that  
time) rather than being absolutely fixed.  
  
The standard abbreviation-list files have been changed to use this behavior  
for abbreviations that have actually varied in meaning since 1970.  The  
old simple-numeric definitions are kept for abbreviations that have not  
changed, since they are a bit faster to resolve.  
  
While this is clearly a new feature, it seems necessary to back-patch it  
into all active branches, because otherwise use of Russian zone  
abbreviations is going to become even more problematic than it already was.  
This change supersedes the changes in commit 513d06ded et al to modify the  
fixed meanings of the Russian abbreviations; since we've not shipped that  
yet, this will avoid an undesirably incompatible (not to mention incorrect)  
change in behavior for timestamps between 2011 and 2014.  
  
This patch makes some cosmetic changes in ecpglib to keep its usage of  
datetime lookup tables as similar as possible to the backend code, but  
doesn't do anything about the increasingly obsolete set of timezone  
abbreviation definitions that are hard-wired into ecpglib.  Whatever we  
do about that will likely not be appropriate material for back-patching.  
Also, a potential free() of a garbage pointer after an out-of-memory  
failure in ecpglib has been fixed.  
  
This patch also fixes pre-existing bugs in DetermineTimeZoneOffset() that  
caused it to produce unexpected results near a timezone transition, if  
both the "before" and "after" states are marked as standard time.  We'd  
only ever thought about or tested transitions between standard and DST  
time, but that's not what's happening when a zone simply redefines their  
base GMT offset.  
  
In passing, update the SGML documentation to refer to the Olson/zoneinfo/  
zic timezone database as the "IANA" database, since it's now being  
maintained under the auspices of IANA.  

commit   : 9bb6b7c5ed617b34edf1a962c9405359822418d3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Oct 2014 18:50:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Oct 2014 18:50:16 -0400    

We've gotten enough push-back on that change to make it clear that it  
wasn't an especially good idea to do it like that.  Revert plain EXPLAIN  
to its previous behavior, but keep the extra output in EXPLAIN ANALYZE.  
Per discussion.  
  
Internally, I set this up as a separate flag ExplainState.summary that  
controls printing of planning time and execution time.  For now it's  
just copied from the ANALYZE option, but we could consider exposing it  
to users.  

commit   : 4971c36b46c63c0b36a38df6a4b6ad9f303e4620    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 Oct 2014 10:01:00 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 Oct 2014 10:01:00 +0300    

LWLockAcquireWithVar needs to set the protected variable while holding  
the spinlock. Need to use a volatile pointer to make sure it doesn't get  
reordered by the compiler. The other functions that accessed the protected  
variable already got this right.  
  
9.4 only. Earlier releases didn't have this code, and in master, spinlock  
release acts as a compiler barrier.  

commit   : 4dbc7606cfc8188646a2e302ef5e6a5ec3c962af    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 Oct 2014 09:55:26 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 Oct 2014 09:55:26 +0300    

LWLockRelease should release all backends waiting with LWLockWaitForVar,  
even when another backend has already been woken up to acquire the lock,  
i.e. when releaseOK is false. LWLockWaitForVar can return as soon as the  
protected value changes, even if the other backend will acquire the lock.  
Fix that by resetting releaseOK to true in LWLockWaitForVar, whenever  
adding itself to the wait queue.  
  
This should fix the bug reported by MauMau, where the system occasionally  
hangs when there is a lot of concurrent WAL activity and a checkpoint.  
Backpatch to 9.4, where this code was added.  

commit   : 79ec6e399f1377a56633c0e4b4c8ed768c230ec2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 Oct 2014 09:45:00 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 14 Oct 2014 09:45:00 +0300    

Shigeru Hanada  

commit   : 590eb0c14eebe834f716721a9659b77899cf3084    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 13 Oct 2014 22:17:34 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 13 Oct 2014 22:17:34 -0400    

The way the ALTER VIEW / SET options were listed in the synopsis was  
very confusing.  Move the list to the main description, similar to how  
the ALTER TABLE reference page does it.  

commit   : 44992e68375a27410089ad43a706ffa80f311783    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 13 Oct 2014 22:10:01 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 13 Oct 2014 22:10:01 -0400    

commit   : ec757c2735fdc6e845fd9edd8da65db35d9c4836    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 13 Oct 2014 22:07:30 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 13 Oct 2014 22:07:30 -0400    

This was inadvertently changed in commit c64e68fd.  

commit   : 4b9d7ccab3fc180ca9830a92688c1b560a01b720    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Oct 2014 23:33:37 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Oct 2014 23:33:37 -0400    

The previous quoting caused "make -C src/bin check" to ignore, rather  
than add to, any LD_LIBRARY_PATH content from the environment.  
Back-patch to 9.4, where the macro was introduced.  

commit   : 62698dae6b4fd066f8d4e4a4f0a41c3155769d3d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Oct 2014 23:27:06 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 12 Oct 2014 23:27:06 -0400    

This file used __int64, which is specific to native Windows, rather than  
int64.  Suppress the long-unused union field of this type.  Noticed on  
Cygwin x86_64 with -lcrypt not installed.  Back-patch to 9.0 (all  
supported versions).  

commit   : 1b031ae62e7cdf2f99848cd35cdb2166babdaa87    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 12 Oct 2014 01:45:25 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 12 Oct 2014 01:45:25 -0400    

List the actions first, as they are the most important options.  Group  
the other options more sensibly, consistent with the man page.  Correct  
a few typographical errors, clarify some things.  
  
Also update the pg_receivexlog --help output to make it a bit more  
consistent with that of pg_recvlogical.  

commit   : 7ce2a45aeb12d3d32a5b5e334f99a67264613fc1    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 12 Oct 2014 01:02:56 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 12 Oct 2014 01:02:56 -0400    

commit   : 308ab77b89ec1662f24b5ab4013ff0d1bd4153a1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Oct 2014 14:29:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Oct 2014 14:29:51 -0400    

Per gripe from Josh Berkus.  

commit   : 86b889494a71bd6c9574de04d6612d367bc5a423    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Oct 2014 14:13:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Oct 2014 14:13:54 -0400    

When determining whether one JSONB object contains another, it's okay to  
make a quick exit if the first object has fewer pairs than the second:  
because we de-duplicate keys within objects, it is impossible that the  
first object has all the keys the second does.  However, the code was  
applying this rule to JSONB arrays as well, where it does *not* hold  
because arrays can contain duplicate entries.  The test was really in  
the wrong place anyway; we should do it within JsonbDeepContains, where  
it can be applied to nested objects not only top-level ones.  
  
Report and test cases by Alexander Korotkov; fix by Peter Geoghegan and  
Tom Lane.  

commit   : a0c58b55220f190e8be9cfe0cadb4d478e13fac2    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 10 Oct 2014 03:18:01 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 10 Oct 2014 03:18:01 +0900    

Back-patch to all supported branches.  
  
Marti Raudsepp, per a report from Marko Tiikkaja  

commit   : 80ddb590b6729fb398cad00b0774f2d10e954b0d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Oct 2014 21:23:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Oct 2014 21:23:20 -0400    

The code wrote a value into the caller's field[] array before checking  
to see if there was room, which of course is backwards.  Per report from  
Michael Paquier.  
  
I fixed the equivalent bug in the backend's version of this code way back  
in 630684d3a130bb93, but failed to think about ecpg's copy.  Fortunately  
this doesn't look like it would be exploitable for anything worse than a  
core dump: an external attacker would have no control over the single word  
that gets written.  

commit   : abc1a8e509180a96dab45538643abeb25a955190    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Oct 2014 14:32:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Oct 2014 14:32:17 -0400    

commit   : 0cd700477466d260ed9c61d0af87df18f7cbfd1a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 6 Oct 2014 12:11:52 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 6 Oct 2014 12:11:52 +0200    

A future patch (9.5 only) adds slot management to pg_receivexlog. The  
verbs create/drop don't seem descriptive enough there. It seems better  
to rename pg_recvlogical's commands now, in beta, than live with the  
inconsistency forever.  
  
The old form (e.g. --drop) will still be accepted by virtue of most  
getopt_long() options accepting abbreviations for long commands.  
  
Backpatch to 9.4 where pg_recvlogical was introduced.  
  
Author: Michael Paquier and Andres Freund  
Discussion: CAB7nPqQtt79U6FmhwvgqJmNyWcVCbbV-nS72j_jyPEopERg9rg@mail.gmail.com  

commit   : 6af3a67235ba6d31819bc7e4a2dae151721dc257    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 5 Oct 2014 23:22:24 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 5 Oct 2014 23:22:24 -0400    

commit   : 0e7cb5fbd2f4fcdadfe697d5ed92b9b82e3529ef    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Oct 2014 14:14:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Oct 2014 14:14:07 -0400    

Add entries for recent changes, including noting the JSONB format change  
and the recent timezone data changes.  We should remove those two items  
before 9.4 final: the JSONB change will be of no interest in the long  
run, and it's not normally our habit to mention timezone updates in  
major-release notes.  But it seems important to document them temporarily  
for beta testers.  
  
I failed to resist the temptation to wordsmith a couple of existing  
entries, too.  

commit   : c6fda5a19f7d43089801f445733d48ba2a7229d4    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Sat, 4 Oct 2014 21:25:41 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Sat, 4 Oct 2014 21:25:41 -0400    

Teach sigusr1_handler() to use the same test for whether a worker  
might need to be started as ServerLoop().  Aside from being perhaps  
a bit simpler, this prevents a potentially-unbounded delay when  
starting a background worker.  On some platforms, select() doesn't  
return when interrupted by a signal, but is instead restarted,  
including a reset of the timeout to the originally-requested value.  
If signals arrive often enough, but no connection requests arrive,  
sigusr1_handler() will be executed repeatedly, but the body of  
ServerLoop() won't be reached.  This change ensures that, even in  
that case, background workers will eventually get launched.  
  
This is far from a perfect fix; really, we need select() to return  
control to ServerLoop() after an interrupt, either via the self-pipe  
trick or some other mechanism.  But that's going to require more  
work and discussion, so let's do this for now to at least mitigate  
the damage.  
  
Per investigation of test_shm_mq failures on buildfarm member anole.  

commit   : bb7c8f99ac829c5fe5d3bd3a20b2642d55abdb62    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Oct 2014 14:18:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Oct 2014 14:18:29 -0400    

Most zones in the Russian Federation are subtracting one or two hours  
as of 2014-10-26.  Update the meanings of the abbreviations IRKT, KRAT,  
MAGT, MSK, NOVT, OMST, SAKT, VLAT, YAKT, YEKT to match.  
  
The IANA timezone database has adopted abbreviations of the form AxST/AxDT  
for all Australian time zones, reflecting what they believe to be current  
majority practice Down Under.  These names do not conflict with usage  
elsewhere (other than ACST for Acre Summer Time, which has been in disuse  
since 1994).  Accordingly, adopt these names into our "Default" timezone  
abbreviation set.  The "Australia" abbreviation set now contains only  
CST,EAST,EST,SAST,SAT,WST, all of which are thought to be mostly historical  
usage.  Note that SAST has also been changed to be South Africa Standard  
Time in the "Default" abbreviation set.  
  
Add zone abbreviations SRET (Asia/Srednekolymsk) and XJT (Asia/Urumqi),  
and use WSST/WSDT for western Samoa.  
  
Also a DST law change in the Turks & Caicos Islands (America/Grand_Turk),  
and numerous corrections for historical time zone data.  

commit   : d13913c820c2b6ea418d51106c199d01c50eb14b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Oct 2014 17:44:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Oct 2014 17:44:38 -0400    

This updates known_abbrevs.txt to be what it should have been already,  
were my -P patch not broken; and updates some tznames/ entries that  
missed getting any love in previous timezone data updates because zic  
failed to flag the change of abbreviation.  
  
The non-cosmetic updates:  
  
* Remove references to "ADT" as "Arabia Daylight Time", an abbreviation  
that's been out of use since 2007; therefore, claiming there is a conflict  
with "Atlantic Daylight Time" doesn't seem especially helpful.  (We have  
left obsolete entries in the files when they didn't conflict with anything,  
but that seems like a different situation.)  
  
* Fix entirely incorrect GMT offsets for CKT (Cook Islands), FJT, FJST  
(Fiji); we didn't even have them on the proper side of the date line.  
(Seems to have been aboriginal errors in our tznames data; there's no  
evidence anything actually changed recently.)  
  
* FKST (Falkland Islands Summer Time) is now used all year round, so  
don't mark it as a DST abbreviation.  
  
* Update SAKT (Sakhalin) to mean GMT+11 not GMT+10.  
  
In cosmetic changes, I fixed a bunch of wrong (or at least obsolete)  
claims about abbreviations not being present in the zic files, and  
tried to be consistent about how obsolete abbreviations are labeled.  
  
Note the underlying timezone/data files are still at release 2014e;  
this is just trying to get us in sync with what those files actually  
say before we go to the next update.  

commit   : 03163139c9553c6ee4c26a73e21aaef5da22be45    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Oct 2014 14:48:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Oct 2014 14:48:11 -0400    

The quick hack I added to zic to dump out currently-in-use timezone  
abbreviations turns out to have a nasty bug: within each zone, it was  
printing the last "struct ttinfo" to be *defined*, not necessarily the  
last one in use.  This was mainly a problem in zones that had changed the  
meaning of their zone abbreviation (to another GMT offset value) and later  
changed it back.  
  
As a result of this error, we'd missed out updating the tznames/ files  
for some jurisdictions that have changed their zone abbreviations since  
the tznames/ files were originally created.  I'll address the missing data  
updates in a separate commit.  

commit   : 23a8cae6bcdadb1569336cf911cbeb772fda099b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 3 Oct 2014 13:01:27 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 3 Oct 2014 13:01:27 -0300    

When there are cost-delay-related storage options set for a table,  
trying to make that table participate in the autovacuum cost-limit  
balancing algorithm produces undesirable results: instead of using the  
configured values, the global values are always used,  
as illustrated by Mark Kirkwood in  
http://www.postgresql.org/message-id/52FACF15.8020507@catalyst.net.nz  
  
Since the mechanism is already complicated, just disable it for those  
cases rather than trying to make it cope.  There are undesirable  
side-effects from this too, namely that the total I/O impact on the  
system will be higher whenever such tables are vacuumed.  However, this  
is seen as less harmful than slowing down vacuum, because that would  
cause bloat to accumulate.  Anyway, in the new system it is possible to  
tweak options to get the precise behavior one wants, whereas with the  
previous system one was simply hosed.  
  
This has been broken forever, so backpatch to all supported branches.  
This might affect systems where cost_limit and cost_delay have been set  
for individual tables.  

commit   : 925e10dc57cdf0efb7268a65b411f1e58ac5116d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 3 Oct 2014 12:07:10 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 3 Oct 2014 12:07:10 +0300    

The page splitting code would go into infinite recursion if you try to  
insert an index tuple that doesn't fit even on an empty page.  
  
Per analysis and suggested fix by Andrew Gierth. Fixes bug #11555, reported  
by Bryan Seitz (analysis happened over IRC). Backpatch to all supported  
versions.  

commit   : 80f9a368be91d179cddd9666f8cb66132e52727d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 2 Oct 2014 15:51:31 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 2 Oct 2014 15:51:31 +0300    

commit   : 07afbca2e7e8b1699ea2dc7b581d59c99287fff8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Oct 2014 19:30:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Oct 2014 19:30:27 -0400    

As of commit a87c72915 (which later got backpatched as far as 9.1),  
we're explicitly supporting the notion that append relations can be  
nested; this can occur when UNION ALL constructs are nested, or when  
a UNION ALL contains a table with inheritance children.  
  
Bug #11457 from Nelson Page, as well as an earlier report from Elvis  
Pranskevichus, showed that there were still nasty bugs associated with such  
cases: in particular the EquivalenceClass mechanism could try to generate  
"join" clauses connecting an appendrel child to some grandparent appendrel,  
which would result in assertion failures or bogus plans.  
  
Upon investigation I concluded that all current callers of  
find_childrel_appendrelinfo() need to be fixed to explicitly consider  
multiple levels of parent appendrels.  The most complex fix was in  
processing of "broken" EquivalenceClasses, which are ECs for which we have  
been unable to generate all the derived equality clauses we would like to  
because of missing cross-type equality operators in the underlying btree  
operator family.  That code path is more or less entirely untested by  
the regression tests to date, because no standard opfamilies have such  
holes in them.  So I wrote a new regression test script to try to exercise  
it a bit, which turned out to be quite a worthwhile activity as it exposed  
existing bugs in all supported branches.  
  
The present patch is essentially the same as far back as 9.2, which is  
where parameterized paths were introduced.  In 9.0 and 9.1, we only need  
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to  
propagate out the original WHERE clauses when a broken EC contains constant  
members.  (The regression test case results show that these older branches  
are noticeably stupider than 9.2+ in terms of the quality of the plans  
generated; but we don't really care about plan quality in such cases,  
only that the plan not be outright wrong.  A more invasive fix in the  
older branches would not be a good idea anyway from a plan-stability  
standpoint.)  

commit   : 6d89b0860cba23761db3d08523c28e4da79bcbcd    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 1 Oct 2014 19:24:50 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 1 Oct 2014 19:24:50 +0200    

Unfortunately I mistakenly split the commit wrongly into two parts,  
leaving one part of renaming StreamLog to StreamLogicalLog in the  
second commit. Which isn't backported to 9.4...  
Fix it in 9.4 only, as master already is 'fixed' by the subsequent  
commit.  
  
Noticed by Jan Wieck and the buildfarm.  

commit   : 0cadfee37fba0e60a763c62b2d9010b9a2f15b5e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 29 Sep 2014 15:35:40 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 29 Sep 2014 15:35:40 +0200    

Several comments still referred to 'initiating', 'freeing', 'stopping'  
replication slots. These were terms used during different phases of  
the development of logical decoding, but are no long accurate.  
  
Also rename StreamLog() to StreamLogicalLog() and add 'void' to the  
prototype.  
  
Author: Michael Paquier, with some editing by me.  
  
Backpatch to 9.4 where pg_recvlogical was introduced.  

commit   : fc0acf43878bcd70dc1b701b054521d8553d2088    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 1 Oct 2014 16:37:15 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 1 Oct 2014 16:37:15 +0300    

I left the GUC in place for the beta period, so that people could experiment  
with different values. No-one's come up with any data that a different value  
would be better under some circumstances, so rather than try to document to  
users what the GUC, let's just hard-code the current value, 8.  

commit   : e14ed8e2f5382185c9cd0215bf88dc90eb1907cb    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 1 Oct 2014 14:23:43 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 1 Oct 2014 14:23:43 +0200    

DetermineSleepTime() was previously called without blocked  
signals. That's not good, because it allows signal handlers to  
interrupt its workings.  
  
DetermineSleepTime() was added in 9.3 with the addition of background  
workers (da07a1e856511), where it only read from  
BackgroundWorkerList.  
  
Since 9.4, where dynamic background workers were added (7f7485a0cde),  
the list is also manipulated in DetermineSleepTime(). That's bad  
because the list now can be persistently corrupted if modified by both  
a signal handler and DetermineSleepTime().  
  
This was discovered during the investigation of hangs on buildfarm  
member anole. It's unclear whether this bug is the source of these  
hangs or not, but it's worth fixing either way. I have confirmed that  
it can cause crashes.  
  
It luckily looks like this only can cause problems when bgworkers are  
actively used.  
  
Discussion: 20140929193733.GB14400@awork2.anarazel.de  
  
Backpatch to 9.3 where background workers were introduced.  

commit   : ce84b0682cd169738797f74ec8acc1701b9da40c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 1 Oct 2014 13:13:59 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 1 Oct 2014 13:13:59 +0200    

Discussion: CAB7nPqQrqFzjqCjxu4GZzTrD9kpj6HMn9G5aOOMwt1WZ8NfqeA@mail.gmail.com,  
    CAB7nPqQXc_+g95zWnqaa=mVQ4d3BVRs6T41frcEYi2ocUrR3+A@mail.gmail.com  
  
Per discussion between Michael Paquier, Robert Haas and Andres Freund  
  
Backpatch to 9.4 where logical decoding was introduced.  

commit   : f78319fec8eb8aed34d6e1e43ca35fb0a9bfe108    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 1 Oct 2014 11:54:05 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 1 Oct 2014 11:54:05 +0200    

As noted in http://bugs.debian.org/763098 there is a conflict between  
postgres' definition of CACHE_LINE_SIZE and the definition by various  
*bsd platforms. It's debatable who has the right to define such a  
name, but postgres' use was only introduced in 375d8526f290 (9.4), so  
it seems like a good idea to rename it.  
  
Discussion: 20140930195756.GC27407@msg.df7cb.de  
  
Per complaint of Christoph Berg in the above email, although he's not  
the original bug reporter.  
  
Backpatch to 9.4 where the define was introduced.  

commit   : 721a8bb54602624b24d416f8d9b7b8f97701ecbd    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 30 Sep 2014 15:55:28 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 30 Sep 2014 15:55:28 -0400    

The COPY documentation incorrectly stated, for the PROGRAM case,  
that we read from stdin and wrote to stdout.  Fix that, and improve  
consistency by referring to the 'PostgreSQL' user instead of the  
'postgres' user, as is done in the rest of the COPY documentation.  
  
Pointed out by Peter van Dijk.  
  
Back-patch to 9.3 where COPY .. PROGRAM was introduced.  

commit   : 5f4f66f67184cc4696ffa3babcad868d34fd557a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 30 Sep 2014 12:06:37 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 30 Sep 2014 12:06:37 -0300    

This was born broken in 9067310cc5dd590e36c2c3219dbf3961d7c9f8cb.  
  
Per trouble report from Joachim Wieland.  
  
Pavel Stěhule and Álvaro Herrera  

commit   : 6f1310024d20bdaf54edb1ab212c1428ebb300d4    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 29 Sep 2014 20:19:59 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 29 Sep 2014 20:19:59 -0400    

Backpatch through 9.4  

commit   : f6b7d4fbbb72cedd53adb3bf10428dab559bb909    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Sep 2014 12:29:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Sep 2014 12:29:24 -0400    

The original design used an array of offsets into the variable-length  
portion of a JSONB container.  However, such an array is basically  
uncompressible by simple compression techniques such as TOAST's LZ  
compressor.  That's bad enough, but because the offset array is at the  
front, it tended to trigger the give-up-after-1KB heuristic in the TOAST  
code, so that the entire JSONB object was stored uncompressed; which was  
the root cause of bug #11109 from Larry White.  
  
To fix without losing the ability to extract a random array element in O(1)  
time, change this scheme so that most of the JEntry array elements hold  
lengths rather than offsets.  With data that's compressible at all, there  
tend to be fewer distinct element lengths, so that there is scope for  
compression of the JEntry array.  Every N'th entry is still an offset.  
To determine the length or offset of any specific element, we might have  
to examine up to N preceding JEntrys, but that's still O(1) so far as the  
total container size is concerned.  Testing shows that this cost is  
negligible compared to other costs of accessing a JSONB field, and that  
the method does largely fix the incompressible-data problem.  
  
While at it, rearrange the order of elements in a JSONB object so that  
it's "all the keys, then all the values" not alternating keys and values.  
This doesn't really make much difference right at the moment, but it will  
allow providing a fast path for extracting individual object fields from  
large JSONB values stored EXTERNAL (ie, uncompressed), analogously to the  
existing optimization for substring extraction from large EXTERNAL text  
values.  
  
Bump catversion to denote the incompatibility in on-disk format.  
We will need to fix pg_upgrade to disallow upgrading jsonb data stored  
with 9.4 betas 1 and 2.  
  
Heikki Linnakangas and Tom Lane  

commit   : 4e23c47a3bb7a198c87940b6e9ac96edfa53962b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Sep 2014 11:21:35 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 26 Sep 2014 11:21:35 -0400    

Without this fix, parallel restore of a schema-only dump can deadlock,  
because when the dump is schema-only, the dependency will still be  
pointing at the TABLE item rather than the TABLE DATA item.  
  
Robert Haas and Tom Lane  

commit   : d99d0e60eaa8334b698a070cb919202607660a65    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 25 Sep 2014 15:08:42 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 25 Sep 2014 15:08:42 -0400    

We removed a similar ban on this in json_object recently, but the ban in  
datum_to_json was left, which generate4d sprutious errors in othee json  
generators, notable json_build_object.  
  
Along the way, add an assertion that datum_to_json is not passed a null  
key. All current callers comply with this rule, but the assertion will  
catch any possible future misbehaviour.  

commit   : 2024ead21b8ac64f0d6cd13d0c1c2cb8d596238e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 25 Sep 2014 15:22:26 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 25 Sep 2014 15:22:26 +0200    

Some compilers don't automatically search the current directory for  
included files. 9cc2c182fc2 fixed that for builds from tarballs by  
adding an include to the source directory. But that doesn't work when  
the scanner is generated in the VPATH directory. Use the same search  
path as the other parsers in the tree.  
  
One compiler that definitely was affected is solaris' sun cc.  
  
Backpatch to 9.1 which introduced using an actual parser for  
replication commands.  

commit   : bda1d14360404ef58c4647888032158991051b14    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 25 Sep 2014 08:18:18 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 25 Sep 2014 08:18:18 -0400    

This makes it consistent with the docs and with all other builtin  
aggregates apart from count().  

commit   : 54b8ed6c24736d7ad55f56dbaa2696ae05c4bded    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Sep 2014 15:59:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Sep 2014 15:59:37 -0400    

This function created new Vars with varno different from varnoold, which  
is a condition that should never prevail before setrefs.c does the final  
variable-renumbering pass.  The created Vars could not be seen as equal()  
to normal Vars, which among other things broke equivalence-class processing  
for them.  The consequences of this were indeed visible in the regression  
tests, in the form of failure to propagate constants as one would expect.  
I stumbled across it while poking at bug #11457 --- after intentionally  
disabling join equivalence processing, the security-barrier regression  
tests started falling over with fun errors like "could not find pathkey  
item to sort", because of failure to match the corrupted Vars to normal  
ones.  

commit   : 2c7946e4b8a623f7972fd87f8a1226e48f74ca7f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 24 Sep 2014 11:24:42 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 24 Sep 2014 11:24:42 -0400    

commit   : 6eaf7e5bea958c93fda306c846997414184d2526    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Sep 2014 20:25:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Sep 2014 20:25:33 -0400    

When the number of allowed iterations is limited (either a "?" quantifier  
or a bound expression), the last sub-match has to reach to the end of the  
target string.  The previous coding here first tried the shortest possible  
match (one character, usually) and then gave up and back-tracked if that  
didn't work, typically leading to failure to match overall, as shown in  
bug #11478 from Christoph Berg.  The minimum change to fix that would be to  
not decrement k before "goto backtrack"; but that would be a pretty stupid  
solution, because we'd laboriously try each possible sub-match length  
before finally discovering that only ending at the end can work.  Instead,  
force the sub-match endpoint limit up to the end for even the first  
shortest() call if we cannot have any more sub-matches after this one.  
  
Bug introduced in my rewrite that added the iterdissect logic, commit  
173e29aa5deefd9e71c183583ba37805c8102a72.  The shortest-first search code  
was too closely modeled on the longest-first code, which hasn't got this  
issue since it tries a match reaching to the end to start with anyway.  
Back-patch to all affected branches.  

commit   : fcfd7d26a2f99e99ad5bba6a982963dc3c9b0da0    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 22 Sep 2014 20:50:17 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 22 Sep 2014 20:50:17 -0400    

Per discussion in bug #11350, log ALTER SYSTEM commands at the  
log_statement=ddl level, rather than at the log_statement=all level.  
  
Pointed out by Tomonari Katsumata.  
  
Back-patch to 9.4 where ALTER SYSTEM was introduced.  

commit   : c4bee09c0e1fc7fb2281ba1e125ab17c5e9a20e7    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Mon, 22 Sep 2014 20:22:16 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Mon, 22 Sep 2014 20:22:16 -0400    

While withCheckOption exprs had been handled in many cases by  
happenstance, they need to be handled during set_plan_references and  
more specifically down in set_plan_refs for ModifyTable plan nodes.  
This is to ensure that the opfuncid's are set for operators referenced  
in the withCheckOption exprs.  
  
Identified as an issue by Thom Brown  
  
Patch by Dean Rasheed  
  
Back-patch to 9.4, where withCheckOption was introduced.  

commit   : e3e065d3779d82640e93298c06106c16c1948090    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 22 Sep 2014 16:05:51 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 22 Sep 2014 16:05:51 -0400    

It's a string, not a scalar.  
  
Petr Jelinek  

commit   : 47288bd08c0169ecb5eb50742336cc0df813777e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Sep 2014 13:18:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Sep 2014 13:18:59 -0400    

This has been broken since commit af7914c6627bcf0b0ca614e9ce95d3f8056602bf,  
which added the EXPLAIN (TIMING) option.  Although that commit included  
updates to auto_explain, they evidently weren't tested very carefully,  
because the code failed to print node timings even when it should, due to  
failure to set es.timing in the ExplainState struct.  Reported off-list by  
Neelakanth Nadgir of Salesforce.  
  
In passing, clean up the documentation for auto_explain's options a  
little bit, including re-ordering them into what seems to me a more  
logical order.  

commit   : f9edfc1aa9ea4f0bae87eabcac261d82370c7de4    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 19 Sep 2014 17:04:00 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 19 Sep 2014 17:04:00 +0200    

x86's memory barrier assembly was marked as clobbering "memory" but  
not "cc" even though 'addl' sets various flags. As it turns out gcc on  
x86 implicitly assumes "cc" on every inline assembler statement, so  
it's not a bug. But as that's poorly documented and might get copied  
to architectures or compilers where that's not the case, it seems  
better to be precise.  
  
Discussion: 20140919100016.GH4277@alap3.anarazel.de  
  
To keep the code common, backpatch to 9.2 where explicit memory  
barriers were introduced.  

commit   : 78b488d2e3d884e58a670f052400573b33824e04    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 17 Sep 2014 00:54:12 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 17 Sep 2014 00:54:12 -0400    

Add some quotes in the makefile snippet that creates the temporary  
installation, so that it can handle spaces in the directory name and  
possibly some other oddities.  

commit   : 4c054ad18ecc4aa7fdc9a6760d029c64eaab1cdd    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 16 Sep 2014 09:11:49 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 16 Sep 2014 09:11:49 +0300    

They were marked to return a boolean, but they actually return a  
GinTernaryValue, which is more like a "char". It makes no practical  
difference, as the triConsistent functions cannot be called directly from  
SQL because they have "internal" arguments, but this nevertheless seems  
more correct.  
  
Also fix the GinTernaryValue name in the documentation. I renamed the enum  
earlier, but neglected the docs.  
  
Alexander Korotkov. This is new in 9.4, so backpatch there.  

commit   : 1597e6c212d3930edb6f58390a511526cc043377    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 12 Sep 2014 11:24:09 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 12 Sep 2014 11:24:09 -0400    

In psql, expanded mode was not being displayed correctly when using  
the normal ascii or unicode linestyles and border set to '3'.  Now,  
per the documentation, border '3' is really only sensible for HTML  
and LaTeX formats, however, that's no excuse for ascii/unicode to  
break in that case, and provisions had been made for psql to cleanly  
handle this case (and it did, in non-expanded mode).  
  
This was broken when ascii/unicode was initially added a good five  
years ago because print_aligned_vertical_line wasn't passed in the  
border setting being used by print_aligned_vertical but instead was  
given the whole printTableContent.  There really isn't a good reason  
for vertical_line to have the entire printTableContent structure, so  
just pass in the printTextFormat and border setting (similar to how  
this is handled in horizontal_line).  
  
Pointed out by Pavel Stehule, fix by me.  
  
Back-patch to all currently-supported versions.  

commit   : 7dfab04a8aad7aa5066d2625a649d407ed6b7a5f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 2 Sep 2014 16:06:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 2 Sep 2014 16:06:58 +0900    

This patch allows us to execute ALTER SYSTEM RESET command to  
remove the configuration entry from postgresql.auto.conf.  
  
Vik Fearing, reviewed by Amit Kapila and me.  

commit   : 79ee6370ee803b36c2649cfb7655affa2c1007f1    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 12 Sep 2014 11:23:59 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 12 Sep 2014 11:23:59 +0300    

The code that tried to split a page at 75/25 ratio, when appending to the  
end of an index, was buggy in two ways. First, there was a silly typo that  
caused it to just fill the left page as full as possible. But the logic as  
it was intended wasn't correct either, and would actually have given a ratio  
closer to 60/40 than 75/25.  
  
Gaetano Mendola spotted the typo. Backpatch to 9.4, where this code was added.  

commit   : 1c603198a497173b4947fc669fdeda4706b09eb8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Sep 2014 23:30:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 11 Sep 2014 23:30:54 -0400    

The code for raising a NUMERIC value to an integer power wasn't very  
careful about large powers.  It got an outright wrong answer for an  
exponent of INT_MIN, due to failure to consider overflow of the Abs(exp)  
operation; which is fixable by using an unsigned rather than signed  
exponent value after that point.  Also, even though the number of  
iterations of the power-computation loop is pretty limited, it's easy for  
the repeated squarings to result in ridiculously enormous intermediate  
values, which can take unreasonable amounts of time/memory to process,  
or even overflow the internal "weight" field and so produce a wrong answer.  
We can forestall misbehaviors of that sort by bailing out as soon as the  
weight value exceeds what will fit in int16, since then the final answer  
must overflow (if exp > 0) or underflow (if exp < 0) the packed numeric  
format.  
  
Per off-list report from Pavel Stehule.  Back-patch to all supported  
branches.  

commit   : 330bf85c4936fa6f0b59d4baad54cd8e1ce11604    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 11 Sep 2014 21:08:59 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 11 Sep 2014 21:08:59 -0400    

When running vacuumdb --analyze-in-stages --all, it needs to run the  
first stage across all databases before the second one, instead of  
running all stages in a database before processing the next one.  
  
Also respect the --quiet option with --analyze-in-stages.  

commit   : 022aea346def58d5dd17dd0e012f925e8688d439    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Sep 2014 18:39:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Sep 2014 18:39:46 -0400    

This is useful for replication tools like Slony and Skytools.  This is a  
backpatch of a74a4aa23bb95b590ff01ee564219d2eacea3706.  
  
Report by Sergey Konoplev  
  
Backpatch through 9.3  

commit   : b8b4124011322b7e376f9e21b3d335a85a28f54c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 11 Sep 2014 22:43:56 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 11 Sep 2014 22:43:56 +0300    

With the new B-tree incomplete split handling in 9.4, _bt_insert_parent is  
never called in recovery.  

commit   : 06b95334f8d16d975e3a68f2392599249ca99c93    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 11 Sep 2014 15:15:40 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 11 Sep 2014 15:15:40 +0300    

I renamed a variable, but missed an #ifdef WIN32 block.  

commit   : c8b24991115c967abee06ccc78e11532d02cffde    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 11 Sep 2014 13:00:48 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 11 Sep 2014 13:00:48 +0300    

The previous coding first generated a uniform random value between 0.0 and  
1.0, then converted that to an integer between 1 and 10000, and divided that  
again by 10000. Those conversions are unnecessary; we can use the double  
value that pg_erand48() returns directly. While we're at it, put the logic  
into a helper function, getPoissonRand().  
  
The largest delay generated by the old coding was about 9.2 times the  
average, because of the way the uniformly distributed value used for the  
calculation was truncated to 1/10000 granularity. The new coding doesn't  
have such clamping. With my laptop's DBL_MIN value, the maximum delay with  
the new coding is about 700x the average. That seems acceptable - any  
reasonable pgbench session should last long enough to average that out.  
  
Backpatch to 9.4.  

commit   : 8c9dd69fc2638701653c90bbf291884f8ca23d56    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 11 Sep 2014 12:40:01 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 11 Sep 2014 12:40:01 +0300    

The reported latency values now include the "schedule lag" time, that is,  
the time between the transaction's scheduled start time and the time it  
actually started. This relates better to a model where requests arrive at a  
certain rate, and we are interested in the response time to the end user or  
application, rather than the response time of the database itself.  
  
Also, when --rate is used, include the schedule lag time in the log output.  
  
The --rate option is new in 9.4, so backpatch to 9.4. It seems better to  
make this change in 9.4, while we're still in the beta period, than ship a  
9.4 version that calculates the values differently than 9.5.  

commit   : 958a828fea254307d7699aea4310f0654dc48990    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 Sep 2014 20:39:28 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 Sep 2014 20:39:28 -0400    

Really old versions of Test::More don't support subplans, so skip the  
tests in that case.  

commit   : e7903163ff6352cd75dc896cf289e3cccc1fef33    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 Sep 2014 20:05:56 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 10 Sep 2014 20:05:56 -0400    

Apparently, older versions of "prove" (couldn't identify the exact  
version from the changelog) don't look into the t/ directory for tests  
by default, so specify it explicitly.  

commit   : 1e6ba64080d0906e428cc3f58e612f8c237fc755    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Sep 2014 20:50:15 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 10 Sep 2014 20:50:15 -0400    

Patch by David Johnston  
  
Backpatch through 9.4  

commit   : f003419791f35eeab0150cd097bcf7929622b0fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Sep 2014 18:35:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 9 Sep 2014 18:35:17 -0400    

The code I added in commit f343a880d5555faf1dad0286c5632047c8f599ad was  
careless about preserving AND/OR flatness: it could create a structure with  
an OR node directly underneath another one.  That breaks an assumption  
that's fairly important for planning efficiency, not to mention triggering  
various Asserts (as reported by Benjamin Smith).  Add a trifle more logic  
to handle the case properly.  

commit   : 21dcc48dc7ec48bf7b2a40c619e1c96ca4d2477c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 9 Sep 2014 13:57:38 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 9 Sep 2014 13:57:38 +0200    

07968dbfaad03 missed part of the S_UNLOCK define when building for  
sparcv8+.  

commit   : 11687e728d726a8ab3c9e165e4f7d962013f46ab    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 9 Sep 2014 00:47:32 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 9 Sep 2014 00:47:32 +0200    

Some Sparc CPUs can be run in various coherence models, ranging from  
RMO (relaxed) over PSO (partial) to TSO (total). Solaris has always  
run CPUs in TSO mode while in userland, but linux didn't use to and  
the various *BSDs still don't. Unfortunately the sparc TAS/S_UNLOCK  
were only correct under TSO. Fix that by adding the necessary memory  
barrier instructions. On sparcv8+, which should be all relevant CPUs,  
these are treated as NOPs if the current consistency model doesn't  
require the barriers.  
  
Discussion: 20140630222854.GW26930@awork2.anarazel.de  
  
Will be backpatched to all released branches once a few buildfarm  
cycles haven't shown up problems. As I've no access to sparc, this is  
blindly written.  

commit   : 18af7938c1efa1ad18c876fcc471020c0ad9db07    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 Sep 2014 13:56:29 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 9 Sep 2014 13:56:29 -0400    

bug #10528  

commit   : 106e4b29c0b1fdba36193bf38896d77fc28ea940    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 9 Sep 2014 10:52:10 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 9 Sep 2014 10:52:10 -0400    

Now that ALTER TABLE .. ALL IN TABLESPACE has replaced the previous  
ALTER TABLESPACE approach, it makes sense to move the calls down in  
to ProcessUtilitySlow where the rest of ALTER TABLE is handled.  
  
This also means that event triggers will support ALTER TABLE .. ALL  
(which was the impetus for the original change, though it has other  
good qualities also).  
  
Álvaro Herrera  
  
Back-patch to 9.4 as the original rework was.  

commit   : fd66ccf7db638664a7867cc18e253d770c783d33    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Sep 2014 16:09:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Sep 2014 16:09:49 -0400    

psql's \s (print command history) doesn't work at all with recent libedit  
versions when printing to the terminal, because libedit tries to do an  
fchmod() on the target file which will fail if the target is /dev/tty.  
(We'd already noted this in the context of the target being /dev/null.)  
Even before that, it didn't work pleasantly, because libedit likes to  
encode the command history file (to ensure successful reloading), which  
renders it nigh unreadable, not to mention significantly different-looking  
depending on exactly which libedit version you have.  So let's forget using  
write_history() for this purpose, and instead print the data ourselves,  
using logic similar to that used to iterate over the history for newline  
encoding/decoding purposes.  
  
While we're at it, insert the ability to use the pager when \s is printing  
to the terminal.  This has been an acknowledged shortcoming of \s for many  
years, so while you could argue it's not exactly a back-patchable bug fix  
it still seems like a good improvement.  Anyone who's seriously annoyed  
at this can use "\s /dev/tty" or local equivalent to get the old behavior.  
  
Experimentation with this showed that the history iteration logic was  
actually rather broken when used with libedit.  It turns out that with  
libedit you have to use previous_history() not next_history() to advance  
to more recent history entries.  The easiest and most robust fix for this  
seems to be to make a run-time test to verify which function to call.  
We had not noticed this because libedit doesn't really need the newline  
encoding logic: its own encoding ensures that command entries containing  
newlines are reloaded correctly (unlike libreadline).  So the effective  
behavior with recent libedits was that only the oldest history entry got  
newline-encoded or newline-decoded.  However, because of yet other bugs in  
history_set_pos(), some old versions of libedit allowed the existing loop  
logic to reach entries besides the oldest, which means there may be libedit  
~/.psql_history files out there containing encoded newlines in more than  
just the oldest entry.  To ensure we can reload such files, it seems  
appropriate to back-patch this fix, even though that will result in some  
incompatibility with older psql versions (ie, multiline history entries  
written by a psql with this fix will look corrupted to a psql without it,  
if its libedit is reasonably up to date).  
  
Stepan Rutz and Tom Lane  

commit   : b1a7c9e387f77b85aa14eb342f0432fcdb6ddc35    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Sep 2014 22:40:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Sep 2014 22:40:41 -0400    

The old claim is from my commit d06ebdb8d3425185d7e641d15e45908658a0177d of  
2000-07-17, but it seems to have been a plain old thinko; sum(float4) has  
been distinct from sum(float8) since Berkeley days.  Noted by KaiGai Kohei.  
  
While at it, mention the existence of sum(money), which is also of  
embarrassingly ancient vintage.  

commit   : 4231599328f75d6549831f65223a22236a43a5c9    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sun, 7 Sep 2014 08:04:35 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sun, 7 Sep 2014 08:04:35 -0400    

Update the tab completion for the changes made in  
3c4cf080879b386d4ed1814667aca025caafe608, which rework 'MOVE ALL' to be  
'ALTER .. ALL IN TABLESPACE'.  
  
Fujii Masao  
  
Back-patch to 9.4, as the original change was.  

commit   : 31189e8627cdbdb72d16d0314d95b1aea913e616    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 6 Sep 2014 12:43:11 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 6 Sep 2014 12:43:11 -0400    

Report by Erik Rijkers  
  
Backpatch through 9.4  

commit   : f9c0434ee330bdbd07d7dc75ade849a1d01ef42e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 6 Sep 2014 11:10:51 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 6 Sep 2014 11:10:51 -0400    

This is for postgres/postmaster options.  
  
Report by Tom Lane  
  
Backpatch through 9.4  

commit   : a6d9b331aaa1bccd740700954c15bd56727189ad    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Sep 2014 19:01:26 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 5 Sep 2014 19:01:26 -0400    

Peer rows are matching rows when ORDER BY is specified.  
  
Report by arnaud.mouronval@gmail.com, David G Johnston  
  
Backpatch through 9.4  

commit   : a6283f97069e6f747bdc2052e9f755a9136a5edc    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 5 Sep 2014 01:20:33 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 5 Sep 2014 01:20:33 -0400    

commit   : 7695f9701a8bf46bf385c96bce2e216ee2ccf93e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 5 Sep 2014 11:40:08 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 5 Sep 2014 11:40:08 +0900    

Back-patch to 9.4 where user_catalog_table was added.  
  
Review by Michael Paquier  

commit   : ffb16cf29fe127b1105310a70d908b7bba88d0ac    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 4 Sep 2014 14:11:23 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 4 Sep 2014 14:11:23 -0400    

The link to the NIST web page about DES standards leads to nowhere, and  
according to archive.org has been forwarded to an unrelated page for  
many years.  Therefore, just remove that link.  More up to date  
information can be found via Wikipedia, for example.  

commit   : 6da740e72ebfe22cb2a40bf9ebd775531a2294a6    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 5 Sep 2014 02:17:57 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 5 Sep 2014 02:17:57 +0900    

Back-patch to all supported branches.  
  
Per bug #11335 from Haruka Takatsuka  

commit   : 643cad19346bc7d6e16663ee9ff6f7a6ef009d93    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 4 Sep 2014 13:48:09 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 4 Sep 2014 13:48:09 +0900    

The syntax summary previously failed to clarify that the first  
argument is also optional.  The textual description did mention it,  
but all the way at the bottom.  It fits better with the command  
overview, so move it there, and fix the summary also.  
  
Back-patch to 9.4 where \pset without arguments was supported.  
  
Dilip Kumar, reviewed by Fabien Coelho  

commit   : 42c73ef9b7e5eb552b972bc05335746f54e34f98    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 3 Sep 2014 17:22:20 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 3 Sep 2014 17:22:20 -0400    

Report by Peter Eisentraut  

commit   : 646deb603e0846d1efd4da84df412963dda68eec    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 3 Sep 2014 14:34:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 3 Sep 2014 14:34:46 -0400    

Report by Tomáš Greif  
  
Backpatch through 9.4  

commit   : 6ea591ed4619a29e57369fef905d2160bd6e5438    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 2 Sep 2014 14:22:42 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 2 Sep 2014 14:22:42 +0300    

Andres Freund  

commit   : cb3d2df90e240680438cb612edcd1598579f4d5c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 1 Sep 2014 13:42:43 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 1 Sep 2014 13:42:43 +0200    

The regression tests for contrib/test_decoding regularly failed on  
postgres instances that were very slow. Either because the hardware  
itself was slow or because very expensive debugging options like  
CLOBBER_CACHE_ALWAYS were used.  
  
The reason they failed was just that some additional transactions were  
decoded. Analyze and vacuum, triggered by autovac.  
  
To fix just add a option to test_decoding to only display transactions  
in which a change was actually displayed. That's not pretty because it  
removes information from the tests; but better than constantly failing  
tests in very likely harmless ways.  
  
Backpatch to 9.4 where logical decoding was introduced.  
  
Discussion: 20140629142511.GA26930@awork2.anarazel.de  

commit   : 92b2c136580869fe9286a4d880d592d74f55d5b7    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 1 Sep 2014 00:17:18 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 1 Sep 2014 00:17:18 +0200    

68a2e52bbaf98f136 has introduced LWLockAcquireCommon() containing the  
previous contents of LWLockAcquire() plus added functionality. The  
latter then calls it, just like LWLockAcquireWithVar(). Because the  
majority of callers don't need the added functionality, declare the  
common code as inline. The compiler then can optimize away the unused  
code. Doing so is also useful when looking at profiles, to  
differentiate the users.  
  
Backpatch to 9.4, the first branch to contain LWLockAcquireCommon().  

commit   : ae70b9f0ec1f967aa84844274f26f519450b6b49    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 30 Aug 2014 11:01:47 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 30 Aug 2014 11:01:47 -0500    

Errors detected using Topy (https://github.com/intgr/topy), all  
changes verified by hand and some manual tweaks added.  
  
Marti Raudsepp  
  
Individual changes backpatched, where applicable, as far as 9.0.  

commit   : f08b5e7577e70f9aee80d04e94864bb5053f7555    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 29 Aug 2014 09:05:35 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 29 Aug 2014 09:05:35 -0400    

Also update docs to mention which function are super-user-only.  
  
Report by sys-milan@statpro.com  
  
Backpatch through 9.4  

commit   : 08bff295a7e7ac66a35f42e92e97782b9af64cdc    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 29 Aug 2014 14:19:34 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 29 Aug 2014 14:19:34 +0300    

The list of posting lists it's dealing with can contain placeholders for  
deleted posting lists. The placeholders are kept around so that they can  
be WAL-logged, but we must be careful to not try to access them.  
  
This fixes bug #11280, reported by Mårten Svantesson. Backpatch to 9.4,  
where the compressed data leaf page code was added.  

commit   : c573e9d7760869a0db6343b2a7353309045e05ab    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 29 Aug 2014 00:01:34 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 29 Aug 2014 00:01:34 -0400    

commit   : f41381e240f4312017f9f70fea194e59d8cc3a2e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 28 Aug 2014 23:59:03 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 28 Aug 2014 23:59:03 -0400    

It was changed when ALTER TABLESPACE / MOVE was added but then not  
updated when that was moved back out.  

commit   : c45af8fa111ea381b428ab31adcaa5ecd032f06a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Aug 2014 18:21:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Aug 2014 18:21:11 -0400    

In commit 45e02e3232ac7cc5ffe36f7986159b5e0b1f6fdc, we intentionally  
disallowed updates on individual elements of oidvector columns.  While that  
still seems like a sane idea in the abstract, we (I) forgot that citext's  
"upgrade from unpackaged" script did in fact perform exactly such updates,  
in order to fix the problem that citext indexes should have a collation  
but would not in databases dumped or upgraded from pre-9.1 installations.  
  
Even if we wanted to add casts to allow such updates, there's no practical  
way to do so in the back branches, so the only real alternative is to make  
citext's kluge even klugier.  In this patch, I cast the oidvector to text,  
fix its contents with regexp_replace, and cast back to oidvector.  (Ugh!)  
  
Since the aforementioned commit went into all active branches, we have to  
fix this in all branches that contain the now-broken update script.  
  
Per report from Eric Malm.  

commit   : eeab936ba94de70ee5f03e167331f1399914b6db    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 27 Aug 2014 19:15:18 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 27 Aug 2014 19:15:18 -0400    

If SELECT FOR UPDATE NOWAIT tries to lock a tuple that is concurrently  
being updated, it might fail to honor its NOWAIT specification and block  
instead of raising an error.  
  
Fix by adding a no-wait flag to EvalPlanQualFetch which it can pass down  
to heap_lock_tuple; also use it in EvalPlanQualFetch itself to avoid  
blocking while waiting for a concurrent transaction.  
  
Authors: Craig Ringer and Thomas Munro, tweaked by Álvaro  
http://www.postgresql.org/message-id/51FB6703.9090801@2ndquadrant.com  
  
Per Thomas Munro in the course of his SKIP LOCKED feature submission,  
who also provided one of the isolation test specs.  
  
Backpatch to 9.4, because that's as far back as it applies without  
conflicts (although the bug goes all the way back).  To that branch also  
backpatch Thomas Munro's new NOWAIT test cases, committed in master by  
Heikki as commit 9ee16b49f0aac819bd4823d9b94485ef608b34e8 .  

commit   : d4b8418a04f41dc991dc364a0a6eab64b16f2e83    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 26 Aug 2014 23:08:41 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 26 Aug 2014 23:08:41 -0400    

In some cases, not all Vars were being correctly marked as having been  
modified for updatable security barrier views, which resulted in invalid  
plans (eg: when security barrier views were created over top of  
inheiritance structures).  
  
In passing, be sure to update both varattno and varonattno, as _equalVar  
won't consider the Vars identical otherwise.  This isn't known to cause  
any issues with updatable security barrier views, but was noticed as  
missing while working on RLS and makes sense to get fixed.  
  
Back-patch to 9.4 where updatable security barrier views were  
introduced.  

commit   : 06414c0f68e9f8039c1de40d009f12fa96c49192    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 26 Aug 2014 10:00:42 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Tue, 26 Aug 2014 10:00:42 -0500    

Use SECURITY_LOCAL_USERID_CHANGE while building temporary tables;  
only escalate to SECURITY_RESTRICTED_OPERATION while potentially  
running user-supplied code.  The more secure mode was preventing  
temp table creation.  Add regression tests to cover this problem.  
  
This fixes Bug #11208 reported by Bruno Emanuel de Andrade Silva.  
  
Backpatch to 9.4, where the bug was introduced.  

commit   : 3a3d3f9ec01f1f7333e3bbcd5ba9398fd19ad8d9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 25 Aug 2014 15:34:50 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 25 Aug 2014 15:34:50 -0400    

Also, remove OID preservation mention, mention non-text dump formats  
  
Backpatch through 9.4  

commit   : 34356933f044d5e3fa02a30ef1fe859eca20d605    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Aug 2014 15:33:19 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Aug 2014 15:33:19 -0400    

There's no point in setting up a context error callback when doing  
conditional lock acquisition, because we never actually wait and so the  
able wouldn't be able to see it.  
  
Backpatch to 9.4, where this was added.  

commit   : 0bfce7618420c6f1eece55577c61ef2a7a12f80b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 25 Aug 2014 18:30:28 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 25 Aug 2014 18:30:28 +0200    

Some of the many error messages introduced in 458857cc missed 'FROM  
unpackaged'. Also e016b724 and 45ffeb7e forgot to quote extension  
version numbers.  
  
Backpatch to 9.1, just like 458857cc which introduced the messages. Do  
so because the error messages thrown when the wrong command is copy &  
pasted aren't easy to understand.  

commit   : 642aadff7ff6704e2afee360ca98b78a4fba6629    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 25 Aug 2014 19:13:24 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 25 Aug 2014 19:13:24 +0300    

We also don't track PREPARE, nor do we track planning time in general, so  
let's ignore DEALLOCATE as well for consistency.  
  
Backpatch to 9.4, but not further than that. Although it seems unlikely that  
anyone is relying on the current behavior, this is a behavioral change.  
  
Fabien Coelho  

commit   : 73e47b703b3b5bfc3a76029b0895b1173ae9ad76    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 23 Aug 2014 00:23:34 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 23 Aug 2014 00:23:34 -0400    

Add a note that some options can be specified multiple times to select  
multiple objects to restore.  This replaces the somewhat confusing use  
of plurals in the option descriptions themselves.  

commit   : 25eda23679433ee35972f9e4411a628e19b8cd57    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 22 Aug 2014 13:55:34 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 22 Aug 2014 13:55:34 -0400    

commit   : 15247948cc19e74b20af15020b48bee4aec771e9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Aug 2014 13:18:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Aug 2014 13:18:00 -0400    

Cause the path extraction operators to return their lefthand input,  
not NULL, if the path array has no elements.  This seems more consistent  
since the case ought to correspond to applying the simple extraction  
operator (->) zero times.  
  
Cause other corner cases in field/element/path extraction to return NULL  
rather than failing.  This behavior is arguably more useful than throwing  
an error, since it allows an expression index using these operators to be  
built even when not all values in the column are suitable for the  
extraction being indexed.  Moreover, we already had multiple  
inconsistencies between the path extraction operators and the simple  
extraction operators, as well as inconsistencies between the JSON and  
JSONB code paths.  Adopt a uniform rule of returning NULL rather than  
throwing an error when the JSON input does not have a structure that  
permits the request to be satisfied.  
  
Back-patch to 9.4.  Update the release notes to list this as a behavior  
change since 9.3.  

commit   : 32d93e8c2da5387a8d5efdd4df1e5fb9bcfa9bb2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Aug 2014 13:45:38 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Aug 2014 13:45:38 +0300    

The option is called --tablespace-mapping, not --tablespace.  
  
Amit Kapila  

commit   : 8a22633f52f2399118d6ad3c2c4da6a31f07e907    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Aug 2014 10:16:26 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 22 Aug 2014 10:16:26 +0300    

Previously, we would first create the symlinks the way they are in the  
original system, and at the end replace them with the mapped symlinks.  
That never really made much sense, so now we create the symlink pointing  
to the correct location to begin with, so that there's no need to fix  
them at the end.  
  
The old coding didn't work correctly on Windows, because Windows junction  
points look more like directories than files, and ought to be removed with  
rmdir rather than unlink. Also, it incorrectly used "%d" rather than "%u"  
to print an Oid, but that's gone now.  
  
Report and patch by Amit Kapila, with minor changes by me. Reviewed by  
MauMau. Backpatch to 9.4, where the --tablespace feature was added.  

commit   : d9b2bc45cf75f913490f1b3ce9b9263509b26704    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Thu, 21 Aug 2014 19:06:17 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Thu, 21 Aug 2014 19:06:17 -0400    

As 'ALTER TABLESPACE .. MOVE ALL' really didn't change the tablespace  
but instead changed objects inside tablespaces, it made sense to  
rework the syntax and supporting functions to operate under the  
'ALTER (TABLE|INDEX|MATERIALIZED VIEW)' syntax and to be in  
tablecmds.c.  
  
Pointed out by Alvaro, who also suggested the new syntax.  
  
Back-patch to 9.4.  

commit   : 9243417801be3f1cfaa3a3c33d5a003f382bd7a4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Aug 2014 19:05:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Aug 2014 19:05:09 -0400    

Cover some cases I omitted before, such as null and empty-string  
elements in the path array.  This exposes another inconsistency:  
json_extract_path complains about empty path elements but  
jsonb_extract_path does not.  

commit   : 04db8747840f581177c6622008d2e42d3528f7fe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Aug 2014 16:48:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Aug 2014 16:48:37 -0400    

jsonb's #> operator segfaulted (dereferencing a null pointer) if the RHS  
was a zero-length array, as reported in bug #11207 from Justin Van Winkle.  
json's #> operator returns NULL in such cases, so for the moment let's  
make jsonb act likewise.  
  
Also add a bunch of regression test queries memorializing the -> and #>  
operators' behavior for this and other corner cases.  
  
There is a good argument for changing some of these behaviors, as they  
are not very consistent with each other, and throwing an error isn't  
necessarily a desirable behavior for operators that are likely to be  
used in indexes.  However, everybody can agree that a core dump is the  
Wrong Thing, and we need test cases even if we decide to change their  
expected output later.  

commit   : e0d010f64ca2b3b7d41ca961549388cf4fbe8aed    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 19 Aug 2014 18:30:38 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 19 Aug 2014 18:30:38 +0900    

This reverts commit 083d29c65b7897f90c70e6dc0a4240a5fa75c8f2.  
  
The commit changed the code so that it causes an errors when  
IDENTIFY_SYSTEM returns three columns. But which prevents us  
from using the replication-related utilities against the server  
with older version. This is not what we want. For that  
compatibility, we allow the utilities to receive three columns  
as the result of IDENTIFY_SYSTEM eventhough it actually returns  
four columns in 9.4 or later.  
  
Pointed out by Andres Freund.  

commit   : c41996b18c0bb1cbf7bdcdf6a01da8e3cbce9fc8    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 19 Aug 2014 17:26:07 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 19 Aug 2014 17:26:07 +0900    

5a991ef8692ed0d170b44958a81a6bd70e90585 added new column into  
the result of IDENTIFY_SYSTEM command. But it was not reflected into  
several codes checking that result. Specifically though the number of  
columns in the result was increased to 4, it was still compared with 3  
in some replication codes.  
  
Back-patch to 9.4 where the number of columns in IDENTIFY_SYSTEM  
result was increased.  
  
Report from Michael Paquier  

commit   : 151ce45825b317a9e06c40ddb48917bde9dc94fa    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 18 Aug 2014 23:00:38 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 18 Aug 2014 23:00:38 -0400    

Programs need execute permission on a DLL file to load it.  MSYS  
"install" ignores the mode argument, and our Cygwin build statically  
links libpq into programs.  That explains the lack of buildfarm trouble.  
Back-patch to 9.0 (all supported versions).  

commit   : 48e0b5ff3795a827c558a9ca7863fbfdbff6d683    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 18 Aug 2014 22:58:57 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 18 Aug 2014 22:58:57 -0400    

The aboriginal sample placed connection parameters in  
groupOfUniqueNames/uniqueMember.  OpenLDAP, at least as early as version  
2.4.23, rejects uniqueMember entries that do not conform to the syntax  
for a distinguished name.  Use device/description, which is free-form.  
Back-patch to 9.4 for web site visibility.  

commit   : a611d2afb0f2ea1de8262dc132aaa0d5aaa3dbf2    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 18 Aug 2014 22:58:25 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 18 Aug 2014 22:58:25 -0400    

Oversight in commit 7cbe57c34dec4860243e6d0f81738cfbb6e5d069.  
Back-patch to 9.4, where that commit first appeared.  In passing,  
release-note the FDW API postcondition change from the same commit.  

commit   : 61947069ffb27a7eb8037cbd7756dbcbb06ebd4a    
  
author   : Greg Stark <stark@mit.edu>    
date     : Mon, 18 Aug 2014 13:59:41 +0100    
  
committer: Greg Stark <stark@mit.edu>    
date     : Mon, 18 Aug 2014 13:59:41 +0100    

commit   : 7e81c4b2901d8a692cc4e8c839a5a6490fc345e4    
  
author   : Greg Stark <stark@mit.edu>    
date     : Mon, 18 Aug 2014 11:28:57 +0100    
  
committer: Greg Stark <stark@mit.edu>    
date     : Mon, 18 Aug 2014 11:28:57 +0100    

revert dbe31616c9be7380b8a88cdfbeaa68dbdcdebc36  
revert 6513633b94173fc1d9e2b213c43f9422ddbf5faa  

commit   : f304ddc5cefff167e702c044269d75df2d5b4508    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Aug 2014 01:17:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Aug 2014 01:17:49 -0400    

The old text explained what happened if we didn't have working int64  
arithmetic.  Since that case has been explicitly rejected by configure  
since 8.4.3, documenting it in the 9.x branches can only produce confusion.  

commit   : 560e2300b2ab395a367153e37d445fd584281cf7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Aug 2014 22:57:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Aug 2014 22:57:20 -0400    

Commit f30015b6d794c15d52abbb3df3a65081fbefb1ed made this happen for  
timestamp and timestamptz, but it seems pretty inconsistent to not  
do it for simple dates as well.  
  
(In passing, I re-pgindent'd json.c.)  

commit   : 3b2f4aa0f0fe23b0cac753f91833df353994d298    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 18 Aug 2014 11:18:53 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 18 Aug 2014 11:18:53 +0900    

Previously only CREATE_REPLICATION_SLOT was exposed as an index term.  
That's odd and there is no reason not to add index terms for other  
replication commands.  
  
Back-patch to 9.4.  

commit   : 912c70bb8db05a4a7599e43e3a79599957daa301    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Aug 2014 22:26:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Aug 2014 22:26:49 -0400    

Update the notes to include commits through today, and do a lot of  
wordsmithing and markup adjustment.  Notably, don't use <link> where <xref>  
will do; since we got rid of the text-format HISTORY file, there is no  
longer a reason to avoid <xref>.  

commit   : 1071ba183a2181f109cbd5b2a597637b3b145a8c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Aug 2014 15:59:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Aug 2014 15:59:06 -0400    

The new DISCARD SEQUENCES option was inadequately described, and hadn't  
been mentioned at all in the initial Description paragraph.  Rather than  
rectifying the latter the hard way, it seemed better to rewrite the  
description as a summary, instead of having it basically duplicate  
statements made under Parameters.  Be more consistent about the ordering  
of the options, too.  

commit   : 3d5ba5395aa0437c45441d2ca7b0973cbd060305    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 17 Aug 2014 09:10:28 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 17 Aug 2014 09:10:28 -0400    

The upstream stylesheets for man output insert a *roff comment for an  
occurrence of an indexterm, for reasons that have apparently been lost  
in history.  This, however, is done incorrectly and causes some  
formatting problems.  This hasn't been an issue until now, but the  
reorganization of indexterm elements inside variablelists has triggered  
this issue.  
  
The upstream fix (http://sourceforge.net/p/docbook/bugs/1340/) is to  
drop indexterms altogether in man output, and so we'll do the same here.  

commit   : 364f7cd4b6d2bb89be55c8915fcd08b69b5eb84e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Aug 2014 13:48:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Aug 2014 13:48:43 -0400    

PG_RETURN_BOOL() should only be used in functions following the V1 SQL  
function API.  This coding accidentally fails to fail since letting the  
compiler coerce the Datum representation of bool back to plain bool  
does give the right answer; but that doesn't make it a good idea.  
  
Back-patch to older branches just to avoid unnecessary code divergence.  

commit   : 30c05261ae842e2475fb06c7746de8623bcca731    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Aug 2014 12:53:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Aug 2014 12:53:57 -0400    

<@ and @> are each other's commutators, but they were incorrectly marked  
as being each other's negators instead.  (This was actually questioned  
in a comment in the original commit, but nobody followed through :-(.)  
Per bug #11178 from Christian Pronovost.  
  
In passing, fix some JSONB operator descriptions that were randomly  
different from the phrasing of every other similar description.  
  
catversion bump for pg_catalog contents change.  

commit   : a4eaa07bd011cba36921757489ab941f0b652587    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 15 Aug 2014 09:39:38 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 15 Aug 2014 09:39:38 +0300    

I removed the flag earlier, but missed a few references in jsonb.h.  

commit   : 0964db851d8bb6805d41f66a663bd129fa3cbea0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 15 Aug 2014 00:01:14 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 15 Aug 2014 00:01:14 -0400    

When the TAP tests are run in-tree (make check), set the shared library  
path using the appropriate environment variable, using a logic similar  
to pg_regress, so that the right libraries are used.  

commit   : 5086be023ac4205fe1003079a99803112cbaffa5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Aug 2014 16:05:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Aug 2014 16:05:49 -0400    

FreeBSD hasn't made any use of kern.ipc.semmap since 1.1, and newer  
releases reject attempts to set it altogether; so stop recommending  
that it be adjusted.  Per bug #11161.  
  
Back-patch to all supported branches.  Before 9.3, also incorporate  
commit 7a42dff47, which touches the same text and for some reason  
was not back-patched at the time.  

commit   : f3ab265052429793acf7a838a565b6d63b093914    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 14 Aug 2014 13:57:52 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 14 Aug 2014 13:57:52 +0900    

Previously the help message described that -m is an option for  
"stop", "restart" and "promote" commands in pg_ctl. But actually  
that's not an option for "promote". So this commit fixes that  
incorrect description in the help message.  
  
Back-patch to 9.3 where the incorrect description was added.  

commit   : 7c77ba8577d52b142997303f14c1e01abdb2d104    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 13 Aug 2014 10:45:28 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 13 Aug 2014 10:45:28 +0900    

This option is equivalent to --slot option which pg_receivexlog has  
already supported, which specifies the replication slot to use for  
WAL streaming. pg_recvlogical has already supported both options,  
and this commit makes pg_receivexlog consistent with pg_recvlogical  
regarding the slot option.  
  
Back-patch to 9.4 where the slot option was added.  
  
Michael Paquier  

commit   : 876f1e6805c34bb87525583e524e3445a33c215b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 12 Aug 2014 11:12:16 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 12 Aug 2014 11:12:16 +0200    

Some error messages complained about --init and --stop being used  
whereas the --create and --drop are the correct verbs. Fix that.  
  
Also a XLogRecPtr was tested in a boolean fashion instead of being  
compared to InvalidXLogRecPtr.  
  
Backpatch to 9.4 where pg_recvlogical was introduced.  
  
Michael Paquier  

commit   : 423f73df9dcb9fd5b05fb1ed17bd636245bb90f3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 12 Aug 2014 11:04:50 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 12 Aug 2014 11:04:50 +0200    

When doing logical decoding using START_LOGICAL_REPLICATION in a  
walsender process the walsender sometimes was sending out keepalive  
messages too frequently. Asking for feedback every time.  
  
WalSndWaitForWal() sends out keepalive messages when it's waiting for  
new WAL to be generated locally when it sees that the remote side  
hasn't yet flushed WAL up to the local position. That generally is  
good but causes problems if the remote side only writes but doesn't  
flush changes yet. So check for both remote write and flush position.  
  
Additionally we've asked for feedback to the keepalive message which  
isn't warranted when waiting for WAL in contrast to preventing  
timeouts because of wal_sender_timeout.  
  
Complaint and patch by Steve Singer.  

commit   : 700f060528b1485970e6414fbf96aa1f87766a40    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 12 Aug 2014 16:50:09 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 12 Aug 2014 16:50:09 +0900    

When both postgresql.conf and postgresql.auto.conf have their own entry of  
the same parameter, PostgreSQL uses the entry in postgresql.auto.conf because  
it appears last in the configuration scan. IOW, the other entries which appear  
earlier are ignored. But, previously, ProcessConfigFile() detected the invalid  
settings of even those unused entries and emitted the error messages  
complaining about them, at postmaster startup. Complaining about the entries  
to ignore is basically useless.  
  
This problem happened because ProcessConfigFile() was called twice at  
postmaster startup and the first call read only postgresql.conf. That is, the  
first call could check the entry which might be ignored eventually by  
the second call which read both postgresql.conf and postgresql.auto.conf.  
To work around the problem, this commit changes ProcessConfigFile so that  
its first call processes only data_directory and the second one does all the  
entries. It's OK to process data_directory in the first call because it's  
ensured that data_directory doesn't exist in postgresql.auto.conf.  
  
Back-patch to 9.4 where postgresql.auto.conf was added.  
  
Patch by me. Review by Amit Kapila  

commit   : 44ea72d28066103b3d1df9a3e9476f52c56e06cc    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 11 Aug 2014 22:52:16 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 11 Aug 2014 22:52:16 +0900    

The initialization fork was added in 9.1, but has not been taken into  
consideration in documents of get_raw_page function in pageinspect and  
storage layout. This commit fixes those oversights.  
  
get_raw_page can read not only a table but also an index, etc. So it  
should be documented that the function can read any relation. This commit  
also fixes the document of pageinspect that way.  
  
Back-patch to 9.1 where those oversights existed.  
  
Vik Fearing, review by MauMau  

commit   : 5d20643532cafd719482119d250c919edcac93b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Aug 2014 16:13:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Aug 2014 16:13:16 -0400    

The user documentation was vague and not entirely accurate about how  
we treat domain inputs for ambiguous operators/functions.  Clarify  
that, and add an example and some commentary.  Per a recent question  
from Adam Mackler.  
  
It's acted like this ever since we added domains, so back-patch  
to all supported branches.  

commit   : 2591e623f5fc80a49347fb5e106aa1e03f713429    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Aug 2014 17:31:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Aug 2014 17:31:16 -0400    

There's actually no need for any special case for unknown-type literals,  
since we only need to push the value through its output function and  
unknownout() works fine.  The code that was here was completely bizarre  
anyway, and would fail outright in cases that should work, not to mention  
suffering from some copy-and-paste bugs.  

commit   : 84dd042a51e702a3761250e2ce801b3fb2b879c3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Aug 2014 16:35:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Aug 2014 16:35:32 -0400    

Fix an obvious typo in json_build_object()'s complaint about invalid  
number of arguments, and make the errhint a bit more sensible too.  
  
Per discussion about how to word the improved hint, change the few places  
in the documentation that refer to JSON object field names as "names" to  
say "keys" instead, since that's what we've said in the vast majority of  
places in the docs.  Arguably "name" is more correct, since that's the  
terminology used in RFC 7159; but we're stuck with "key" in view of the  
naming of json_object_keys() so let's at least be self-consistent.  
  
I adjusted a few code comments to match this as well, and failed to  
resist the temptation to clean up some odd whitespace choices in the  
same area, as well as a useless duplicate PG_ARGISNULL() check.  There's  
still quite a bit of code that uses the phrase "field name" in non-user-  
visible ways, so I left those usages alone.  

commit   : 2f9912335c198f7ee8ec8c46a72f947c9c1c2257    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Aug 2014 13:46:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Aug 2014 13:46:38 -0400    

Such cases are disallowed by the SQL spec, and even if we wanted to allow  
them, the semantics seem ambiguous: how should the FK columns be matched up  
with the columns of a unique index?  (The matching could be significant in  
the presence of opclasses with different notions of equality, so this issue  
isn't just academic.)  However, our code did not previously reject such  
cases, but instead would either fail to match to any unique index, or  
generate a bizarre opclass-lookup error because of sloppy thinking in the  
index-matching code.  
  
David Rowley  

commit   : 213f0ff938949df3dd64cddd8c71f2da59812216    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 9 Aug 2014 00:07:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 9 Aug 2014 00:07:00 -0400    

commit   : 6749cd4e41ef68ba2ffe368487ec1b98fb0a974f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Aug 2014 20:46:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Aug 2014 20:46:44 -0400    

s/XIDs XIDs/XIDs/ in one place in maintenance.sgml.  
  
Guillaume Lelarge  

commit   : f445b368d357332fb8392384ee4d75f21f07c5bb    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 Aug 2014 14:56:13 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 Aug 2014 14:56:13 -0400    

Previously, TOAST tables only required in the new cluster could cause  
oid conflicts if they were auto-numbered and a later conflicting oid had  
to be assigned.  
  
Backpatch through 9.3  

commit   : dc431f41672611d5575e330209784adad73b4f0d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 6 Aug 2014 11:18:38 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 6 Aug 2014 11:18:38 -0400    

Commit 930e8ad738f5c78abd667626ca86f2553f36356f broke this.  
  
Jeff Janes  

commit   : cf6a9c3742a78414184a6e651e4cc7d239f8f2c4    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 6 Aug 2014 14:49:43 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 6 Aug 2014 14:49:43 +0900    

When more than one setting entries of same parameter exist in the  
configuration file, PostgreSQL uses only entry appearing last in  
configuration file scan. Since the other entries are not used,  
ParseConfigFp() doesn't need to process them, but previously it did  
that. This problematic behavior caused the configuration file scan  
to detect invalid settings of unused entries (e.g., existence of  
multiple entries of PGC_POSTMASTER parameter) and log the messages  
complaining about them.  
  
This commit changes the configuration file scan so that it processes  
only last entry of each parameter.  
  
Note that when multiple entries of same parameter exist both in  
postgresql.conf and postgresql.auto.conf, unused entries in  
postgresql.conf are still processed only at postmaster startup.  
  
The problem has existed since old version, but a user is more likely  
to encounter it since 9.4 where ALTER SYSTEM command was introduced.  
So back-patch to 9.4.  
  
Amit Kapila, slightly modified by me. Per report from Christoph Berg.  

commit   : 930e8ad738f5c78abd667626ca86f2553f36356f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 5 Aug 2014 12:26:25 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 5 Aug 2014 12:26:25 -0400    

These messages are new in 9.4, which hasn't been released yet, so  
back-patch to REL9_4_STABLE.  
  
Daniele Varrazzo  

commit   : 1337b3bbc2d821837e580fa232b714270e7ccd90    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 4 Aug 2014 11:45:45 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 4 Aug 2014 11:45:45 -0400    

autovacuum_multixact_freeze_max_age was added as a pg_ctl start  
parameter in 9.3.X to prevent autovacuum from running.  However, only  
some 9.3.X releases have autovacuum_multixact_freeze_max_age as it was  
added in a minor PG 9.3 release.  It also isn't needed because -b turns  
off autovacuum in 9.1+.  
  
Without this fix, trying to upgrade from an early 9.3 release to 9.4  
would fail.  
  
Report by EDB  
  
Backpatch through 9.3  

commit   : 7cf7dc759c5c23703c1ac9e2808a2a059b0b02dc    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 2 Aug 2014 15:18:09 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 2 Aug 2014 15:18:09 +0900    

Back-patch to 9.3.  

commit   : 38803d823cfe872be11592a2d0eb2d9575b07e20    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 2 Aug 2014 14:57:21 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 2 Aug 2014 14:57:21 +0900    

In 9.2, pg_receivexlog with verbose option has emitted the messages  
at the end of each WAL file. But the commit 0b63291 suppressed such  
messages by mistake. This commit fixes the bug so that pg_receivexlog  
--verbose outputs such messages again.  
  
Back-patch to 9.3 where the bug was added.  

commit   : d5186cf270c0860932bd8a03897eb78f43dc88fe    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 1 Aug 2014 21:13:17 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 1 Aug 2014 21:13:17 +0300    

commit   : a95f7fb761eea4b323973671f86dc406612a5d11    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Jul 2014 14:41:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 30 Jul 2014 14:41:35 -0400    

When autovacuum is nominally off, we will still launch autovac workers  
to vacuum tables that are at risk of XID wraparound.  But after we'd done  
that, an autovac worker would proceed to autovacuum every table in the  
targeted database, if they meet the usual thresholds for autovacuuming.  
This is at best pretty unexpected; at worst it delays response to the  
wraparound threat.  Fix it so that if autovacuum is nominally off, we  
*only* do forced vacuums and not any other work.  
  
Per gripe from Andrey Zhidenkov.  This has been like this all along,  
so back-patch to all supported branches.  

commit   : aeebacff114634ffa07b5299ee6c41b219717bc3    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 30 Jul 2014 11:25:58 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 30 Jul 2014 11:25:58 -0400    

InitProcess() relies on IsBackgroundWorker to decide whether the PGPROC  
for a new backend should be taken from ProcGlobal's freeProcs or from  
bgworkerFreeProcs.  In EXEC_BACKEND builds, InitProcess() is called  
sooner than in non-EXEC_BACKEND builds, and IsBackgroundWorker wasn't  
getting initialized soon enough.  
  
Report by Noah Misch.  Diagnosis and fix by me.  

commit   : 98c5fe5d0df8549972f46c324d9c6b18b4c4ecc0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 29 Jul 2014 23:47:16 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 29 Jul 2014 23:47:16 -0400    

- Capitalize titles consistently.  
- Fix some grammar.  
- Group "Obtaining Information About an Error" under "Trapping Errors",  
  but make "Obtaining the Call Stack Context Information" its own  
  section, since it's not about errors.  

commit   : 5b7f1f52107941a819cdf587216b86081cd967e2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 29 Jul 2014 17:16:59 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 29 Jul 2014 17:16:59 +0300    

Pointed out by Tom Lane. Backpatch to 9.4, the code was structured  
differently in earlier branches and didn't have this mistake.  

commit   : 3b558ac830b2c30b50b9993c505e3061cbda036c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 29 Jul 2014 10:33:15 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 29 Jul 2014 10:33:15 +0300    

There were several oversights in recovery code where COMMIT/ABORT PREPARED  
records were ignored:  
  
* pg_last_xact_replay_timestamp() (wasn't updated for 2PC commits)  
* recovery_min_apply_delay (2PC commits were applied immediately)  
* recovery_target_xid (recovery would not stop if the XID used 2PC)  
  
The first of those was reported by Sergiy Zuban in bug #11032, analyzed by  
Tom Lane and Andres Freund. The bug was always there, but was masked before  
commit d19bd29f07aef9e508ff047d128a4046cc8bc1e2, because COMMIT PREPARED  
always created an extra regular transaction that was WAL-logged.  
  
Backpatch to all supported versions (older versions didn't have all the  
features and therefore didn't have all of the above bugs).  

commit   : 850ebf2db574a0c28a4f34eceae3c77dbc6320c8    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 29 Jul 2014 12:07:54 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 29 Jul 2014 12:07:54 +0900    

Previously the duplicated paragraphs were used next to each other  
in the document to demonstrate that the changes in the stream  
were not consumed by pg_logical_slot_peek_changes function.  
But some users misunderstood that the duplication of the same  
paragraph was just typo. So this commit rewords the sentence in  
the latter paragraph for less confusing.  
  
Christoph Moench-Tegeder  

commit   : 5307c993637674692ef71bcd41ff2412b03de914    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jul 2014 16:30:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Jul 2014 16:30:14 -0400    

Since commit 2d00190495b22e0d0ba351b2cda9c95fb2e3d083, fork numbers are  
defined in relpath.h not relfilenode.h.  
  
Fabrízio de Royes Mello  

commit   : 48f9e3d22ee3e790d4356ab46a13bbf1ed78ccce    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 26 Jul 2014 23:19:02 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 26 Jul 2014 23:19:02 -0400    

The documentation of ALTER TABLESPACE ... MOVE was added without any  
markup, not even paragraph breaks.  Fix that, and clarify the text in a  
few places.  

commit   : a8dddcaf758159059a83e147a960b369e9e3ab96    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Jul 2014 19:48:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Jul 2014 19:48:45 -0400    

findDependencyLoops() was not bright about cases where there are multiple  
dependency paths between the same two dumpable objects.  In most scenarios  
this did not hurt us too badly; but since the introduction of section  
boundary pseudo-objects in commit a1ef01fe163b304760088e3e30eb22036910a495,  
it was possible for this code to take unreasonable amounts of time (tens  
of seconds on a database with a couple thousand objects), as reported in  
bug #11033 from Joe Van Dyk.  Joe's particular problem scenario involved  
"pg_dump -a" mode with long chains of foreign key constraints, but I think  
that similar problems could arise with other situations as long as there  
were enough objects.  To fix, add a flag array that lets us notice when we  
arrive at the same object again while searching from a given start object.  
This simple change seems to be enough to eliminate the performance problem.  
  
Back-patch to 9.1, like the patch that introduced section boundary objects.  

commit   : df58a17df29f7ec0ffc8389deee46e81a2a58a60    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 24 Jul 2014 09:19:50 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 24 Jul 2014 09:19:50 -0400    

shm_mq_send_bytes didn't invariably initialize *bytes_written before  
returning, which would cause shm_mq_send to read from uninitialized  
memory and add the value it found there to mqh->mqh_partial_bytes.  
This could cause the next attempt to send a message via the queue to  
fail an assertion (if the queue was detached) or copy data from a  
garbage pointer value into the queue (if non-blocking mode was in use).  

commit   : 3372f1adad12bc70321fdf22f3c11ac67e429f63    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 24 Jul 2014 09:04:59 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 24 Jul 2014 09:04:59 -0400    

Nothing in the checkpointer calls InitXLOGAccess(), so WALInsertLocks  
never got initialized there.  Without EXEC_BACKEND, it works anyway  
because the correct value is inherited from the postmaster, but  
with EXEC_BACKEND we've got a problem.  The problem appears to have  
been introduced by commit 68a2e52bbaf98f136a96b3a0d734ca52ca440a95.  
  
To fix, move the relevant initialization steps from InitXLOGAccess()  
to XLOGShmemInit(), making this more parallel to what we do  
elsewhere.  
  
Amit Kapila  

commit   : fece13d7477720bcbf02af795bed695c54d1250c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 24 Jul 2014 14:32:34 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 24 Jul 2014 14:32:34 +0200    

Ephemeral slots - slots that shouldn't survive database restarts -  
weren't properly cleaned up after a immediate/crash restart. They were  
ignored in the sense that they weren't restored into memory and thus  
didn't cause unwanted resource retention; but they prevented a new  
slot with the same name from being created.  
  
Now ephemeral slots are fully removed during startup.  
  
Backpatch to 9.4 where replication slots where added.  

commit   : 8da262879ef5e53620b9e6a0da82510d09c105cb    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 24 Jul 2014 08:19:19 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 24 Jul 2014 08:19:19 -0400    

Spotted by Tom Lane.  

commit   : e27eee10d7bcc211e1bac38575ed18c18d2ef88b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 23 Jul 2014 21:41:59 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 23 Jul 2014 21:41:59 -0400    

This fixes the installcheck part.  The check part has additional  
problems that will be addressed in a separate commit.  

commit   : 7a8715b9886ef2970b89edb7e8ab2a195e0f1e0d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jul 2014 15:20:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 23 Jul 2014 15:20:34 -0400    

Break the list of available options into an <itemizedlist> instead of  
inline sentences.  This is mostly motivated by wanting to ensure that the  
cross-references to the FSM and VM docs don't cross page boundaries in PDF  
format; but it seems to me to read more easily this way anyway.  I took the  
liberty of editorializing a bit further while at it.  
  
Per complaint from Magnus about 9.0.18 docs not building in A4 format.  
Patch all active branches so we don't get blind-sided by this particular  
issue again in future.  

commit   : b28761cb3176c22d7804504c753ef4892ae0356a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 23 Jul 2014 00:35:13 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 23 Jul 2014 00:35:13 -0400    

This is consistent with the POSIX verdict that kill() shall not report  
ESRCH for a zombie process.  Back-patch to 9.0 (all supported versions).  
Test code from commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 depends  
on it, and log messages about kill() reporting "Invalid argument" will  
cease to appear for this not-unexpected condition.  

commit   : 44acd17605032b7d32575b66f4c00ee0e2a7ab5f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 23 Jul 2014 00:35:07 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 23 Jul 2014 00:35:07 -0400    

Commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 introduced a usage  
thereof.  Back-patch to 9.0, like that commit.  

commit   : 30d6a9858cd8389e59d652d9919761dc095326c5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jul 2014 13:30:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jul 2014 13:30:01 -0400    

The executor has thrown errors for negative OFFSET values since 8.4 (see  
commit bfce56eea45b1369b7bb2150a150d1ac109f5073), but in a moment of brain  
fade I taught the planner that OFFSET with a constant negative value was a  
no-op (commit 1a1832eb085e5bca198735e5d0e766a3cb61b8fc).  Reinstate the  
former behavior by only discarding OFFSET with a value of exactly 0.  In  
passing, adjust a planner comment that referenced the ancient behavior.  
  
Back-patch to 9.3 where the mistake was introduced.  

commit   : 1ea941450bca70ec9e30c2936e99835f9649f865    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jul 2014 11:45:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 22 Jul 2014 11:45:50 -0400    

get_raw_page tried to validate the supplied block number against  
RelationGetNumberOfBlocks(), which of course is only right when  
accessing the main fork.  In most cases, the main fork is longer  
than the others, so that the check was too weak (allowing a  
lower-level error to be reported, but no real harm to be done).  
However, very small tables could have an FSM larger than their heap,  
in which case the mistake prevented access to some FSM pages.  
Per report from Torsten Foertsch.  
  
In passing, make the bad-block-number error into an ereport not elog  
(since it's certainly not an internal error); and fix sloppily  
maintained comment for RelationGetNumberOfBlocksInFork.  
  
This has been wrong since we invented relation forks, so back-patch  
to all supported branches.  

commit   : a61f63df7d19006b36adf7ee402999aa5243097d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 22 Jul 2014 11:22:47 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 22 Jul 2014 11:22:47 -0400    

This makes the behaviour consistent with the json parser, other  
json-generating functions, and the JSON standards.  

commit   : fd18965e33da9dc7326803e61cf28d82237e3bba    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 22 Jul 2014 11:01:03 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 22 Jul 2014 11:01:03 -0400    

With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL  
backends can crash at exit.  Raise a warning during "configure" based on  
the compile-time OpenLDAP version number, and test the crash scenario in  
the dblink test suite.  Back-patch to 9.0 (all supported versions).  

commit   : 87c4232fd35fc3d1ff06189e886bffb382f6ca87    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 22 Jul 2014 00:42:36 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 22 Jul 2014 00:42:36 -0400    

Unset environment variables that control message language, so that we  
can compare some program output with expected strings.  This is very  
similar to what pg_regress does.  

commit   : 2cf489301e0487ea7bedde488e1b52ede862d058    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Jul 2014 23:58:18 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Jul 2014 23:58:18 -0400    

The latest update introduced some funny whitespace, but since they are  
externally maintained files, we add them to the list of files to ignore.  

commit   : ecb2d583ca6b248a94c8b53e74dac1ec863a4db7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Jul 2014 22:41:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Jul 2014 22:41:23 -0400    

In commit 631dc390f49909a5c8ebd6002cfb2bcee5415a9d, we started to handle  
simple numeric timezone offsets via the zic library instead of the old  
CTimeZone/HasCTZSet kluge.  However, we overlooked the fact that the zic  
code will reject UTC offsets exceeding a week (which seems a bit arbitrary,  
but not because it's too tight ...).  This led to possibly setting  
session_timezone to NULL, which results in crashes in most timezone-related  
operations as of 9.4, and crashes in a small number of places even before  
that.  So check for NULL return from pg_tzset_offset() and report an  
appropriate error message.  Per bug #11014 from Duncan Gillis.  
  
Back-patch to all supported branches, like the previous patch.  
(Unfortunately, as of today that no longer includes 8.4.)  

commit   : c85374626f680902c207285b986ac38a134535eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Jul 2014 15:07:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Jul 2014 15:07:50 -0400    

commit   : ab2f504b2e8b4e90e44c9a20bb5d481794b39d1d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Jul 2014 14:59:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Jul 2014 14:59:25 -0400    

commit   : 3622b6be0fa8082f60eee2dd373f68911861118b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Jul 2014 12:58:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Jul 2014 12:58:44 -0400    

Per recommendation from Andres.  

commit   : d122387d7d9149fdb9589ebdaf52c763464e4cd5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Jul 2014 11:41:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Jul 2014 11:41:30 -0400    

In commit a61daa14d56867e90dc011bbba52ef771cea6770, we fixed pg_upgrade so  
that it would install sane relminmxid and datminmxid values, but that does  
not cure the problem for installations that were already pg_upgraded to  
9.3; they'll initially have "1" in those fields.  This is not a big problem  
so long as 1 is "in the past" compared to the current nextMultiXact  
counter.  But if an installation were more than halfway to the MXID wrap  
point at the time of upgrade, 1 would appear to be "in the future" and  
that would effectively disable tracking of oldest MXIDs in those  
tables/databases, until such time as the counter wrapped around.  
  
While in itself this isn't worse than the situation pre-9.3, where we did  
not manage MXID wraparound risk at all, the consequences of premature  
truncation of pg_multixact are worse now; so we ought to make some effort  
to cope with this.  We discussed advising users to fix the tracking values  
manually, but that seems both very tedious and very error-prone.  
  
Instead, this patch adopts two amelioration rules.  First, a relminmxid  
value that is "in the future" is allowed to be overwritten with a  
full-table VACUUM's actual freeze cutoff, ignoring the normal rule that  
relminmxid should never go backwards.  (This essentially assumes that we  
have enough defenses in place that wraparound can never occur anymore,  
and thus that a value "in the future" must be corrupt.)  Second, if we see  
any "in the future" values then we refrain from truncating pg_clog and  
pg_multixact.  This prevents loss of clog data until we have cleaned up  
all the broken tracking data.  In the worst case that could result in  
considerable clog bloat, but in practice we expect that relfrozenxid-driven  
freezing will happen soon enough to fix the problem before clog bloat  
becomes intolerable.  (Users could do manual VACUUM FREEZEs if not.)  
  
Note that this mechanism cannot save us if there are already-wrapped or  
already-truncated-away MXIDs in the table; it's only capable of dealing  
with corrupt tracking values.  But that's the situation we have with the  
pg_upgrade bug.  
  
For consistency, apply the same rules to relfrozenxid/datfrozenxid.  There  
are not known mechanisms for these to get messed up, but if they were, the  
same tactics seem appropriate for fixing them.  

commit   : 4bcdfb930e0477def194a651f043eaf9c8b82818    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Jul 2014 01:07:36 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Jul 2014 01:07:36 -0400    

commit   : 2f2b7879edca272ae5ff52e27fcf7b8c09503153    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Jul 2014 00:42:32 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 21 Jul 2014 00:42:32 -0400    

commit   : be72263635dc95b4ada1bda3494c815fbd8987c3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Jul 2014 22:20:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Jul 2014 22:20:38 -0400    

Rather remarkable that this has been wrong since 9.1 and nobody noticed.  

commit   : e5ea60e80bf0b2941c63c64d0a9de4f103ec8d58    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Jul 2014 15:00:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Jul 2014 15:00:50 -0400    

DST law changes in Crimea, Egypt, Morocco.  New zone Antarctica/Troll  
for Norwegian base in Queen Maud Land.  

commit   : f0a497e4c499b3283b10d6092388413f9a565d65    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Jul 2014 14:28:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 19 Jul 2014 14:28:25 -0400    

When a view has a function-returning-composite in FROM, and there are  
some dropped columns in the underlying composite type, ruleutils.c  
printed junk in the column alias list for the reconstructed FROM entry.  
Before 9.3, this was prevented by doing get_rte_attribute_is_dropped  
tests while printing the column alias list; but that solution is not  
currently available to us for reasons I'll explain below.  Instead,  
check for empty-string entries in the alias list, which can only exist  
if that column position had been dropped at the time the view was made.  
(The parser fills in empty strings to preserve the invariant that the  
aliases correspond to physical column positions.)  
  
While this is sufficient to handle the case of columns dropped before  
the view was made, we have still got issues with columns dropped after  
the view was made.  In particular, the view could contain Vars that  
explicitly reference such columns!  The dependency machinery really  
ought to refuse the column drop attempt in such cases, as it would do  
when trying to drop a table column that's explicitly referenced in  
views.  However, we currently neglect to store dependencies on columns  
of composite types, and fixing that is likely to be too big to be  
back-patchable (not to mention that existing views in existing databases  
would not have the needed pg_depend entries anyway).  So I'll leave that  
for a separate patch.  
  
Pre-9.3, ruleutils would print such Vars normally (with their original  
column names) even though it suppressed their entries in the RTE's  
column alias list.  This is certainly bogus, since the printed view  
definition would fail to reload, but at least it didn't crash.  However,  
as of 9.3 the printed column alias list is tightly tied to the names  
printed for Vars; so we can't treat columns as dropped for one purpose  
and not dropped for the other.  This is why we can't just put back the  
get_rte_attribute_is_dropped test: it results in an assertion failure  
if the view in fact contains any Vars referencing the dropped column.  
Once we've got dependencies preventing such cases, we'll probably want  
to do it that way instead of relying on the empty-string test used here.  
  
This fix turned up a very ancient bug in outfuncs/readfuncs, namely  
that T_String nodes containing empty strings were not dumped/reloaded  
correctly: the node was printed as "<>" which is read as a string  
value of <>.  Since (per SQL) we disallow empty-string identifiers,  
such nodes don't occur normally, which is why we'd not noticed.  
(Such nodes aren't used for literal constants, just identifiers.)  
  
Per report from Marc Schablewski.  Back-patch to 9.3 which is where  
the rule printing behavior changed.  The dangling-variable case is  
broken all the way back, but that's not what his complaint is about.  

commit   : f0af51d077b392cac4ce25e1347a4fc3b050d832    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 18 Jul 2014 16:05:17 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 18 Jul 2014 16:05:17 -0400    

~/.pgpass is a sound choice everywhere, and "peer" authentication is  
safe on every platform it supports.  Cease to recommend "trust"  
authentication, the safety of which is deeply configuration-specific.  
Back-patch to 9.0, where pg_upgrade was introduced.  

commit   : 4a66f0f2d5a758f282549555feec4541c35588c4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jul 2014 13:00:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 18 Jul 2014 13:00:27 -0400    

If pg_regcomp failed after having invoked markst/cleanst, it would leak any  
"struct subre" nodes it had created.  (We've already detected all regex  
syntax errors at that point, so the only likely causes of later failure  
would be query cancel or out-of-memory.)  To fix, make sure freesrnode  
knows the difference between the pre-cleanst and post-cleanst cleanup  
procedures.  Add some documentation of this less-than-obvious point.  
  
Also, newlacon did the wrong thing with an out-of-memory failure from  
realloc(), so that the previously allocated array would be leaked.  
  
Both of these are pretty low-probability scenarios, but a bug is a bug,  
so patch all the way back.  
  
Per bug #10976 from Arthur O'Dwyer.  

commit   : 9fb149573dee5dc0b2849b4cdee5d5ffe83313d9    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 16 Jul 2014 22:20:15 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 16 Jul 2014 22:20:15 -0400    

commit   : 9b3ef66afe132e1f71e2577f513f28bee5fef39e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 16 Jul 2014 09:10:54 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 16 Jul 2014 09:10:54 +0300    

The consistent function contained several bugs:  
  
* The "if (which2) { ... }"  block was broken. It compared the  argument's  
lower bound against centroid's upper bound, while it was supposed to compare  
the argument's upper bound against the centroid's lower bound (the comment  
was correct, code was wrong). Also, it cleared bits in the "which1"  
variable, while it was supposed to clear bits in "which2".  
  
* If the argument's upper bound was equal to the centroid's lower bound, we  
descended to both halves (= all quadrants). That's unnecessary, searching  
the right quadrants is sufficient. This didn't lead to incorrect query  
results, but was clearly wrong, and slowed down queries unnecessarily.  
  
* In the case that argument's lower bound is adjacent to the centroid's  
upper bound, we also don't need to visit all quadrants. Per similar  
reasoning as previous point.  
  
* The code where we compare the previous centroid with the current centroid  
should match the code where we compare the current centroid with the  
argument. The point of that code is to redo the calculation done in the  
previous level, to see if we were supposed to traverse left or right (or up  
or down), and if we actually did. If we moved in the different direction,  
then we know there are no matches for bound.  
  
Refactor the code and adds comments to make it more readable and easier to  
reason about.  
  
Backpatch to 9.3 where SP-GiST support for range types was introduced.  

commit   : 0e34d82538bd48fc537d512539cee014654a45e1    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 15 Jul 2014 22:00:56 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 15 Jul 2014 22:00:56 +0200    

Mingw uses a different header file than msvc, so we don't get the  
hardcoded value, so we need the configure test to run.  

commit   : 3b70e973cf8363c84b2ef2958aea38f523765f44    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Jul 2014 14:34:33 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Jul 2014 14:34:33 -0400    

commit   : e763ec989cb8b75ab010cc809cf9f5d6c2418da0    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Jul 2014 14:33:59 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Jul 2014 14:33:59 -0400    

commit   : 7466037596bfdf1223f1759c7a0e4aaabff0cb53    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Jul 2014 14:32:55 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Jul 2014 14:32:55 -0400    

It was previously not clear what unit the option argument should have.  

commit   : 05011b6da5d0318710c272bfe23b84d8adc61332    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 15 Jul 2014 14:24:47 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 15 Jul 2014 14:24:47 -0400    

These functions indirectly invoke output functions, so they can't be  
immutable.  
  
Backpatch to 9.4 where they were introduced.  
  
Catalog version bumped.  

commit   : e45229bb66f52518cb07c38fe3d262502cd2d0c9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 15 Jul 2014 13:24:07 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 15 Jul 2014 13:24:07 -0400    

Trying to reassign objects owned by a user that had text search  
dictionaries or configurations used to fail with:  
ERROR:  unexpected classid 3600  
or  
ERROR:  unexpected classid 3602  
  
Fix by adding cases for those object types in a switch in pg_shdepend.c.  
  
Both REASSIGN OWNED and text search objects go back all the way to 8.1,  
so backpatch to all supported branches.  In 9.3 the alter-owner code was  
made generic, so the required change in recent branches is pretty  
simple; however, for 9.2 and older ones we need some additional  
reshuffling to enable specifying objects by OID rather than name.  
  
Text search templates and parsers are not owned objects, so there's no  
change required for them.  
  
Per bug #9749 reported by Michal Novotný  

commit   : 5e4c9b37312e7d9dcb88e1e0a1fc279c780dd89e    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 15 Jul 2014 18:04:43 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 15 Jul 2014 18:04:43 +0200    

Apparently we still build against OpenSSL so old that it doesn't  
have this function, so add an autoconf check for it to make the  
buildfarm happy. If the function doesn't exist, always return  
that compression is disabled, since presumably the actual  
compression functionality is always missing.  
  
For now, hardcode the function as present on MSVC, since we should  
hopefully be well beyond those old versions on that platform.  

commit   : 77b41010dbb159b77b35aef02b517ce1a130f3b6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Jul 2014 10:00:53 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Jul 2014 10:00:53 -0400    

These are files under common/ that have been moved around.  Updating  
these manually is not satisfactory, but it's the only solution at the  
moment.  

commit   : d3c980694fa4523a8aa66b57343f031c4b6b8425    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 15 Jul 2014 15:07:38 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 15 Jul 2014 15:07:38 +0200    

Both the psql banner and the connection logging already included  
SSL status, cipher and bitlength, this adds the information about  
compression being on or off.  

commit   : 350651905decd60637e583837d3bb3aa5d9164b6    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Jul 2014 08:25:27 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 15 Jul 2014 08:25:27 -0400    

Also update one place where the wal_level "logical" was not added to an  
error message.  

commit   : a53878fd5a639802237fcd883421d4ea7cced5c5    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 14 Jul 2014 20:37:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 14 Jul 2014 20:37:00 -0400    

From: Josh Kupershmidt <schmiddy@gmail.com>  

commit   : 28a935149fcf65c9b1b6c28c4131ed72e5183762    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 14 Jul 2014 17:24:40 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 14 Jul 2014 17:24:40 -0400    

Per discussion after a gripe from me in  
http://www.postgresql.org/message-id/20140611194633.GH18688@eldon.alvh.no-ip.org  
  
Jaime Casanova  

commit   : 543f57fc37e5d18ad4937fe11efd8e58d8fc7b23    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 14 Jul 2014 20:40:14 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 14 Jul 2014 20:40:14 +0900    

EXPLAIN ANALYZE shows the information of the numbers of exact/lossy blocks which  
bitmap heap scan processes. But, previously, when those numbers were both zero,  
it displayed only the prefix "Heap Blocks:" in TEXT output format. This is strange  
and would confuse the users. So this commit suppresses such unnecessary information.  
  
Backpatch to 9.4 where EXPLAIN ANALYZE was changed so that such information was  
displayed.  
  
Etsuro Fujita  

commit   : 22ccce5206717036a06aefdf3f9f78ed9ffaab2f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 12 Jul 2014 14:28:19 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 12 Jul 2014 14:28:19 +0200    

Commit 1b86c81d2d fixed the decoding of toasted columns for the rows  
contained in one xl_heap_multi_insert record. But that's not actually  
enough, because heap_multi_insert() will actually first toast all  
passed in rows and then emit several *_multi_insert records; one for  
each page it fills with tuples.  
  
Add a XLOG_HEAP_LAST_MULTI_INSERT flag which is set in  
xl_heap_multi_insert->flag denoting that this multi_insert record is  
the last emitted by one heap_multi_insert() call. Then use that flag  
in decode.c to only set clear_toast_afterwards in the right situation.  
  
Expand the number of rows inserted via COPY in the corresponding  
regression test to make sure that more than one heap page is filled  
with tuples by one heap_multi_insert() call.  
  
Backpatch to 9.4 like the previous commit.  

commit   : bb4d05c026a7b811fa081d994bc02133fb6d13b1    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sat, 12 Jul 2014 14:19:57 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sat, 12 Jul 2014 14:19:57 +0200    

Adds support for autocomplete of LC_COLLATE and LC_CTYPE to  
the CREATE DATABASE command in psql.  

commit   : f280eff94974d4f50a927120d45580bb14c27e87    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jul 2014 19:12:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 11 Jul 2014 19:12:38 -0400    

ExecEvalWholeRowVar incorrectly supposed that it could "bless" the source  
TupleTableSlot just once per query.  But if the input is coming from an  
Append (or, perhaps, other cases?) more than one slot might be returned  
over the query run.  This led to "record type has not been registered"  
errors when a composite datum was extracted from a non-blessed slot.  
  
This bug has been there a long time; I guess it escaped notice because when  
dealing with subqueries the planner tends to expand whole-row Vars into  
RowExprs, which don't have the same problem.  It is possible to trigger  
the problem in all active branches, though, as illustrated by the added  
regression test.  

commit   : 6fe24405fa2e79d653daaf5c078e2a9d0a4b2c0c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 2 Jul 2014 21:07:47 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 2 Jul 2014 21:07:47 +0200    

The old name wasn't very descriptive as of actual contents of the  
directory, which are historical snapshots in the snapshots/  
subdirectory and mappingdata for rewritten tuples in  
mappings/. There's been a fair amount of discussion what would be a  
good name. I'm settling for pg_logical because it's likely that  
further data around logical decoding and replication will need saving  
in the future.  
  
Also add the missing entry for the directory into storage.sgml's list  
of PGDATA contents.  
  
Bumps catversion as the data directories won't be compatible.  
  
Backpatch to 9.4, which I missed to do as Michael Paquier luckily  
noticed. As there already has been a catversion bump after 9.4beta1,  
there's no reasons for having 9.4 diverge from master.  

commit   : 8adb4769954f072636a1c139517d08b6ba860779    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 8 Jul 2014 23:29:09 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 8 Jul 2014 23:29:09 -0400    

commit   : 845b3c3bb58c704374321c54307b36aa1fb4625a    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 8 Jul 2014 14:54:32 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 8 Jul 2014 14:54:32 -0400    

commit   : 44850ec32a1463782055092002dd4e9cbc6f5c5f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 8 Jul 2014 14:14:37 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 8 Jul 2014 14:14:37 -0400    

commit   : ac45aa1dde2dd690682bf74f7535ba6d1a87bff8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jul 2014 14:03:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 8 Jul 2014 14:03:16 -0400    

While the x output of "select x from t group by x" can be presumed unique,  
this does not hold for "select x, generate_series(1,10) from t group by x",  
because we may expand the set-returning function after the grouping step.  
(Perhaps that should be re-thought; but considering all the other oddities  
involved with SRFs in targetlists, it seems unlikely we'll change it.)  
Put a check in query_is_distinct_for() so it's not fooled by such cases.  
  
Back-patch to all supported branches.  
  
David Rowley  

commit   : 443dd97001c4cdb78ec388fffd5780ddccb3218f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 8 Jul 2014 11:39:07 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 8 Jul 2014 11:39:07 -0400    

commit   : f64fe2cbe6f1ec74a97e32d152d02ff9e371da14    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 7 Jul 2014 13:24:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 7 Jul 2014 13:24:08 -0400    

Previously, when calculations on the need for toast tables changed,  
pg_upgrade could not handle cases where the new cluster needed a TOAST  
table and the old cluster did not.  (It already handled the opposite  
case.)  This fixes the "OID mismatch" error typically generated in this  
case.  
  
Backpatch through 9.2  

commit   : d54712e7cf2e8925d1e04782a0aec88eae2be72c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 6 Jul 2014 15:58:01 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 6 Jul 2014 15:58:01 +0200    

When decoding the results of a HEAP2_MULTI_INSERT (currently only  
generated by COPY FROM) toast columns for all but the last tuple  
weren't replaced by their actual contents before being handed to the  
output plugin. The reassembled toast datums where disregarded after  
every REORDER_BUFFER_CHANGE_(INSERT|UPDATE|DELETE) which is correct  
for plain inserts, updates, deletes, but not multi inserts - there we  
generate several REORDER_BUFFER_CHANGE_INSERTs for a single  
xl_heap_multi_insert record.  
  
To solve the problem add a clear_toast_afterwards boolean to  
ReorderBufferChange's union member that's used by modifications. All  
row changes but multi_inserts always set that to true, but  
multi_insert sets it only for the last change generated.  
  
Add a regression test covering decoding of multi_inserts - there was  
none at all before.  
  
Backpatch to 9.4 where logical decoding was introduced.  
  
Bug found by Petr Jelinek.  

commit   : 49c279efe7858454114bd304444e95573be0804b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 6 Jul 2014 00:29:51 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 6 Jul 2014 00:29:51 -0400    

The isxdigit() calls relied on undefined behavior.  The isascii() call  
was well-defined, but our prevailing style is to include the cast.  
Back-patch to 9.4, where the isxdigit() calls were introduced.  

commit   : e44964c709b4a5f18d3f9a8fe6d5c259091315c1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2014 18:47:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2014 18:47:09 -0400    

Although nodeAgg.c currently uses the same per-group memory context for  
all groups of a query, that might change in future.  Avoid assuming it.  
This costs us an extra AggCheckCallContext() call per group, but that's  
pretty cheap and is probably good from a safety standpoint anyway.  
  
Back-patch to 9.4 in case any third-party code copies this logic.  
  
Andrew Gierth  

commit   : f688cf548b3e37991009b7a3607171242c796e62    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2014 18:25:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Jul 2014 18:25:37 -0400    

The previous design exposed the input and output ExprContexts of the  
Agg plan node, but work on grouping sets has suggested that we'll regret  
doing that.  Instead provide more narrowly-defined APIs that can be  
implemented in multiple ways, namely a way to get a short-term memory  
context and a way to register an aggregate shutdown callback.  
  
Back-patch to 9.4 where the bad APIs were introduced, since we don't  
want third-party code using these APIs and then having to change in 9.5.  
  
Andrew Gierth  

commit   : 6b56bc16cdf0c59e7d18ec046b2ed63bc82faf7b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 2 Jul 2014 21:44:02 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 2 Jul 2014 21:44:02 -0400    

Creating the Unix-domain socket in the build directory can run into  
name-length limitations.  Therefore, create the socket file in the  
default temporary directory of the operating system.  Keep the temporary  
data directory etc. in the build tree.  

commit   : 04163ff1b98651ac2e04384ae8d84d8d1cb5dd60    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 2 Jul 2014 21:47:07 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 2 Jul 2014 21:47:07 -0400    

commit   : 93787ce7477b0d718bdcdb88605725792f36697e    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 2 Jul 2014 15:03:57 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 2 Jul 2014 15:03:57 -0500    

If a connection committed or rolled back any transactions within a  
PGSTAT_STAT_INTERVAL pacing interval without accessing any tables,  
the reporting of those statistics would be held up until the  
connection closed or until it ended a PGSTAT_STAT_INTERVAL interval  
in which it had accessed a table.  This could result in under-  
reporting of transactions for an extended period, followed by a  
spike in reported transactions.  
  
While this is arguably a bug, the impact is minimal, primarily  
affecting, and being affected by, monitoring software.  It might  
cause more confusion than benefit to change the existing behavior  
in released stable branches, so apply only to master and the 9.4  
beta.  
  
Gurjeet Singh, with review and editing by Kevin Grittner,  
incorporating suggested changes from Abhijit Menon-Sen and Tom  
Lane.  

commit   : b446a384b7c231e3fa10dfb0fbc9247a6b329348    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 2 Jul 2014 15:29:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 2 Jul 2014 15:29:38 -0400    

Also set these values for pre-9.3 old clusters that don't have values to  
preserve.  
  
Analysis by Alvaro  
  
Backpatch through 9.3  

commit   : fbbb65daa22c4fee8b608dfc39e41cb36a751cd2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 2 Jul 2014 13:11:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 2 Jul 2014 13:11:05 -0400    

Per analysis by Alvaro  
  
Backpatch through 9.3  

commit   : cec3be05f624bc32599c2a056ec1b47bec917510    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jul 2014 12:31:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 2 Jul 2014 12:31:27 -0400    

This function wasn't originally thought to be really user-facing,  
because converting a table to a view isn't something we expect people  
to do manually.  So not all that much effort was spent on the error  
messages; in particular, while the code will complain that you got  
the column types wrong it won't say exactly what they are.  But since  
we repurposed the code to also check compatibility of rule RETURNING  
lists, it's definitely user-facing.  It now seems worthwhile to add  
errdetail messages showing exactly what the conflict is when there's  
a mismatch of column names or types.  This is prompted by bug #10836  
from Matthias Raffelsieper, which might have been forestalled if the  
error message had reported the wrong column type as being "record".  
  
Back-patch to 9.4, but not into older branches where the set of  
translatable error strings is supposed to be stable.  

commit   : 5520006b5bbaa36e6734a8ccf960bb870f4a4fec    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 2 Jul 2014 12:42:20 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 2 Jul 2014 12:42:20 +0900    

The autocommit-off mode works by issuing an implicit BEGIN just before  
any command that is not already in a transaction block and is not itself  
a BEGIN or other transaction-control command, nor a command that  
cannot be executed inside a transaction block. This commit prevents psql  
from issuing such an implicit BEGIN before ALTER SYSTEM because it's  
not allowed inside a transaction block.  
  
Backpatch to 9.4 where ALTER SYSTEM was added.  
  
Report by Feike Steenbergen  

commit   : 49bca9ea53f6428f7ac6372ad4dd47ecacfac395    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jul 2014 11:22:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 1 Jul 2014 11:22:46 -0400    

The output buffer size in unaccent_lexize() was calculated as input string  
length times pg_database_encoding_max_length(), which effectively assumes  
that replacement strings aren't more than one character.  While that was  
all that we previously documented it to support, the code actually has  
always allowed replacement strings of arbitrary length; so if you tried  
to make use of longer strings, you were at risk of buffer overrun.  To fix,  
use an expansible StringInfo buffer instead of trying to determine the  
maximum space needed a-priori.  
  
This would be a security issue if unaccent rules files could be installed  
by unprivileged users; but fortunately they can't, so in the back branches  
the problem can be labeled as improper configuration by a superuser.  
Nonetheless, a memory stomp isn't a nice way of reacting to improper  
configuration, so let's back-patch the fix.  

commit   : 4dc3df9d193838060ec97dd29899e33676796ab5    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 30 Jun 2014 19:57:47 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 30 Jun 2014 19:57:47 -0400    

There were some C comments that hadn't been updated from the switch of  
using only pg_dumpall to using pg_dump and pg_dumpall, so update them.  
Also, don't bother using --schema-only for pg_dumpall --globals-only.  
  
Backpatch through 9.4  

commit   : 37a4d3d70617f574b9a3dd5af079430b24817333    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 30 Jun 2014 16:59:19 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 30 Jun 2014 16:59:19 -0400    

This function continued to use it after heap_endscan() freed it.  In  
passing, don't explicit create a strategy here.  Instead, use the one  
created by heap_beginscan_strat(), if any.  Back-patch to 9.2, where use  
of a BufferAccessStrategy here was introduced.  

commit   : 6ad903d70a440eb0fbe0b33ceb87a8b0a81cb240    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 29 Jun 2014 17:08:04 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 29 Jun 2014 17:08:04 +0200    

When reading large amounts of preexisting WAL during logical decoding  
using the SQL interface we possibly could fail to check interrupts in  
due time. Similarly the same could happen on systems with a very high  
WAL volume while creating a new logical replication slot, independent  
of the used interface.  
  
Previously these checks where only performed in xlogreader's read_page  
callbacks, while waiting for new WAL to be produced. That's not  
sufficient though, if there's never a need to wait.  Walsender's send  
loop already contains a interrupt check.  
  
Backpatch to 9.4 where the logical decoding feature was introduced.  

commit   : d27d493a4e465c7b3a9e2749e0b69d51aa1e3133    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 30 Jun 2014 10:23:18 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 30 Jun 2014 10:23:18 +0300    

Per discussion, it still fires too often to be safe to enable in  
production. Keep it in master, so that we find the issues, but disable it  
in the stable branch.  

commit   : 3130b8505ffcc3dae053939824c72291f6cdff3b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Jun 2014 13:51:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Jun 2014 13:51:02 -0400    

The "false" case was really quite useless since all it did was to throw  
an error; a definition not helped in the least by making it the default.  
Instead let's just have the "true" case, which emits nested objects and  
arrays in JSON syntax.  We might later want to provide the ability to  
emit sub-objects in Postgres record or array syntax, but we'd be best off  
to drive that off a check of the target field datatype, not a separate  
argument.  
  
For the functions newly added in 9.4, we can just remove the flag arguments  
outright.  We can't do that for json_populate_record[set], which already  
existed in 9.3, but we can ignore the argument and always behave as if it  
were "true".  It helps that the flag arguments were optional and not  
documented in any useful fashion anyway.  

commit   : 56f86bb764bb99a32810c52976926f85cc3bf3b1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Jun 2014 14:43:52 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Jun 2014 14:43:52 -0400    

Instead of truncating pg_multixact at vacuum time, do it only at  
checkpoint time.  The reason for doing it this way is twofold: first, we  
want it to delete only segments that we're certain will not be required  
if there's a crash immediately after the removal; and second, we want to  
do it relatively often so that older files are not left behind if  
there's an untimely crash.  
  
Per my proposal in  
http://www.postgresql.org/message-id/20140626044519.GJ7340@eldon.alvh.no-ip.org  
we now execute the truncation in the checkpointer process rather than as  
part of vacuum.  Vacuum is in only charge of maintaining in shared  
memory the value to which it's possible to truncate the files; that  
value is stored as part of checkpoints also, and so upon recovery we can  
reuse the same value to re-execute truncate and reset the  
oldest-value-still-safe-to-use to one known to remain after truncation.  
  
Per bug reported by Jeff Janes in the course of his tests involving  
bug #8673.  
  
While at it, update some comments that hadn't been updated since  
multixacts were changed.  
  
Backpatch to 9.3, where persistency of pg_multixact files was  
introduced by commit 0ac5ad5134f2.  

commit   : 9eecc8a7cafa2be356a859f74c5db5961e190579    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Jun 2014 14:43:46 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Jun 2014 14:43:46 -0400    

We were allowing a table's pg_class.relminmxid value to move backwards  
when heaps were swapped by VACUUM FULL or CLUSTER.  There is a  
similar protection against relfrozenxid going backwards, which we  
neglected to clone when the multixact stuff was rejiggered by commit  
0ac5ad5134f276.  
  
Backpatch to 9.3, where relminmxid was introduced.  
  
As reported by Heikki in  
http://www.postgresql.org/message-id/52401AEA.9000608@vmware.com  

commit   : 4c888a6290add7ab86078c8759f0de1bd74c7377    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Jun 2014 14:43:39 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Jun 2014 14:43:39 -0400    

Don't assert MultiXactIdIsRunning if the multi came from a tuple that  
had been share-locked and later copied over to the new cluster by  
pg_upgrade.  Doing that causes an error to be raised unnecessarily:  
MultiXactIdIsRunning is not open to the possibility that its argument  
came from a pg_upgraded tuple, and all its other callers are already  
checking; but such multis cannot, obviously, have transactions still  
running, so the assert is pointless.  
  
Noticed while investigating the bogus pg_multixact/offsets/0000 file  
left over by pg_upgrade, as reported by Andres Freund in  
http://www.postgresql.org/message-id/20140530121631.GE25431@alap3.anarazel.de  
  
Backpatch to 9.3, as the commit that introduced the buglet.  

commit   : 6327f25dddba0c359f8be8395e1b2d99dfe0d30c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Jun 2014 11:08:51 -0700    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Jun 2014 11:08:51 -0700    

A WHERE clause applied to the output of a subquery with DISTINCT should  
theoretically be applied only once per distinct row; but if we push it  
into the subquery then it will be evaluated at each row before duplicate  
elimination occurs.  If the qual is volatile this can give rise to  
observably wrong results, so don't do that.  
  
While at it, refactor a little bit to allow subquery_is_pushdown_safe  
to report more than one kind of restrictive condition without indefinitely  
expanding its argument list.  
  
Although this is a bug fix, it seems unwise to back-patch it into released  
branches, since it might de-optimize plans for queries that aren't giving  
any trouble in practice.  So apply to 9.4 but not further back.  

commit   : c3096d57c8faa24aa5ff4cc7e87d989ce42ad05d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jun 2014 16:22:18 -0700    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jun 2014 16:22:18 -0700    

These should not have existed to begin with, but there was apparently some  
misunderstanding of the purpose of the opr_sanity regression test item  
that checks for operator implementation functions with their own comments.  
The idea there is to check for unintentional violations of the rule that  
operator implementation functions shouldn't be documented separately  
.... but for these functions, that is in fact what we want, since the  
variadic option is useful and not accessible via the operator syntax.  
Get rid of the extra pg_proc entries and fix the regression test and  
documentation to be explicit about what we're doing here.  

commit   : 973837450c764b585321c965179eb8a57380ab5c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jun 2014 10:40:55 -0700    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Jun 2014 10:40:55 -0700    

Commit a87c729153e372f3731689a7be007bc2b53f1410 already fixed the bug this  
is checking for, but the regression test case it added didn't cover this  
scenario.  Since we managed to miss the fact that there was a bug at all,  
it seems like a good idea to propagate the extra test case forward to HEAD.  

commit   : 2a741ca7658167c9061f9d0095992b326d6ffdbb    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 26 Jun 2014 14:27:27 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 26 Jun 2014 14:27:27 +0900    

7380b63 changed log_filename so that epoch was not appended to it  
when no format specifier is given. But the example of CSV log file name  
with epoch still left in log_filename document. This commit removes  
such obsolete example.  
  
This commit also documents the defaults of log_directory and  
log_filename.  
  
Backpatch to all supported versions.  
  
Christoph Berg  

commit   : 119fed85f5f68e8fb146549e3267026c9fdc8640    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Jun 2014 15:25:26 -0700    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Jun 2014 15:25:26 -0700    

I noticed that the functions in jsonfuncs.c sometimes printed error  
messages that claimed I'd called some other function.  Investigation showed  
that this was from repurposing code into "worker" functions without taking  
much care as to whether it would mention the right SQL-level function if it  
threw an error.  Moreover, there was a weird mismash of messages that  
contained a fixed function name, messages that used %s for a function name,  
and messages that constructed a function name out of spare parts, like  
"json%s_populate_record" (which, quite aside from being ugly as sin, wasn't  
even sufficient to cover all the cases).  This would put an undue burden on  
our long-suffering translators.  Standardize on inserting the SQL function  
name with %s so as to reduce the number of translatable strings, and pass  
function names around as needed to make sure we can report the right one.  
Fix up some gratuitous variations in wording, too.  

commit   : 199aa7108794db50c64b55327e4c81d1c2f414a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Jun 2014 11:22:21 -0700    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Jun 2014 11:22:21 -0700    

Re-pgindent, remove a lot of random vertical whitespace, remove useless  
(if not counterproductive) inline markings, get rid of unnecessary  
zero-padding of strings for hashtable searches.  No functional changes.  

commit   : a331512dec25807c4c93e3d537ac7734ee901641    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Jun 2014 21:22:43 -0700    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Jun 2014 21:22:43 -0700    

populate_recordset_object_start() improperly created a new hash table  
(overwriting the link to the existing one) if called at nest levels  
greater than one.  This resulted in previous fields not appearing in  
the final output, as reported by Matti Hameister in bug #10728.  
In 9.4 the problem also affects json_to_recordset.  
  
This perhaps missed detection earlier because the default behavior is to  
throw an error for nested objects: you have to pass use_json_as_text = true  
to see the problem.  
  
In addition, fix query-lifespan leakage of the hashtable created by  
json_populate_record().  This is pretty much the same problem recently  
fixed in dblink: creating an intended-to-be-temporary context underneath  
the executor's per-tuple context isn't enough to make it go away at the  
end of the tuple cycle, because MemoryContextReset is not  
MemoryContextResetAndDeleteChildren.  
  
Michael Paquier and Tom Lane  

commit   : dd5369047fc3400f4b5d1d61d85b040a8eef8d1b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 24 Jun 2014 16:11:06 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 24 Jun 2014 16:11:06 -0400    

This fixes a bug that caused vacuum to fail when the '0000' files left  
by initdb were accessed as part of vacuum's cleanup of old pg_multixact  
files.  
  
Backpatch through 9.3  

commit   : 1818ae0a789ec360d8641c98520f832b9fd9c0ef    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 24 Jun 2014 12:31:36 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 24 Jun 2014 12:31:36 +0300    

The syntax doesn't let you specify "WITH OIDS" for foreign tables, but it  
was still possible with default_with_oids=true. But the rest of the system,  
including pg_dump, isn't prepared to handle foreign tables with OIDs  
properly.  
  
Backpatch down to 9.1, where foreign tables were introduced. It's possible  
that there are databases out there that already have foreign tables with  
OIDs. There isn't much we can do about that, but at least we can prevent  
them from being created in the future.  
  
Patch by Etsuro Fujita, reviewed by Hadi Moshayedi.  

commit   : e9b182404b67eef9a263c3d07b89cb60b26bed7b    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Jun 2014 03:51:51 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Jun 2014 03:51:51 +0900    

commit   : c6d0df9492b12ce657de8512a93dd473f3eff5d9    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Jun 2014 03:25:01 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Jun 2014 03:25:01 +0900    

commit   : a2586dece1953e7c395b533bf52b54b5e7bb3a3c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 21 Jun 2014 15:33:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 21 Jun 2014 15:33:22 -0400    

Backpatch through 9.4  

commit   : 750c0351ea9c07e2398a2e116ed7d48dbc42b489    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 21 Jun 2014 10:56:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 21 Jun 2014 10:56:37 -0400    

Backpatch to 9.4  

commit   : bcd67a2fe97eaf3f83b5ddb72aaffff34f4d441f    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 21 Jun 2014 09:17:14 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sat, 21 Jun 2014 09:17:14 -0500    

By using curly braces, the template had specified that one of  
"NOT DEFERRABLE", "INITIALLY IMMEDIATE", or "INITIALLY DEFERRED"  
was required on any CREATE TRIGGER statement, which is not  
accurate.  Change to square brackets makes that optional.  
  
Backpatch to 9.1, where the error was introduced.  

commit   : 9d884a34c343641f7ab3c24377d7ec0970df4eea    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Fri, 20 Jun 2014 12:22:34 -0700    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Fri, 20 Jun 2014 12:22:34 -0700    

dblink uses a short-lived data conversion memory context. However it  
was not deleted when no longer needed, leading to a noticeable memory  
leak under some circumstances. Plug the hole, along with minor  
refactoring. Backpatch to 9.2 where the leak was introduced.  
  
Report and initial patch by MauMau. Reviewed/modified slightly by  
Tom Lane and me.  

commit   : 4bc0a13a8a6af0320923a89238b7ab3f27c28d56    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 20 Jun 2014 11:06:48 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 20 Jun 2014 11:06:48 +0200    

Since fdf9e21196a lazy_vacuum_page() rechecks the all-visible status  
of pages in the second pass over the heap. It does so inside a  
critical section, but both visibilitymap_test() and  
heap_page_is_all_visible() perform operations that should not happen  
inside one. The former potentially performs IO and both potentially do  
memory allocations.  
  
To fix, simply move all the all-visible handling outside the critical  
section. Doing so means that the PD_ALL_VISIBLE on the page won't be  
included in the full page image of the HEAP2_CLEAN record anymore. But  
that's fine, the flag will be set by the HEAP2_VISIBLE logged later.  
  
Backpatch to 9.3 where the problem was introduced. The bug only came  
to light due to the assertion added in 4a170ee9 and isn't likely to  
cause problems in production scenarios. The worst outcome is a  
avoidable PANIC restart.  
  
This also gets rid of the difference in the order of operations  
between master and standby mentioned in 2a8e1ac5.  
  
Per reports from David Leverton and Keith Fiske in bug #10533.  

commit   : 1044e79a0b7b21ddedd9e093394a34e8cc2d42bc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jun 2014 22:13:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jun 2014 22:13:44 -0400    

ExecMakeTableFunctionResult evaluated the arguments for a function-in-FROM  
in the query-lifespan memory context.  This is insignificant in simple  
cases where the function relation is scanned only once; but if the function  
is in a sub-SELECT or is on the inside of a nested loop, any memory  
consumed during argument evaluation can add up quickly.  (The potential for  
trouble here had been foreseen long ago, per existing comments; but we'd  
not previously seen a complaint from the field about it.)  To fix, create  
an additional temporary context just for this purpose.  
  
Per an example from MauMau.  Back-patch to all active branches.  

commit   : b488daf0d59614e801059e3558f73b65b0cf7e06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jun 2014 12:33:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Jun 2014 12:33:56 -0400    

Haribabu Kommi, somewhat rewritten by me  

commit   : 909cab83058b12cabec6fb10c945f67ef09de5ec    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Thu, 19 Jun 2014 08:51:54 -0500    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Thu, 19 Jun 2014 08:51:54 -0500    

Commit ea9df812d8502fff74e7bc37d61bdc7d66d77a7f failed to include  
NUM_BUFFER_PARTITIONS in this offset, resulting in a bad offset.  
Ultimately this threw off NUM_FIXED_LWLOCKS which is based on  
earlier offsets, leading to memory allocation problems.  It seems  
likely to have also caused increased LWLOCK contention when  
serializable transactions were used, because lightweight locks used  
for that overlapped others.  
  
Reported by Amit Kapila with analysis and fix.  
Backpatch to 9.4, where the bug was introduced.  

commit   : fc5cf383d9ae894e3c9e94701ce5dc468d334433    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 19 Jun 2014 20:31:20 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 19 Jun 2014 20:31:20 +0900    

data_directory could be set both in postgresql.conf and postgresql.auto.conf so far.  
This could cause some problematic situations like circular definition. To avoid such  
situations, this commit forbids a user to set data_directory in postgresql.auto.conf.  
  
Backpatch this to 9.4 where ALTER SYSTEM command was introduced.  
  
Amit Kapila, reviewed by Abhijit Menon-Sen, with minor adjustments by me.  

commit   : a6896e00058c55692347f898a9bc2a2974520df8    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 18 Jun 2014 19:28:20 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 18 Jun 2014 19:28:20 -0400    

The check was confusing and is a condition that should never in fact  
happen.  
  
Per gripe from Dmitry Dolgov.  

commit   : fd1afbbedc55014783b9730385967d73c31a1f37    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jun 2014 15:44:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Jun 2014 15:44:15 -0400    

Seems to have been introduced in 1a3458b6d8d202715a83c88474a1b63726d0929e.  

commit   : 8b4067e6ec051b5b50b9e8ae981708ce7c4bcf02    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 18 Jun 2014 15:16:48 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 18 Jun 2014 15:16:48 -0400    

commit   : cee1f48cb3e34dbd8435849369a7cd0f7cbc6d3b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 18 Jun 2014 09:21:50 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 18 Jun 2014 09:21:50 -0400    

Catch up with commit b8cc8f94730610c0189aa82dfec4ae6ce9b13e34's  
introduction of the HAVE_UUID_OSSP symbol to the principal build  
process.  Back-patch to 9.4, where that commit appeared.  

commit   : 9d90472a0ed4955678d7080ee6b2a53a7762f32b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 17 Jun 2014 11:28:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 17 Jun 2014 11:28:34 -0400    

Report by Peter Geoghegan  

commit   : 0ada6b84b058b76095ffffa69175e82b6f3e63ec    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 16 Jun 2014 15:33:19 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 16 Jun 2014 15:33:19 -0400    

This prevents several compiler warnings on Windows.  

commit   : 6583a75b282c221e143b57386c51f7d59305b51c    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Jun 2014 09:41:13 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Jun 2014 09:41:13 -0400    

Any OS user able to access the socket can connect as the bootstrap  
superuser and proceed to execute arbitrary code as the OS user running  
the test.  Protect against that by placing the socket in a temporary,  
mode-0700 subdirectory of /tmp.  The pg_regress-based test suites and  
the pg_upgrade test suite were vulnerable; the $(prove_check)-based test  
suites were already secure.  Back-patch to 8.4 (all supported versions).  
The hazard remains wherever the temporary cluster accepts TCP  
connections, notably on Windows.  
  
As a convenient side effect, this lets testing proceed smoothly in  
builds that override DEFAULT_PGSOCKET_DIR.  Popular non-default values  
like /var/run/postgresql are often unwritable to the build user.  
  
Security: CVE-2014-0067  

commit   : 598efaa37f4e223491cf326f2ab44414a934c014    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Jun 2014 09:41:13 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Jun 2014 09:41:13 -0400    

This function is pervasive on free software operating systems; import  
NetBSD's implementation.  Back-patch to 8.4, like the commit that will  
harness it.  

commit   : cc3e1553fa6786b3a8c673fc9d8ce0a258ba8809    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Jun 2014 19:57:59 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Jun 2014 19:57:59 -0400    

Per buildfarm member prairiedog.  Back-patch to 9.4, where the test was  
introduced.  
  
Reviewed by Tom Lane.  

commit   : b31218798a6a9119e88f08c4c646fe7236c01a5d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Jun 2014 19:57:41 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Jun 2014 19:57:41 -0400    

Back-patch to 9.4.  

commit   : c221a0e22768ed7b5aa67184944a50ca735de8dc    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Jun 2014 19:57:18 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Jun 2014 19:57:18 -0400    

Back-patch to 9.4, where .dir-locals.el was introduced.  

commit   : c3c1401ca23a6a990989da777c78f7c8a19ca282    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 20:14:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 20:14:36 -0400    

Prior to 9.0, pg_dump handled comments on large objects by dumping a bunch  
of COMMENT commands into a single BLOB COMMENTS archive object.  With  
sufficiently many such comments, some of the commands would likely get  
split across bufferloads when restoring, causing failures in  
direct-to-database restores (though no problem would be evident in text  
output).  This is the same type of issue we have with table data dumped as  
INSERT commands, and it can be fixed in the same way, by using a mini SQL  
lexer to figure out where the command boundaries are.  Fortunately, the  
COMMENT commands are no more complex to lex than INSERTs, so we can just  
re-use the existing lexer for INSERTs.  
  
Per bug #10611 from Jacek Zalewski.  Back-patch to all active branches.  

commit   : 3ba1776c568e36423ee66892481b6d1703f4fbd8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 18:59:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 18:59:06 -0400    

We should report the errno when we get a failure from functions like  
BufFileWrite.  "ERROR: write failed" is unreasonably taciturn for a  
case that's well within the realm of possibility; I've seen it a  
couple times in the buildfarm recently, in situations that were  
probably out-of-disk-space, but it'd be good to see the errno  
to confirm it.  
  
I think this code was originally written without assuming that  
the buffile.c functions would return useful errno; but most other  
callers *are* assuming that, and a quick look at the buffile code  
gives no reason to suppose otherwise.  
  
Also, a couple of the old messages were phrased on the assumption  
that a short read might indicate a logic bug in tuplestore itself;  
but that code's pretty well tested by now, so a filesystem-level  
problem seems much more likely.  

commit   : b37e574865f8b465a1c99a29dcdfcecf6eca32f5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 17:51:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 17:51:47 -0400    

Since we commonly test pg_dump/pg_restore by seeing whether they can dump  
and restore the regression test database, it behooves us to include some  
large objects in that test scenario.  
  
I tried to include a comment on one of these large objects to improve  
the test scenario further ... but it turns out that pg_upgrade fails to  
preserve comments on large objects, and its regression test notices  
the discrepancy.  So uncommenting that COMMENT is a TODO for later.  

commit   : 7e00e09872f194c3dc30faca6aff7c2a32b608f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 16:51:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 16:51:05 -0400    

Robert Frost is no longer with us, but his copyrights still are, so  
let's stop using "Stopping by Woods on a Snowy Evening" as test data  
before somebody decides to sue us.  Wordsworth is more safely dead.  

commit   : e6f6db300fef2e53080209ae00f19408203e5686    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 15:54:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 15:54:13 -0400    

Memorialize the expected output of the query that libpq has been using for  
many years to get the OIDs of large-object support functions.  Although  
we really ought to change the way libpq does this, we must expect that  
this query will remain in use in the field for the foreseeable future,  
so until we're ready to break compatibility with old libpq versions  
we'd better check the results stay the same.  See the recent lo_create()  
fiasco.  

commit   : e3489847d08beaa4b9dc2a84011719f0b848f3e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 15:39:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Jun 2014 15:39:09 -0400    

The previous naming broke the query that libpq's lo_initialize() uses  
to collect the OIDs of the server-side functions it requires, because  
that query effectively assumes that there is only one function named  
lo_create in the pg_catalog schema (and likewise only one lo_open, etc).  
  
While we should certainly make libpq more robust about this, the naive  
query will remain in use in the field for the foreseeable future, so it  
seems the only workable choice is to use a different name for the new  
function.  lo_from_bytea() won a small straw poll.  
  
Back-patch into 9.4 where the new function was introduced.  

commit   : d52a6c4944c1d83cfaae53e20561c53220e7968b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 12 Jun 2014 13:23:46 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 12 Jun 2014 13:23:46 +0200    

Change the order of checks in similar functions to be the same; remove  
a parameter that's not needed anymore; rename a memory context and  
expand a couple of comments.  
  
Per review comments from Amit Kapila  

commit   : 7f9fbb842b09da851e003a70c6c53fd8ca6c6f82    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Jun 2014 22:48:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Jun 2014 22:48:16 -0400    

When we grabbed this file off the Snowball project's website, we mistakenly  
supposed that it was in LATIN1 encoding, but evidently it was actually in  
LATIN2.  This resulted in ő (o-double-acute, U+0151, which is code 0xF5 in  
LATIN2) being misconverted into õ (o-tilde, U+00F5), as complained of in  
bug #10589 from Zoltán Sörös.  We'd have messed up u-double-acute too,  
but there aren't any of those in the file.  Other characters used in the  
file have the same codes in LATIN1 and LATIN2, which no doubt helped hide  
the problem for so long.  
  
The error is not only ours: the Snowball project also was confused about  
which encoding is required for Hungarian.  But dealing with that will  
require source-code changes that I'm not at all sure we'll wish to  
back-patch.  Fixing the stopword file seems reasonably safe to back-patch  
however.  

commit   : ab76208e3df6841b3770edeece57d0f048392237    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jun 2014 21:37:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jun 2014 21:37:18 -0400    

Although this bug is already fixed in post-9.2 branches, the case  
triggering it is quite different from what was under consideration  
at the time.  It seems worth memorializing this example in HEAD  
just to make sure it doesn't get broken again in future.  
  
Extracted from commit 187ae17300776f48b2bd9d0737923b1bf70f606e.  

commit   : c170655cc81fd5e3c152e951c52247171bb57611    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jun 2014 16:30:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Jun 2014 16:30:40 -0400    

Previously, the code used a node label of zero both for strings that  
contain no bytes beyond the inner tuple's prefix, and for cases where an  
"allTheSame" inner tuple has to be split to allow a string with a different  
next byte to be inserted into it.  Failing to distinguish these cases meant  
that if a string ending with the current prefix needed to be inserted into  
an allTheSame tuple, we got into an infinite loop, because after splitting  
the tuple we'd descend into the child allTheSame tuple and then find we  
need to split again.  
  
To fix, instead use -1 and -2 as the node labels for these two cases.  
This requires widening the node label type from "char" to int2, but  
fortunately SPGiST stores all pass-by-value node label types in their  
Datum representation, which means that this change is transparently upward  
compatible so far as the on-disk representation goes.  We continue to  
recognize zero as a dummy node label for reading purposes, but will not  
attempt to push new index entries down into such a label, so that the loop  
won't occur even when dealing with an existing index.  
  
Per report from Teodor Sigaev.  Back-patch to 9.2 where the faulty  
code was introduced.  

commit   : b0b263baab3e927fe4b4f35755b91ac8d1db8fe0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 9 Jun 2014 15:17:23 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 9 Jun 2014 15:17:23 -0400    

In a50d97625497b7 I already changed this, but got it wrong for the case  
where the number of members is larger than the number of entries that  
fit in the last page of the last segment.  
  
As reported by Serge Negodyuck in a followup to bug #8673.  

commit   : fe7337f2dc3177da19b647fcda3a33b73da82e14    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 5 Jun 2014 18:27:11 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 5 Jun 2014 18:27:11 +0200    

A ReorderBufferTransaction's end_lsn, the sentPtr advocated by  
walsender keepalive messages, and the end location remembered by the  
decoding get_*changes* SQL functions all use the location of the last  
read record + 1. I.e. the LSN points to the beginning of the next  
record. That cannot realistically be changed without changing the  
replication protocol because that's how keepalive messages have worked  
since 9.0.  
The bug is that the logic inside the snapshot builder, which decides  
whether a transaction's contents should be decoded, assumed the start  
location would point towards the last byte of the last record. The  
reason this didn't actually cause visible problems is that currently  
that decision is only made for commit records. Since interesting  
transactions always have at least one additional record - containing  
actual data - we'd never skip a transaction.  
But if there ever were transactions, or other events, with just one  
record containing important information, we'd skip them after stopping  
and restarting logical decoding.  

commit   : 5f93c37805e7485488480916b4585e098d3cc883    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jun 2014 11:31:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Jun 2014 11:31:06 -0400    

It's critical that the backend's idea of LOBLKSIZE match the way data has  
actually been divided up in pg_largeobject.  While we don't provide any  
direct way to adjust that value, doing so is a one-line source code change  
and various people have expressed interest recently in changing it.  So,  
just as with TOAST_MAX_CHUNK_SIZE, it seems prudent to record the value in  
pg_control and cross-check that the backend's compiled-in setting matches  
the on-disk data.  
  
Also tweak the code in inv_api.c so that fetches from pg_largeobject  
explicitly verify that the length of the data field is not more than  
LOBLKSIZE.  Formerly we just had Asserts() for that, which is no protection  
at all in production builds.  In some of the call sites an overlength data  
value would translate directly to a security-relevant stack clobber, so it  
seems worth one extra runtime comparison to be sure.  
  
In the back branches, we can't change the contents of pg_control; but we  
can still make the extra checks in inv_api.c, which will offer some amount  
of protection against running with the wrong value of LOBLKSIZE.  

commit   : f0c108560bce3a5481db57ffc3743e71b5f7b2d1    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 5 Jun 2014 16:29:20 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 5 Jun 2014 16:29:20 +0200    

Previously there's been a mix between 'slotname' and 'slot_name'. It's  
not nice to be unneccessarily inconsistent in a new feature. As a post  
beta1 initdb now is required in the wake of eeca4cd35e, fix the  
inconsistencies.  
Most the changes won't affect usage of replication slots because the  
majority of changes is around function parameter names. The prominent  
exception to that is that the recovery.conf parameter  
'primary_slotname' is now named 'primary_slot_name'.  

commit   : e0cb4aa89dd61cb1a76d348ced634681255b6a07    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 5 Jun 2014 13:54:16 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 5 Jun 2014 13:54:16 +0200    

The original location in create_function_3.sql didn't invite the close  
structinity warranted for adding new leakproof functions. Add comments  
to the test explaining that functions should only be added after  
careful consideration and understanding what a leakproof function is.  
  
Per complaint from Tom Lane after 5eebb8d954ad.  

commit   : 8776faa81cb651322b8993422bdd4633f1f6a487    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 5 Jun 2014 12:55:35 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 5 Jun 2014 12:55:35 +0300    

The way the code was written, the padding was copied from uninitialized  
memory areas.. Because the structs are local variables in the code where  
the WAL records are constructed, making them larger and zeroing the padding  
bytes would not make the code very pretty, so rather than fixing this  
directly by zeroing out the padding bytes, it seems more clear to not try to  
align the tuples in the WAL records. The redo functions are taught to copy  
the tuple header to a local variable to avoid unaligned access.  
  
Stable-branches have the same problem, but we can't change the WAL format  
there, so fix in master only. Reading a few random extra bytes at the stack  
is harmless in practice, so it's not worth crafting a different  
back-patchable fix.  
  
Per reports from Kevin Grittner and Andres Freund, using clang static  
analyzer and Valgrind, respectively.  

commit   : d4d48a5edd9eb28a7f2ee2e4cbe20d984274982e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Jun 2014 21:31:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Jun 2014 21:31:41 -0400    

Buildfarm says we get different plans on 32-bit and 64-bit platforms,  
probably because of MAXALIGN-related differences in memory-consumption  
calculations.  Add some dummy WHERE clauses so that the planner estimates  
different sizes for the three generate_series() relations; that should  
stabilize the choice of join order.  

commit   : 4c8ab1b91d2bd154031f7bc8529b9e6e2f1cc443    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Jun 2014 20:45:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Jun 2014 20:45:56 -0400    

This is needed to allow ORDER BY, DISTINCT, etc to work as expected for  
pg_lsn values.  
  
We had previously decided to put this off for 9.5, but in view of commit  
eeca4cd35e284c72b2ea1b4494e64e7738896e81 there's no reason to avoid a  
catversion bump for 9.4beta2, and this does make a pretty significant  
usability difference for pg_lsn.  
  
Michael Paquier, with fixes from Andres Freund and Tom Lane  

commit   : eeca4cd35e284c72b2ea1b4494e64e7738896e81    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Jun 2014 18:16:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 4 Jun 2014 18:16:17 -0400    

This should have been done in 6bc8ef0b7f1f1df3998745a66e1790e27424aa0c  
and/or 50e547096c4858a68abf09894667a542cc418315, but better late than  
never.  If we don't change this then we risk 9.3 pg_controldata or  
pg_resetxlog being inappropriately used against a 9.4 pg_control file,  
or vice versa.  

commit   : 621a99a666ba1a27b852dc5ddc0e1b224c388f53    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 4 Jun 2014 21:36:19 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 4 Jun 2014 21:36:19 +0200    

HeapTupleSatisfiesVacuum() didn't properly discern between  
DELETE_IN_PROGRESS and INSERT_IN_PROGRESS for rows that have been  
inserted in the current transaction and deleted in a aborted  
subtransaction of the current backend. At the very least that caused  
problems for CLUSTER and CREATE INDEX in transactions that had  
aborting subtransactions producing rows, leading to warnings like:  
WARNING:  concurrent delete in progress within table "..."  
possibly in an endless, uninterruptible, loop.  
  
Instead of treating *InProgress xmins the same as *IsCurrent ones,  
treat them as being distinct like the other visibility routines. As  
implemented this separatation can cause a behaviour change for rows  
that have been inserted and deleted in another, still running,  
transaction. HTSV will now return INSERT_IN_PROGRESS instead of  
DELETE_IN_PROGRESS for those. That's both, more in line with the other  
visibility routines and arguably more correct. The latter because a  
INSERT_IN_PROGRESS will make callers look at/wait for xmin, instead of  
xmax.  
The only current caller where that's possibly worse than the old  
behaviour is heap_prune_chain() which now won't mark the page as  
prunable if a row has concurrently been inserted and deleted. That's  
harmless enough.  
  
As a cautionary measure also insert a interrupt check before the gotos  
in IndexBuildHeapScan() that lead to the uninterruptible loop. There  
are other possible causes, like a row that several sessions try to  
update and all fail, for repeated loops and the cost of doing so in  
the retry case is low.  
  
As this bug goes back all the way to the introduction of  
subtransactions in 573a71a5da backpatch to all supported releases.  
  
Reported-By: Sandro Santilli  

commit   : c8c9c1f5a3fcd2db0f94d3126e142dee91c53632    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Jun 2014 01:43:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 5 Jun 2014 01:43:17 +0900    

Back-patch to 9.3 where pg_stat directory was introduced.  

commit   : 654e8e444749f053c3bf3fd543d10deb6aa6dd09    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 4 Jun 2014 12:09:45 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 4 Jun 2014 12:09:45 +0900    

187492b6c2e8cafc5b39063ca3b67846e8155d24 changed pgstat.c so that  
the stats files were saved into $PGDATA/pg_stat directory when the server  
was shutdowned. But it accidentally forgot to change the location of  
pg_stat_statements permanent stats file. This commit fixes pg_stat_statements  
so that its stats file is also saved into $PGDATA/pg_stat at shutdown.  
  
Since this fix changes the file layout, we don't back-patch it to 9.3  
where this oversight was introduced.  

commit   : 55fb759ab3e7543a6be72a35e6b6961455c5b393    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 3 Jun 2014 22:36:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 3 Jun 2014 22:36:35 -0400    

Bison >=3.0 issues warnings about  
  
    %name-prefix="base_yy"  
  
instead of the now preferred  
  
    %name-prefix "base_yy"  
  
but the latter doesn't work with Bison 2.3 or less.  So for now we  
silence the deprecation warnings.  

commit   : ab14a73a6ca5cc4750f0e00a48bdc25a2293034a    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 3 Jun 2014 18:26:47 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 3 Jun 2014 18:26:47 -0400    

Per gripe from Peter Eisentraut and Tom Lane.  
  
The output is slightly different, but still ISO 8601 compliant: to_char  
doesn't output the minutes when time zone offset is an integer number of  
hours, while EncodeDateTime outputs ":00".  
  
The code is slightly adapted from code in xml.c  

commit   : 0ad1a816320a2b539a51628e2a0b1e83ff096b1d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 3 Jun 2014 16:11:31 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 3 Jun 2014 16:11:31 -0400    

Previously, any backslash in text being escaped for JSON was doubled so  
that the result was still valid JSON. However, this led to some perverse  
results in the case of Unicode sequences, These are now detected and the  
initial backslash is no longer escaped. All other backslashes are  
still escaped. No validity check is performed, all that is looked for is  
\uXXXX where X is a hexidecimal digit.  
  
This is a change from the 9.2 and 9.3 behaviour as noted in the Release  
notes.  
  
Per complaint from Teodor Sigaev.  

commit   : f30015b6d794c15d52abbb3df3a65081fbefb1ed    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 3 Jun 2014 13:56:53 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 3 Jun 2014 13:56:53 -0400    

Many JSON processors require timestamp strings in ISO 8601 format in  
order to convert the strings. When converting a timestamp, with or  
without timezone, to a JSON datum we therefore now use such a format  
rather than the type's default text output, in functions such as  
to_json().  
  
This is a change in behaviour from 9.2 and 9.3, as noted in the release  
notes.  

commit   : 2dfa15de5510b3c19ffb92b512c39d5440a07b1e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Jun 2014 12:01:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Jun 2014 12:01:27 -0400    

This test previously used a data value containing U+0080, and would  
therefore fail if the database encoding didn't have an equivalent to  
that; which only about half of our supported server encodings do.  
We could fall back to using some plain-ASCII character, but that seems  
like it's losing most of the point of the test.  Instead switch to using  
U+00A0 (no-break space), which translates into all our supported encodings  
except the four in the EUC_xx family.  
  
Per buildfarm testing.  Back-patch to 9.1, which is as far back as this  
test is expected to succeed everywhere.  (9.0 has the test, but without  
back-patching some 9.1 code changes we could not expect to get consistent  
results across platforms anyway.)  

commit   : 44445b28d265fe91fea3da47bd3a8c4007ce87e5    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 3 Jun 2014 14:02:54 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 3 Jun 2014 14:02:54 +0200    

Because RecoveryConflictInterrupt() didn't set the process latch  
anything using the latter to wait for events didn't get notified about  
recovery conflicts. Most latch users are never the target of recovery  
conflicts, which explains the lack of reports about this until  
now.  
Since 9.3 two possible affected users exist though: The sql callable  
pg_sleep() now uses latches to wait and background workers are  
expected to use latches in their main loop. Both would currently wait  
until the end of WaitLatch's timeout.  
  
Fix by adding a SetLatch() to RecoveryConflictInterrupt(). It'd also  
be possible to fix the issue by having each latch user set  
set_latch_on_sigusr1. That seems failure prone and though, as most of  
these callsites won't often receive recovery conflicts and thus will  
likely only be tested against normal query cancels et al. It'd also be  
unnecessarily verbose.  
  
Backpatch to 9.1 where latches were introduced. Arguably 9.3 would be  
sufficient, because that's where pg_sleep() was converted to waiting  
on the latch and background workers got introduced; but there could be  
user level code making use of the latch pre 9.3.  

commit   : 5eebb8d954adf9d600b1a157682539db1e8a3ada    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 3 Jun 2014 12:19:18 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 3 Jun 2014 12:19:18 +0200    

Use the unaligned/no rowcount output mode in a regression tests that  
shows all built-in leakproof functions. Currently a new leakproof  
function will often change the alignment of all existing functions,  
making it hard to see the actual difference and creating unnecessary  
patch conflicts.  
  
Noticed while looking over a patch introducing new leakproof functions.  

commit   : 19c9da1d9654cbfd95bae26caff497d78277fb6e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 2 Jun 2014 16:18:45 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 2 Jun 2014 16:18:45 -0400    

from_jsonb -> from_json, for consistency  
  
Patch by rudolf (private report)  

commit   : 1a4174a498a15a848d4c4c50a3a9ef500926e4bd    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 1 Jun 2014 19:04:02 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 1 Jun 2014 19:04:02 -0400    

Instead of iterating over jsonb structures, use the inbuilt functions  
findJsonbValueFromContainerLen() and getIthJsonbValueFromContainer() to  
extract values directly. These functions use algorithms that are O(n log  
n) and O(1) respectively, whereas iterating is O(n), so we should see  
considerable speedup here.  
  
Teodor Sigaev.  

commit   : a57509821c3147b2bf57560e3bce1641d78a7519    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 31 May 2014 15:58:04 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 31 May 2014 15:58:04 +0200    

Document the CREATE_REPLICATION_SLOT's output_plugin parameter; that  
START_REPLICATION ... LOGICAL takes parameters; that START_REPLICATION  
... LOGICAL uses the same messages as ... PHYSICAL; and be more  
consistent with the usage of <literal/>.  
  
Michael Paquier, with some additional changes by me.  

commit   : 20561acf93d32b7d7fdd59d054344b2e341d6aa0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 May 2014 18:18:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 May 2014 18:18:11 -0400    

As of Xcode 5.0, Apple isn't including the Python framework as part of the  
SDK-level files, which means that linking to it might fail depending on  
whether Xcode thinks you've selected a specific SDK version.  According to  
their Tech Note 2328, they've basically deprecated the framework method of  
linking to libpython and are telling people to link to the shared library  
normally.  (I'm pretty sure this is in direct contradiction to the advice  
they were giving a few years ago, but whatever.)  Testing says that this  
approach works fine at least as far back as OS X 10.4.11, so let's just  
rip out the framework special case entirely.  We do still need a special  
case to decide that OS X provides a shared library at all, unfortunately  
(I wonder why the distutils check doesn't work ...).  But this is still  
less of a special case than before, so it's fine.  
  
Back-patch to all supported branches, since we'll doubtless be hearing  
about this more as more people update to recent Xcode.  

commit   : 512f3b03e3cddf7dc1901c0e062500133e534c1d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 30 May 2014 10:27:40 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 30 May 2014 10:27:40 +0300    

Michael Paquier  

commit   : 42be7d6923e52a8c1ceb549c0931ac43a4954b86    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 29 May 2014 23:33:49 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 29 May 2014 23:33:49 -0400    

Michael Paquier  

commit   : c941aed96b482e32dc3a8eba66b298824e7adc39    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 May 2014 13:51:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 29 May 2014 13:51:02 -0400    

The original coding in contrib/uuid-ossp created and destroyed a uuid_t  
object (or, in some cases, even two of them) each time it was called.  
This is not the intended usage: you're supposed to keep the uuid_t object  
around so that the library can cache its state across uses.  (Other UUID  
libraries seem to keep equivalent state behind-the-scenes in static  
variables, but OSSP chose differently.)  Aside from being quite inefficient,  
creating a new uuid_t loses knowledge of the previously generated UUID,  
which in theory could result in duplicate V1-style UUIDs being created  
on sufficiently fast machines.  
  
On at least some platforms, creating a new uuid_t also draws some entropy  
from /dev/urandom, leaving less for the rest of the system.  This seems  
sufficiently unpleasant to justify back-patching this change.  

commit   : 25dd07e0f6ba1aef0a6802474112b5bcce621ea4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 23:15:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 23:15:51 -0400    

The previous version of these tests expected uuid_generate_v1() to always  
emit MAC addresses with the local-admin and multicast address bits zero.  
However, several of the buildfarm critters are reporting values with the  
local-admin bit set.  (Perhaps they're running inside VMs or jails.)  
And a couple are reporting values with the multicast bit set, probably  
meaning that the UUID library couldn't read the system MAC address.  
  
Also, it emerges that if OSSP UUID can't read the system MAC address, it  
falls back to V1MC behavior wherein the whole node field gets randomized  
each time, breaking the test that expected the node field to remain stable  
in V1 output.  (It looks like e2fs doesn't behave that way, though.)  
  
It's not entirely clear why we can't get a system MAC address, since the  
buildfarm scripts would not work without internet access.  Nonetheless,  
the regression tests had better cope with the case, so adjust the tests  
to expect these behaviors.  

commit   : 71ed8b3ca76cd720f4013c3c20f0d2706583ab9a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 19:21:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 19:21:01 -0400    

This reverts commit 45b7abe59e9485657ac9380f35d2d917dd0da25b.  
  
It turns out that the %name-prefix syntax without "=" does not work  
at all in pre-2.4 Bison.  We are not prepared to make such a large  
jump in minimum required Bison version just to suppress a warning  
message in a version hardly any developers are using yet.  
When 3.0 gets more popular, we'll figure out a way to deal with this.  
In the meantime, BISONFLAGS=-Wno-deprecated is recommendable for  
anyone using 3.0 who doesn't want to see the warning.  

commit   : 21d48d66c8be053ef5ce0474bb30f8a91b7c3dd6    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 29 May 2014 00:32:09 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 29 May 2014 00:32:09 +0200    

Sometimes CREATE_REPLICATION_SLOT ... LOGICAL ... needs to wait for  
further WAL using WalSndWaitForWal(). That used to always respect  
wal_sender_timeout and kill the session when waiting long enough  
because no feedback/ping messages can be sent while the slot is still  
being created.  
Introduce the notion that last_reply_timestamp = 0 means that the  
walsender currently doesn't need timeout processing to avoid that  
problem. Use that notion for CREATE_REPLICATION_SLOT ... LOGICAL.  
  
Bugreport and initial patch by Steve Singer, revised by me.  

commit   : d1d50bff247f189a6a1477596cdbd52d097089a0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 28 May 2014 23:44:31 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 28 May 2014 23:44:31 +0300    

The only caller of compareJsonbScalarValue that needed locale-sensitive  
comparison of strings was also the only caller that didn't just check for  
equality. Separate the two cases for clarity: compareJsonbScalarValue now  
does locale-sensitive comparison, and a new function,  
equalsJsonbScalarValue, just checks for equality.  

commit   : b3e5cfd5f979054e31d60adafd9e75bf9c38549a    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 28 May 2014 22:47:04 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 28 May 2014 22:47:04 +0300    

Fix an over-zealous assertion, which didn't take into account that sometimes  
a scalar element can be compared against an array/object element.  
  
Avoid comparing possibly-uninitialized local variables when end-of-array or  
end-of-object is reached. Also fix and enhance comments a bit.  
  
Peter Geoghegan, per reports by Pavel Stehule and me.  

commit   : 45b7abe59e9485657ac9380f35d2d917dd0da25b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 15:41:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 15:41:53 -0400    

%name-prefix doesn't use an "=" sign according to the Bison docs, but it  
silently accepted one anyway, until Bison 3.0.  This was originally a  
typo of mine in commit 012abebab1bc72043f3f670bf32e91ae4ee04bd2, and we  
seem to have slavishly copied the error into all the other grammar files.  
  
Per report from Vik Fearing; analysis by Peter Eisentraut.  
  
Back-patch to all active branches, since somebody might try to build  
a back branch with up-to-date tools.  

commit   : c0f27628d2fb53e8e5d190da2132739a2bb2f500    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 14:21:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 14:21:17 -0400    

On reflection, the timestamp-advances test might fail if we're unlucky  
enough for the time_mid field to change between two calls, since uuid_cmp  
is just bytewise comparison and the field ordering has more significant  
fields later.  Build some field extraction functions so we can do a more  
honest test of that.  Also check that the version and reserved fields  
contain what they should.  

commit   : 2103218dd4a0c6a44d05c09c066da20e1c2360fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 11:50:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 11:50:41 -0400    

The V5 (SHA1 hashing) code wrote 20 bytes into a 16-byte local variable.  
This had accidentally failed to fail in my testing and Matteo's, but  
buildfarm results exposed the problem.  

commit   : 8232d6df4c943a30c08e65d7ea893cb762bc5612    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 28 May 2014 12:40:45 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 28 May 2014 12:40:45 +0200    

Move the code that sends the initial status information as well as the  
calculation of paths inside the ENSURE_ERROR_CLEANUP block. If this code  
failed, we would "leak" a counter of number of concurrent backups, thereby  
making the system always believe it was in backup mode. This could happen  
if the sending failed (which it probably never did given that the small  
amount of data to send would never cause a flush) or if the psprintf calls  
ran out of memory. Both are very low risk, but all operations after  
do_pg_start_backup should be protected.  

commit   : c676315658973390c5550d73d3bb1fb7b92720b5    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 28 May 2014 06:27:01 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 28 May 2014 06:27:01 -0400    

commit   : ec3357a3bc37d9108b2cf2db96499f83f1a93df1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 00:26:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 May 2014 00:26:46 -0400    

In general it's not a good idea for built-in types in the 'U' category  
to be marked preferred; they could draw behavior away from user-defined  
types with similarly-named operators.  pg_lsn is probably at low risk  
of that right now given the lack of casts between it and other types,  
but that doesn't make this marking OK.  
  
Ordinarily we'd bump catversion when changing any predefined catalog  
contents like this, but since we're past beta1, the costs of a forced  
initdb seem to outweigh the benefits of guaranteed behavioral consistency.  
There's not any known behavioral impact today anyway --- this is more  
in the nature of being sure there's not problems in future.  
  
Per an off-list complaint from Thomas Fanghaenel.  

commit   : 8600031147cee7845e1ad9e64304e1f5fe585515    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 May 2014 22:31:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 May 2014 22:31:21 -0400    

The recent addition of regression tests to uuid-ossp exposed the fact  
that the MSVC build system wasn't being consistent about whether it was  
building/testing that contrib module, ie, it would try to test the module  
even when it hadn't built it.  The same hazard was latent for sslinfo.  
  
For the moment I just copied the more up-to-date logic from point A to  
point B, but this is screaming for refactoring.  
  
Per buildfarm results.  

commit   : 4bcb3946249cbeed157ffd545a804913cfce749b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 May 2014 22:01:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 May 2014 22:01:13 -0400    

Commit 5035701e07e8bd395aa878465a102afd7b74e8c3 improved xlog.c's method  
for creating a database system identifier, but I neglected to fix the  
copy of that code appearing in pg_resetxlog.c.  Spotted by Andres Freund.  

commit   : 49cf2cd815d61e1399fe46f9532347f09c3ed2f9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 27 May 2014 21:30:20 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 27 May 2014 21:30:20 -0400    

Patch by Marko Kreen  

commit   : b8cc8f94730610c0189aa82dfec4ae6ce9b13e34    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 May 2014 19:42:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 May 2014 19:42:08 -0400    

Allow the contrib/uuid-ossp extension to be built atop any one of these  
three popular UUID libraries.  (The extension's name is now arguably a  
misnomer, but we'll keep it the same so as not to cause unnecessary  
compatibility issues for users.)  
  
We would not normally consider a change like this post-beta1, but the issue  
has been forced by our upgrade to autoconf 2.69, whose more rigorous header  
checks are causing OSSP's header files to be rejected on some platforms.  
It's been foreseen for some time that we'd have to move away from depending  
on OSSP UUID due to lack of upstream maintenance, so this is a down payment  
on that problem.  
  
While at it, add some simple regression tests, in hopes of catching any  
major incompatibilities between the three implementations.  
  
Matteo Beccati, with some further hacking by me  

commit   : 616afee14d7e8d6690286aaf8a2a0a01168c378a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 26 May 2014 22:56:28 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 26 May 2014 22:56:28 -0400    

Commit 090d0f2050647958865cb495dff74af7257d2bb4 added new code showing  
how it can be useful to set bgw_notify_pid to a non-zero value, but it  
failed to make sure that the existing call to RegisterBackgroundWorker  
initialized the new field at all.  
  
Report and patch by Shigeru Hanada.  

commit   : 9d7ded0f4277f5c0063eca8e871a34e2355a8371    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 May 2014 22:23:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 May 2014 22:23:29 -0400    

On Mingw, it seems that scanf() doesn't necessarily accept the same format  
codes that printf() does, and in particular it may fail to recognize %llu  
even though printf() does.  Since configure only probes printf() behavior  
while setting up the INT64_FORMAT macros, this means it's unsafe to use  
those macros with scanf().  We had only one instance of such a coding  
pattern, in contrib/pg_stat_statements, so change that code to avoid  
the problem.  
  
Per buildfarm warnings.  Back-patch to 9.0 where the troublesome code  
was introduced.  
  
Michael Paquier  

commit   : bf2e70ba6c0175e5a676b6aa37e49915d8918a63    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 25 May 2014 18:47:05 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 25 May 2014 18:47:05 +0200    

The bug was caused by omitting 'I:' from the short argument list to  
getopt_long(). To make similar bugs in the future less likely reorder  
options in --help, long and short option lists to be in the same,  
alphabetical within groups, order.  
  
Report and fix by Michael Paquier, some additional reordering by me.  

commit   : 0a5faaa90718b0ce259f43bfae8d629cc040a67c    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 25 May 2014 23:20:15 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 25 May 2014 23:20:15 -0400    

commit   : 8da31837803e95f26642019d859c3309d1c125fa    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 25 May 2014 18:15:04 -0400    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 25 May 2014 18:15:04 -0400    

The new page deletion code didn't cope with the case the target page's  
right sibling was marked half-dead. It failed a sanity check which checked  
that the downlinks in the parent page match the lower level, because a  
half-dead page has no downlink. To cope, check for that condition, and  
just give up on the deletion if it happens. The vacuum will finish the  
deletion of the half-dead page when it gets there, and on the next vacuum  
after that the empty can be deleted.  
  
Reported by Jeff Janes.  

commit   : 9a65fb350717360c505de9df411024d47e55710b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 May 2014 16:33:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 May 2014 16:33:29 -0400    

Change the total-transactions counters from int32 to int64 to accommodate  
cases where we do more than 2^31 transactions during a run.  This patch  
does not change the INT_MAX limit on explicit "-t" parameters, but it  
does allow the product of the -t and -c parameters to exceed INT_MAX, or  
allow a -T limit that is large enough that more than 2^31 transactions  
can be completed.  While pgbench did not actually fail in such cases,  
it did print an incorrect total-transactions count, and some of the  
derived numbers such as TPS would have been wrong as well.  
  
Tomas Vondra  

commit   : 9fa93530c878a0e23147a65f7d9a62802b22a995    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 25 May 2014 01:37:52 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 25 May 2014 01:37:52 +0200    

HeapTupleHeaderGetCmax() asserts that it is only used if the tuple has  
been updated by the current transaction. That check is correct and  
sensible but requires allocating memory if xmax is a multixact. When  
wal_level is set to logical cmax needs to be included in a wal record  
, generated inside a critical section, which can trigger the assertion  
added in 4a170ee9e.  
  
Reported-By: Steve Singer  

commit   : 0564bbe7a1690f025f4424d5a12cb6af9d428c48    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 7 May 2014 22:30:05 +0200    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 7 May 2014 22:30:05 +0200    

Define padding bytes in SharedInvalidationMessage structs to be  
defined. Otherwise the sinvaladt.c ringbuffer, which is accessed by  
multiple processes, will cause spurious valgrind warnings about  
undefined memory being used. That's because valgrind remembers the  
undefined bytes from the last local process's store, not realizing  
that another process has written since, filling the previously  
uninitialized bytes.  

commit   : 37828e87aec2eb0c15655d4ad753644be851e59f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 23 May 2014 15:05:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 23 May 2014 15:05:31 -0400    

Report by Tomonari Katsumata  

commit   : 57b7e83b0d5e192c01e261b76ff0ed0ccd73c37c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 23 May 2014 08:16:09 -0400    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 23 May 2014 08:16:09 -0400    

commit   : 11ad3b35c25de6edcaa8a7695cb1d58650c546d3    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 May 2014 10:40:00 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 22 May 2014 10:40:00 -0400    

This is all inside a block guarded by op == DSM_OP_ATTACH, so it can  
never be the case that op == DSM_OP_CREATE.  
  
Reported by Coverity.  

commit   : 06db9cce22efeb2a2cffa69491dd576adb77b655    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 22 May 2014 16:31:55 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 22 May 2014 16:31:55 +0900    

Erik Rijkers  

commit   : 19a683f69f4bc630ee04f2938e13e46397eb7a2d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 22 May 2014 12:43:50 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 22 May 2014 12:43:50 +0900    

commit   : 51f41e8c0a0b9ce00734ed4702d16601cc55c280    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 21 May 2014 23:18:38 -0400    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 21 May 2014 23:18:38 -0400    

commit   : 2e1b5d3f014206f6bdf3dc48d50ecec9dee10fd6    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 21 May 2014 15:49:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 21 May 2014 15:49:44 -0400    

Report by Simon Riggs  

commit   : e12d7320ca494fd05134847e300feedb2d4a5969    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 21 May 2014 08:00:39 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 21 May 2014 08:00:39 -0400    

commit   : 6a61308fba6f474c840192052bca8c86df95927c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 20 May 2014 14:10:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 20 May 2014 14:10:09 -0400    

Report by David Johnston  

commit   : e416830a296f440acd67afd8599dde5411021fc4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 May 2014 12:20:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 20 May 2014 12:20:47 -0400    

Commit af7914c6627bcf0b0ca614e9ce95d3f8056602bf, which introduced the  
EXPLAIN (TIMING) option, for some reason coded explain.c to look at  
planstate->instrument->need_timer rather than es->timing to decide  
whether to print timing info.  However, the former flag might get set  
as a result of contrib/auto_explain wanting timing information.  We  
certainly don't want activation of auto_explain to change user-visible  
statement behavior, so fix that.  
  
Also fix an independent bug introduced in the same patch: in the code  
path for a never-executed node with a machine-friendly output format,  
if timing was selected, it would fail to print the Actual Rows and Actual  
Loops items.  
  
Per bug #10404 from Tomonari Katsumata.  Back-patch to 9.2 where the  
faulty code was introduced.  

commit   : a0841ecd2518d4505b96132b764b918ab5d21ad4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 May 2014 16:38:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 May 2014 16:38:49 -0400    

Peter Geoghegan  

commit   : f097d70b7227c1f9aa2ed0af1d6deb05367ef657    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 19 May 2014 20:41:41 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 19 May 2014 20:41:41 +0900    

commit   : 4e92f780123ca862970816d3fa70d3baf2fcbea4    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 May 2014 14:15:21 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 May 2014 14:15:21 +0300    

Lowercase help statements. Use an existing message to reduce the number  
of strings to be translated.  
  
Euler Taveira  

commit   : c91a9b5a285e20e54cf90f3660ce51ce3a5c2ef4    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 May 2014 13:16:24 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 19 May 2014 13:16:24 +0300    

I got the backup block numbers off-by-one in the commit that changed the  
way incomplete-splits are handled. I blame the comments, which said  
"backup block 1" and "backup block 2", even though the backup blocks  
are numbered starting from 0, in the macros and functions used in replay.  
Fix the comments and the code.  
  
Per Jeff Janes' bug report about corruption caused by torn page writes.  
The incorrect code is new in git master, but backpatch the comment change  
down to 9.0, where the numbering in the redo-side macros  was changed.  

commit   : eb56812144bb310f7cb2f63e53d6d58f30df95b5    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 19 May 2014 17:03:30 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 19 May 2014 17:03:30 +0900    

Fabrízio de Royes Mello  

commit   : 009ca5e7821d742ed118a87c756c857895f3ffdd    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 19 May 2014 00:47:45 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 19 May 2014 00:47:45 -0400    

Report by Andrew Dunstan  

commit   : b05d1e3c0b2477797cd04b1e8dd1d3b91306e671    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 19 May 2014 00:35:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 19 May 2014 00:35:02 -0400    

Text from David G Johnston  

commit   : e41cc470bb57a0f3a765fa44b77ef104b5a5a01e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 May 2014 00:06:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 May 2014 00:06:26 -0400    

C89 says that compound initializers may only contain constant expressions;  
a restriction violated by commit 89d00cbe.  While we've had no actual field  
complaints about this, C89 is still the project standard, and it's not  
saving all that much code to break compatibility here.  So let's adhere to  
the old restriction.  
  
In passing, replace a bunch of hardwired constants "256" with  
sizeof(target-variable), just because the latter is more readable and  
less breakable.  And const-ify where possible.  
  
Back-patch to 9.3 where the nonportable code was added.  
  
Andres Freund and Tom Lane  

commit   : 4d30d4b9d725211859c63a18e458015636d24b94    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 18 May 2014 23:59:23 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 18 May 2014 23:59:23 -0400    

Patch by Andres Freund  

commit   : 0c19aaba22c4d904f7259ef11f7d6db7b5dd36a0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 May 2014 18:17:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 May 2014 18:17:55 -0400    

That's what I get for not fully retesting the final version of the patch.  
The replace_allowed cross-check needs an additional special case for  
bootstrapping.  

commit   : 078b2ed291c758e7125d72c3a235f128d40a232b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 May 2014 16:51:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 May 2014 16:51:46 -0400    

RelationCacheInsert() ignored the possibility that hash_search(HASH_ENTER)  
might find a hashtable entry already present for the same OID.  However,  
that can in fact occur during recursive relcache load scenarios.  When it  
did happen, we overwrote the pointer to the pre-existing Relation, causing  
a session-lifespan leakage of that entire structure.  As far as is known,  
the pre-existing Relation would always have reference count zero by the  
time we arrive back at the outer insertion, so add code that deletes the  
pre-existing Relation if so.  If by some chance its refcount is positive,  
elog a WARNING and allow the pre-existing Relation to be leaked as before.  
  
Also, AttrDefaultFetch() was sloppy about leaking the cstring form of the  
pg_attrdef.adbin value it's copying into the relcache structure.  This is  
only a query-lifespan leakage, and normally not very significant, but it  
adds up during CLOBBER_CACHE testing.  
  
These bugs are of very ancient vintage, but I'll refrain from back-patching  
since there's no evidence that these leaks amount to anything in ordinary  
usage.  

commit   : 44cd47c1d49655c5dd9648bde8e267617c3735b4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 May 2014 18:29:46 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 May 2014 18:29:46 -0400    

The fallback implementation involves acquiring and releasing a spinlock  
variable that is otherwise unreferenced --- not even to the extent of  
initializing it.  This accidentally fails to fail on platforms where  
spinlocks should be initialized to zeroes, but elsewhere it results in  
a "stuck spinlock" failure during startup.  
  
I griped about this last July, and put in a hack that worked for gcc  
on HPPA, but didn't get around to fixing the general case.  Per the  
discussion back then, the best thing to do seems to be to initialize  
dummy_spinlock in main.c.  

commit   : c1907f0cc49e38df9853b7547c9afce5204e4784    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 May 2014 17:57:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 May 2014 17:57:53 -0400    

Per testing with a compiler that whines about this.  

commit   : 6c42b2b10af3f717030966b9f05867f3e065becc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 May 2014 15:53:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 May 2014 15:53:21 -0400    

The xl_heap_header_len structures in an XLOG_HEAP_UPDATE record aren't  
necessarily aligned adequately.  The regular replay function for these  
records is aware of that, but decode.c didn't get the memo.  I'm not  
sure why the buildfarm failed to catch this; the test_decoding test  
certainly blows up real good on my old HPPA box.  
  
Also, I'm pretty sure that the address arithmetic was wrong for the  
case of XLOG_HEAP_CONTAINS_OLD and not XLOG_HEAP_CONTAINS_NEW_TUPLE,  
though this apparently can't happen when logical decoding is active.  

commit   : a3655dd4a5cee3917a7d1766e07e36013e7e8835    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 17 May 2014 13:48:52 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 17 May 2014 13:48:52 +0300    

transam/README explained how B-tree incomplete splits were tracked and  
fixed after recovery, as an example of handling complex actions that need  
multiple WAL records, but that's not how it works anymore. Explain the new  
paradigm.  

commit   : 7894ac5004d5ec158f46296540d3cf49386d30e4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 May 2014 16:51:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 May 2014 16:51:28 -0400    

Several years ago we changed chr(int) so that if the database encoding is  
UTF8, it would interpret its argument as a Unicode code point and expand it  
into the appropriate multibyte sequence.  However, we weren't sufficiently  
careful about checking validity of the input.  According to RFC3629, UTF8  
disallows code points above U+10FFFF (note that the predecessor standard  
RFC2279 was more liberal).  Also, both versions of the UTF8 spec agree  
that Unicode surrogate-pair codes should never appear in UTF8.  Because  
our encoding validity checks follow RFC3629, our failure to enforce these  
restrictions in chr() means it could be used to produce text strings that  
will be rejected when the database is dumped and reloaded.  To ensure  
consistency with the input functions, let's actually apply  
pg_utf8_islegal() to the proposed output of chr().  
  
Per discussion, this seems like too much of a behavioral change to  
back-patch, but it's not too late to squeeze it into 9.4.  

commit   : af215d8190e6ab170c02c24afd1be81f5a147481    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 May 2014 15:29:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 May 2014 15:29:02 -0400    

A couple of functions didn't bother to zero out pad bytes in datums that  
would ultimately go to disk.  Harmless, but valgrind doesn't know that.  

commit   : 39586bc1e971c136c4487b26eb7334dbbe23b102    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 May 2014 15:18:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 May 2014 15:18:09 -0400    

gbt_macad_union also allocated 12-byte structs where we really need 16.  
  
Per report from Andres Freund.  No back-patch since there's no current  
risk of a real problem.  

commit   : 82bbb60c30dbff0633da34387ccab58d843379b5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 May 2014 15:11:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 16 May 2014 15:11:51 -0400    

The macaddr opclass stores two macaddr structs (each of size 6) in an  
index column that's declared as being of type gbtreekey16, ie 16 bytes.  
In the original coding this led to passing a palloc'd value of size 12  
to the index insertion code, so that data would be fetched past the  
end of the allocated value during index tuple construction.  This makes  
valgrind unhappy.  In principle it could result in a SIGSEGV, though  
with the current implementation of palloc there's no risk since  
the 12-byte request size would be rounded up to 16 bytes anyway.  
  
To fix, add a field to struct gbtree_ninfo showing the declared size of  
the index datums, and use that in the palloc requests; and use palloc0  
to be sure that any wasted bytes are cleanly initialized.  
  
Per report from Andres Freund.  No back-patch since there's no current  
risk of a real problem.  

commit   : d900e192a3ef2dd73fae4522c35aadce6d72a534    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 May 2014 11:33:49 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 May 2014 11:33:49 +0300    

Andres Freund  

commit   : afd0fcbc5d421454e7d55d949cca0721c9c135c3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 May 2014 11:23:17 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 May 2014 11:23:17 +0300    

pg_stat_replication shows connected replication clients. The ddl test case  
never has any replication clients connected, so querying pg_stat_replication  
is pointless. To check that a slot has been dropped correctly, query  
pg_replication_slots instead.  
  
Andres Freund  

commit   : 03e2b1017c0d360cae0b4d0a8bf5d6924536c834    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 May 2014 10:53:10 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 May 2014 10:53:10 +0300    

The decoding of prepared transaction commits accidentally used the XID of  
the transaction performing the COMMIT PREPARED, not the XID of the prepared  
transaction. Before bb38fb0d43c8d that lead to those transactions not being  
decoded, afterwards to a assertion failure.  

commit   : e7873b74d9c1bb7a325960f52043db6de88e6e66    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 May 2014 10:10:45 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 May 2014 10:10:45 +0300    

Let's complain about e.g an invalid path or permission problem sooner rather  
than later. Before this patch, we would only try to open the output file  
after receiving the first decoded message from the server.  

commit   : 07a4a93a0e35a778c77ffbbbc18de29e859e18f0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 May 2014 09:47:50 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 16 May 2014 09:47:50 +0300    

Commit dd428c79 added dbId and tsId to the xl_xact_commit struct but missed  
that prepared transaction commits reuse that struct. Fix that.  
  
Because those fields were left unitialized, replaying a commit prepared WAL  
record in a hot standby node would fail to remove the relcache init file.  
That can lead to "could not open file" errors on the standby. Relcache init  
file only needs to be removed when a system table/index is rewritten in the  
transaction using two phase commit, so that should be rare in practice. In  
HEAD, the incorrect dbId/tsId values are also used for filtering in logical  
replication code, causing the transaction to always be filtered out.  
  
Analysis and fix by Andres Freund. Backpatch to 9.0 where hot standby was  
introduced.  

commit   : f62d417825d6a8e26768a130a5f4c9e454d9dbe4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 May 2014 15:57:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 May 2014 15:57:54 -0400    

In yesterday's commit 2dc4f011fd61501cce507be78c39a2677690d44b, I tried  
to force buffering of stdout/stderr in initdb to be what it is by  
default when the program is run interactively on Unix (since that's how  
most manual testing is done).  This tripped over the fact that Windows  
doesn't support _IOLBF mode.  We dealt with that a long time ago in  
syslogger.c by falling back to unbuffered mode on Windows.  Export that  
solution in port.h and use it in initdb.  
  
Back-patch to 8.4, like the previous commit.  

commit   : 2f8e68bd7ea3523977567369056c4b3e67e44fdc    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 15 May 2014 13:23:31 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Thu, 15 May 2014 13:23:31 -0400    

commit   : 00c26b6a60e7ceed29ddae34b0a69fe945c08f81    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 May 2014 19:43:37 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 May 2014 19:43:37 +0300    

Don't close stdout on SIGHUP. Also, when a SIGHUP is received, close the  
file immediately, rather than only after receiving some more data from  
the server. Rename a variable, to avoid mentally dealing with double  
negatives (not unsynced means synced).  

commit   : 8f9b9590d79fc1fc1ad08b207401acfdbb0bfac7    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 May 2014 18:29:20 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 May 2014 18:29:20 +0300    

The proc array can contain duplicate XIDs, when a transaction is just being  
prepared for two-phase commit. To cope, remove any duplicates in  
txid_current_snapshot(). Also ignore duplicates in the input functions, so  
that if e.g. you have an old pg_dump file that already contains duplicates,  
it will be accepted.  
  
Report and fix by Jan Wieck. Backpatch to all supported versions.  

commit   : bb38fb0d43c8d7ff54072bfd8bd63154e536b384    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 May 2014 16:37:50 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 May 2014 16:37:50 +0300    

To lock a prepared transaction's shared memory entry, we used to mark it  
with the XID of the backend. When the XID was no longer active according  
to the proc array, the entry was implicitly considered as not locked  
anymore. However, when preparing a transaction, the backend's proc array  
entry was cleared before transfering the locks (and some other state) to  
the prepared transaction's dummy PGPROC entry, so there was a window where  
another backend could finish the transaction before it was in fact fully  
prepared.  
  
To fix, rewrite the locking mechanism of global transaction entries. Instead  
of an XID, just have simple locked-or-not flag in each entry (we store the  
locking backend's backend id rather than a simple boolean, but that's just  
for debugging purposes). The backend is responsible for explicitly unlocking  
the entry, and to make sure that that happens, install a callback to unlock  
it on abort or process exit.  
  
Backpatch to all supported versions.  

commit   : ff810b4928882bfdc4ebe1ce603c47830aba3132    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 May 2014 14:49:11 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 May 2014 14:49:11 +0300    

Euler Taveira  

commit   : a82a17475d8a8a91df5fd1448b0f93772f590ecd    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 May 2014 12:18:49 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 15 May 2014 12:18:49 +0300    

Mingw-w64 headers map popen/pclose to _popen and _pclose, but we want to use  
our popen wrapper rather than the Mingw-w64. #undef the Mingw's version.  

commit   : 4773c70aa4c938c367ee179f7301f70a4efabc0e    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 14 May 2014 22:26:49 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 14 May 2014 22:26:49 -0400    

commit   : c424c049189f758920b1a3bb961bc05c93a900df    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 14 May 2014 22:19:18 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 14 May 2014 22:19:18 -0400    

commit   : 2dc4f011fd61501cce507be78c39a2677690d44b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 May 2014 21:13:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 May 2014 21:13:54 -0400    

Since this program may print to either stdout or stderr, the relative  
ordering of its messages depends on the buffering behavior of those files.  
Force stdout to be line-buffered and stderr to be unbuffered, ensuring  
that the behavior will match standard Unix interactive behavior, even  
when stdout and stderr are rerouted to a file.  
  
Per complaint from Tomas Vondra.  The particular case he pointed out is  
new in HEAD, but issues of the same sort could arise in any branch with  
other error messages, so back-patch to all branches.  
  
I'm unsure whether we might not want to do this in other client programs  
as well.  For the moment, just fix initdb.  

commit   : 2e6602dfc25d1f8e8a2e1df48c96440b02aa19c1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 14 May 2014 21:13:59 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 14 May 2014 21:13:59 -0400    

commit   : 4456763c78d2a94c42e67ce788fbe94a07aa12dc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 May 2014 20:23:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 May 2014 20:23:32 -0400    

Per buildfarm.  

commit   : bb797b640449d67f722d27660c718b68a692f8f9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 14 May 2014 16:26:06 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 14 May 2014 16:26:06 -0400    

The data type internal format changed in 9.4.  Also mention this in the  
9.4 release notes.  

commit   : b23b0f5588d2e2f15edff66e072e339a8c9616a7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 May 2014 14:55:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 May 2014 14:55:48 -0400    

rd_replidindex should be managed the same as rd_oidindex, and rd_keyattr  
and rd_idattr should be managed like rd_indexattr.  Omissions in this area  
meant that the bitmapsets computed for rd_keyattr and rd_idattr would be  
leaked during any relcache flush, resulting in a slow but permanent leak in  
CacheMemoryContext.  There was also a tiny probability of relcache entry  
corruption if we ran out of memory at just the wrong point in  
RelationGetIndexAttrBitmap.  Otherwise, the fields were not zeroed where  
expected, which would not bother the code any AFAICS but could greatly  
confuse anyone examining the relcache entry while debugging.  
  
Also, create an API function RelationGetReplicaIndex rather than letting  
non-relcache code be intimate with the mechanisms underlying caching of  
that value (we won't even mention the memory leak there).  
  
Also, fix a relcache flush hazard identified by Andres Freund:  
RelationGetIndexAttrBitmap must not assume that rd_replidindex stays valid  
across index_open.  
  
The aspects of this involving rd_keyattr date back to 9.3, so back-patch  
those changes.  

commit   : ac53295d667e7727d7b70ddf11d82c067870501f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 14 May 2014 14:13:19 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 14 May 2014 14:13:19 -0400    

Report by Dean Rasheed  

commit   : eefd90c4a95449f02b568d5370cfe6bcd1bf13e9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 14 May 2014 12:21:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 14 May 2014 12:21:03 -0400    

Patch by Sergey Muraviov  

commit   : 31a263237fa3eb6f36d58335fbdb82bab3136db3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 May 2014 11:51:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 May 2014 11:51:10 -0400    

Historically we've printed a complaint for a bad locale setting, but then  
fallen back to the environment default.  Per discussion, this is not such  
a great idea, because rectifying an erroneous locale choice post-initdb  
(perhaps long after data has been loaded) could be enormously expensive.  
Better to complain and give the user a chance to double-check things.  
  
The behavior was particularly bad if the bad setting came from environment  
variables rather than a bogus command-line switch: in that case not only  
was there a fallback to C/SQL_ASCII, but the printed complaint was quite  
unhelpful.  It's hard to be entirely sure what variables setlocale looked  
at, but we can at least give a hint where the problem might be.  
  
Per a complaint from Tomas Vondra.  

commit   : eb6144bb447ecbb036bfa08da85940cd50d49410    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 14 May 2014 11:02:03 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 14 May 2014 11:02:03 -0400    

Report by Heikki Linnakangas  

commit   : e513087f6401a64b0d9f0b20cd2a51a7938ac645    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 14 May 2014 10:07:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 14 May 2014 10:07:24 -0400    

Report by Dean Rasheed  

commit   : 062f53518927f9bfe1820578ce79d3180b1aa2ca    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 13 May 2014 15:12:54 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 13 May 2014 15:12:54 -0400    

Patch by Andres Freund, slight adjustments by me  

commit   : f35aef415aa755c4e99f8c0ef83f9d14dbc48bb4    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 13 May 2014 19:17:28 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 13 May 2014 19:17:28 +0300    

When cache invalidations arrive while ri_LoadConstraintInfo() is busy  
filling a new cache entry, InvalidateConstraintCacheCallBack() compares  
the - not yet initialized - oidHashValue field with the to-be-invalidated  
hash value. To fix, check whether the entry is already marked as invalid.  
  
Andres Freund  

commit   : 540ac7cea919623f691b20892ccc50e5e33b5009    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 13 May 2014 14:16:28 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 13 May 2014 14:16:28 +0300    

The code expands a varbit gist leaf key to a node key by copying the bit  
data twice in a varlen datum, as both the lower and upper key. The lower key  
was expanded to INTALIGN size, but the padding bytes were not initialized.  
That's a problem because when the lower/upper keys are compared, the padding  
bytes are used compared too, when the values are otherwise equal. That could  
lead to incorrect query results.  
  
REINDEX is advised for any btree_gist indexes on bit or bit varying data  
type, to fix any garbage padding bytes on disk.  
  
Per Valgrind, reported by Andres Freund. Backpatch to all supported  
versions.  

commit   : 5a90ac29c44f0dabf1e3a7b0443ba772cf206e2e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 12 May 2014 23:03:49 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 12 May 2014 23:03:49 -0400    

Andres Freund  

commit   : 9af8bd51a10edaf454c6b5246d79eded73528fd2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 12 May 2014 21:37:49 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 12 May 2014 21:37:49 -0400    

Where appropriate  

commit   : 6de9a6c015d543c41933171cd6cf5d357597f19f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 12 May 2014 21:30:58 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 12 May 2014 21:30:58 -0400    

Report by Nicolas Barbier, Tatsuo Ishii, MauMau  

commit   : 66b737cd9a72e10df4de1867ae7b675bc48d478c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 May 2014 20:21:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 May 2014 20:21:16 -0400    

America/Metlakatla hasn't been in the IANA database all that long, so  
some installations might not have it.  It does seem worthwhile to test  
with a fractional-minute GMT offset, but we can get that from almost  
any pre-1900 date; I chose Europe/Paris, whose LMT offset from Greenwich  
should be pretty darn well established.  
  
Also, assuming that Mars/Mons_Olympus will never be in the IANA database  
seems less than future-proof, so let's use a more fanciful location for  
the bad-zone-name check.  
  
Per complaint from Christoph Berg.  

commit   : 73011f35eca7f4a3973289d5813648abbc1074a0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 May 2014 14:24:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 May 2014 14:24:18 -0400    

config.pl and buildenv.pl can be used to customize build settings when  
using MSVC.  They should never get committed into the common source tree.  
  
Back-patch to 9.0; it looks like the rules were different in 8.4.  
  
Michael Paquier  

commit   : a3632771bb66eec74c7e73c0d7a5f8cdd6719be2    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 13 May 2014 01:41:54 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 13 May 2014 01:41:54 +0900    

Amit Langote  

commit   : c890b488063e23f12b5ab01c9a6d254a034fcea2    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 12 May 2014 10:17:40 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 12 May 2014 10:17:40 +0300    

The leak is fairly small and rare, but a leak nevertheless.  
  
Per Coverity report. Backpatch to 9.2, where pg_receivexlog was added.  
pg_basebackup shares the code, but it always exits on error, so there is  
no real leak.  

commit   : e6df2e1be6330660ba4d81daa726ae4a71535aa9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 May 2014 17:16:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 May 2014 17:16:48 -0400    

commit   : 195e81aff5d63da1e1f9dd0314a13859ec15c7c0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 May 2014 15:13:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 May 2014 15:13:30 -0400    

The original coding for ALTER SYSTEM made a fundamentally bogus assumption  
that postgresql.auto.conf could be sought relative to the main config file  
if we hadn't yet determined the value of data_directory.  This fails for  
common arrangements with the config file elsewhere, as reported by  
Christoph Berg.  
  
The simplest fix is to not try to read postgresql.auto.conf until after  
SelectConfigFiles has chosen (and locked down) the data_directory setting.  
  
Because of the logic in ProcessConfigFile for handling resetting of GUCs  
that've been removed from the config file, we cannot easily read the main  
and auto config files separately; so this patch adopts a brute force  
approach of reading the main config file twice during postmaster startup.  
That's a tad ugly, but the actual time cost is likely to be negligible,  
and there's no time for a more invasive redesign before beta.  
  
With this patch, any attempt to set data_directory via ALTER SYSTEM  
will be silently ignored.  It would probably be better to throw an  
error, but that can be dealt with later.  This bug, however, would  
prevent any testing of ALTER SYSTEM by a significant fraction of the  
userbase, so it seems important to get it fixed before beta.  

commit   : 12e611d43e6efbf0e36014a3055ed47366facee7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 May 2014 12:06:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 May 2014 12:06:04 -0400    

There's no longer much pressure to switch the default GIN opclass for  
jsonb, but there was still some unhappiness with the name "jsonb_hash_ops",  
since hashing is no longer a distinguishing property of that opclass,  
and anyway it seems like a relatively minor detail.  At the suggestion of  
Heikki Linnakangas, we'll use "jsonb_path_ops" instead; that captures the  
important characteristic that each index entry depends on the entire path  
from the document root to the indexed value.  
  
Also add a user-facing explanation of the implementation properties of  
these two opclasses.  

commit   : e136271a947d142eaa7093a789e6fa9ceda18c17    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 10 May 2014 21:53:11 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sat, 10 May 2014 21:53:11 -0400    

commit   : ea78ce1d457d8e0fef01328219a1dfd89aeba7ae    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 10 May 2014 22:03:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 10 May 2014 22:03:24 -0400    

commit   : 0d0b2bf175a53dfedcc0cb69eaba7576b0c286f2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 May 2014 19:46:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 May 2014 19:46:19 -0400    

Per discussion, this seems like a more consistent choice of name.  
  
Fabrízio de Royes Mello, after a suggestion by Peter Eisentraut;  
some additional documentation wordsmithing by me  

commit   : f825c7c850dbe683d62defd7e5bd31664ee3302c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 May 2014 18:56:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 May 2014 18:56:52 -0400    

Document existence operator adequately; fix obsolete claim that no  
Unicode-escape semantic checks happen on input (it's still true for  
json, but not for jsonb); improve examples; assorted wordsmithing.  

commit   : 866e6e1d04d4ae9615bd1899a757dae0191e9c77    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 10 May 2014 23:24:23 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sat, 10 May 2014 23:24:23 +0300    

When returning rows from a bitmap, as done with partial match queries, we  
would get stuck in an infinite loop if the bitmap contained a lossy page  
reference.  
  
This bug is new in master, it was introduced by the patch to allow skipping  
items refuted by other entries in GIN scans.  
  
Report and fix by Alexander Korotkov  

commit   : eaba54c20c5ab2cb6aaffa574444fd4990dfe2c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 May 2014 10:48:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 May 2014 10:48:01 -0400    

Usually the search would find plain "tclsh" without any trouble,  
but some installations might only have the version-numbered flavor  
of that program.  
  
No compatibility problems have been reported with 8.6, so we might  
as well back-patch this to all active branches.  
  
Christoph Berg  

commit   : 7fa5bc43aaaf01e23c3a6ab59a57c19273f6f7f4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 May 2014 10:33:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 May 2014 10:33:34 -0400    

commit   : 17e4082b6312383075e397b4b2ae324c90716c5b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2014 20:25:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2014 20:25:42 -0400    

It takes two arguments, not one.  

commit   : 3d8c2b496fc1fed2b8ff8a403d3a17329325466e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2014 18:24:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2014 18:24:17 -0400    

reserveFromBuffer() failed to consider the possibility that it needs to  
more-than-double the current buffer size.  Beyond that, it seems likely  
that we'd someday need to worry about integer overflow of the buffer  
length variable.  Rather than reinvent the logic that's already been  
debugged in stringinfo.c, let's go back to using that logic.  We can  
still have the same targeted API, but we'll rely on stringinfo.c to  
manage reallocation.  
  
Per report from Alexander Korotkov.  

commit   : 0b92a77c17ebe8bec08e250e1a929b07efef1008    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2014 16:33:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2014 16:33:25 -0400    

I started out with the intention of just fixing the info about the jsonb  
operator classes, but soon found myself copy-editing most of the JSON  
material.  Hopefully it's more readable now.  

commit   : 0ca6bda8e7501947c05f30c127f6d12ff90b5a64    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2014 12:55:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2014 12:55:00 -0400    

These functions were relying on typcategory to identify arrays and  
composites, which is not reliable and not the normal way to do it.  
Using typcategory to identify boolean, numeric types, and json itself is  
also pretty questionable, though the code in those cases didn't seem to be  
at risk of anything worse than wrong output.  Instead, use the standard  
lsyscache functions to identify arrays and composites, and rely on a direct  
check of the type OID for the other cases.  
  
In HEAD, also be sure to look through domains so that a domain is treated  
the same as its base type for conversions to JSON.  However, this is a  
small behavioral change; given the lack of field complaints, we won't  
back-patch it.  
  
In passing, refactor so that there's only one copy of the code that decides  
which conversion strategy to apply, not multiple copies that could (and  
have) gotten out of sync.  

commit   : f1d8dd3647fd0c87f0fb238f7cfc45c1ce282a55    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 9 May 2014 10:44:04 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 9 May 2014 10:44:04 -0400    

Post-commit review identified a number of places where addition was  
used instead of multiplication or memory wasn't zeroed where it should  
have been.  This commit also fixes one case where a structure member  
was mis-initialized, and moves another memory allocation closer to  
the place where the allocated storage is used for clarity.  
  
Andres Freund  

commit   : b2dada8f5f90ab015ca8a62b46261ef01a7c781f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 9 May 2014 10:33:40 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 9 May 2014 10:33:40 -0400    

It's legal to configure wal_level=logical and max_replication_slots=0  
simultaneously.  
  
Andres Freund  

commit   : 62e57ff040e5d0acd303b94e86fff689effc5957    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2014 09:44:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2014 09:44:11 -0400    

This code really needs to be refactored so that there aren't so many copies  
that can diverge.  Not to mention that this whole approach is probably  
wrong.  But for the moment I'll just stick my finger in the dike.  
Per report from Michael Paquier.  

commit   : bdf9dd4db78a5f23e863f2d4d8500969dc261fd0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2014 09:25:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2014 09:25:58 -0400    

Dunno who had the cute idea of labeling jsonb as typcategory 'C',  
but it is not a composite type.  Label it 'U', since that's what  
json is using.  

commit   : d9daff0e0cb15221789e6c50d9733c8754c054fb    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 9 May 2014 15:55:56 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 9 May 2014 15:55:56 +0300    

Fix JSONB_MAX_ELEMS and JSONB_MAX_PAIRS macros to use CB_MASK in the  
calculation. JENTRY_POSMASK happens to have the same value at the moment,  
but that's just coincidental.  
  
Refactor jsonb iterator functions, for readability.  
  
Get rid of the JENTRY_ISFIRST flag. Whenever we handle JEntrys, we have  
access to the whole array and have enough context information to know  
which entry is the first. This frees up one bit in the JEntry header for  
future use. While we're at it, shuffle the JEntry bits so that boolean  
true and false go together, for aesthetic reasons.  
  
Bump catalog version as this changes the on-disk format slightly.  

commit   : 46dddf7673c5820be7c78a8b0e098fdbc65d003d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2014 08:41:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 May 2014 08:41:26 -0400    

Change the key representation so that values that would exceed 127 bytes  
are hashed into short strings, and so that the original JSON datatype of  
each value is recorded in the index.  The hashing rule eliminates the major  
objection to having this opclass be the default for jsonb, namely that it  
could fail for plausible input data (due to GIN's restrictions on maximum  
key length).  Preserving datatype information doesn't really buy us much  
right now, but it requires no extra space compared to the previous way,  
and it might be useful later.  
  
Also, change the consistency-checking functions to request recheck for  
exists (jsonb ? text) and related operators.  The original analysis that  
this is an exactly checkable query was incorrect, since the index does  
not preserve information about whether a key appears at top level in  
the indexed JSON object.  Add a test case demonstrating the problem.  
  
Make some other, mostly cosmetic improvements to the code in jsonb_gin.c  
as well.  
  
catversion bump due to on-disk data format change in jsonb_ops indexes.  

commit   : ff7bbb0176a667aeb0577e4d48d651ffdb6afd50    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 9 May 2014 13:09:59 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 9 May 2014 13:09:59 +0300    

Move the functions around to group related functions together. Remove  
binequal argument from lengthCompareJsonbStringValue, moving that  
responsibility to lengthCompareJsonbPair. Fix typo in comment.  

commit   : d3c72e23df6ef1fde8122db589d12d49c8495535    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 9 May 2014 11:32:28 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 9 May 2014 11:32:28 +0300    

This speeds up text to jsonb parsing and hstore to jsonb conversions  
somewhat.  

commit   : 14d309cc55d88b73d4c9d1fa51b535ae491405fd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 May 2014 22:34:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 May 2014 22:34:51 -0400    

Ensure that ecpg preprocessor output files are rebuilt when re-testing  
after a change in the ecpg preprocessor itself, or a change in any of  
several include files that get copied verbatim into the output files.  
The lack of these dependencies was what created problems for Kevin Grittner  
after the recent pgindent run.  There's no way for --enable-depend to  
discover these dependencies automatically, so we've gotta put them into  
the Makefiles by hand.  
  
While at it, reduce the amount of duplication in the ecpg invocations.  

commit   : fb1974cc6b58cd21a269dd7ab8aea0120906ec3b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 May 2014 21:45:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 May 2014 21:45:02 -0400    

Back in 8.3, we installed permissions checks in these functions (see  
commits 8bc225e7990a and cc26599b7206).  But we forgot to document that  
anywhere in the user-facing docs; it did get mentioned in the 8.3 release  
notes, but nobody's looking at that any more.  Per gripe from Suya Huang.  

commit   : b910d7ea358b0134d170ebf4002248df25a5f244    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 May 2014 21:11:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 May 2014 21:11:47 -0400    

Per discussion, the old value of 128MB is ridiculously small on modern  
machines; in fact, it's not even any larger than the default value of  
shared_buffers, which it certainly should be.  Increase to 4GB, which  
is unlikely to be any worse than the old default for anyone, and should  
be noticeably better for most.  Eventually we might have an autotuning  
scheme for this setting, but the recent attempt crashed and burned,  
so for now just do this.  

commit   : a16d421ca4fc639929bc964b2585e8382cf16e33    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 May 2014 20:49:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 May 2014 20:49:38 -0400    

This reverts commit ee1e5662d8d8330726eaef7d3110cb7add24d058, as well as  
a remarkably large number of followup commits, which were mostly concerned  
with the fact that the implementation didn't work terribly well.  It still  
doesn't: we probably need some rather basic work in the GUC infrastructure  
if we want to fully support GUCs whose default varies depending on the  
value of another GUC.  Meanwhile, it also emerged that there wasn't really  
consensus in favor of the definition the patch tried to implement (ie,  
effective_cache_size should default to 4 times shared_buffers).  So whack  
it all back to where it was.  In a followup commit, I'll do what was  
recently agreed to, which is to simply change the default to a higher  
value.  

commit   : 08c8e8962f56c23c6799178d52d3b31350a0708f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 8 May 2014 19:29:02 -0400    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 8 May 2014 19:29:02 -0400    

Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b broke it.  The change in  
sub-second precision at extreme dates is normal.  The inconsistent  
truncation vs. rounding is essentially a bug, albeit a longstanding one.  
Back-patch to 8.4, like the causative commit.  

commit   : 1e81f8462aceb07d520daaabdc999b879381bd12    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 May 2014 12:42:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 May 2014 12:42:56 -0400    

Previous commit was confused about the case we're handling: actually,  
what the patch is dealing with is platforms that have optreset, *and*  
have <getopt.h>, but the latter fails to declare the former.  Because  
we use a linking probe to set HAVE_INT_OPTRESET, we need to be sure we  
have a declaration even if <getopt.h> doesn't think it exists.  

commit   : 0c15a524c532c1006a7bd36d3a680f8e8b8db9fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 May 2014 12:33:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 8 May 2014 12:33:29 -0400    

Reportedly, some versions of mingw are like that, and it seems plausible  
in general that older platforms might be that way.  However, we'd  
determined experimentally that just doing "extern int" conflicts with  
the way Cygwin declares these variables, so explicitly exclude Cygwin.  
  
Michael Paquier, tweaked by me to hopefully not break Cygwin  

commit   : 4f7bb4b2a36facc94a1d6b821ec6733093aa9bc6    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 8 May 2014 14:43:04 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 8 May 2014 14:43:04 +0300    

To-be-deleted list pages contain no useful information, as they are being  
deleted, but we must still protect the writes from being torn by a crash  
after a partial write. To do that, re-initialize the pages on WAL replay.  
  
Jeff Janes caught this with a test program to test partial writes.  
Backpatch to all supported versions.  

commit   : 02c9a938057ecb811c65999577d32c5f5e9c99dc    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 8 May 2014 10:56:57 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 8 May 2014 10:56:57 +0300    

Michael Paquier  

commit   : 2f557167b19af79ffecb8faedf8b7bce4d48f3e1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 May 2014 21:38:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 May 2014 21:38:36 -0400    

If the server sends a long stream of data, and the server + network are  
consistently fast enough to force the recv() loop in pqReadData() to  
iterate until libpq's input buffer is full, then upon processing the last  
incomplete message in each bufferload we'd usually double the buffer size,  
due to supposing that we didn't have enough room in the buffer to finish  
collecting that message.  After filling the newly-enlarged buffer, the  
cycle repeats, eventually resulting in an out-of-memory situation (which  
would be reported misleadingly as "lost synchronization with server").  
Of course, we should not enlarge the buffer unless we still need room  
after discarding already-processed messages.  
  
This bug dates back quite a long time: pqParseInput3 has had the behavior  
since perhaps 2003, getCopyDataMessage at least since commit 70066eb1a1ad  
in 2008.  Probably the reason it's not been isolated before is that in  
common environments the recv() loop would always be faster than the server  
(if on the same machine) or faster than the network (if not); or at least  
it wouldn't be slower consistently enough to let the buffer ramp up to a  
problematic size.  The reported cases involve Windows, which perhaps has  
different timing behavior than other platforms.  
  
Per bug #7914 from Shin-ichi Morita, though this is different from his  
proposed solution.  Back-patch to all supported branches.  

commit   : be7558162acc5578d0b2cf0c8d4c76b6076ce352    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 May 2014 17:43:39 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 May 2014 17:43:39 -0400    

The previous behavior was to restart immediately, which was generally  
viewed as less useful.  
  
Petr Jelinek, with some adjustments by me.  

commit   : 7572b7735971cd7a5ef289e133eedf7d82f79c42    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 8 May 2014 00:05:43 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 8 May 2014 00:05:43 +0300    

Oops, I didn't realize that contrib/hstore refers to jsonb stuff.  

commit   : eee6cf1f337aa488a20e9111df446cdad770e645    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 May 2014 16:30:23 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 May 2014 16:30:23 -0400    

Commit e2ce9aa27bf20eff2d991d0267a15ea5f7024cd7 was insufficiently  
well thought out.  Repair.  

commit   : 970d1f76d1600dfbdbd9cd88a9e2af113e253798    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 May 2014 16:04:47 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 May 2014 16:04:47 -0400    

Just as we would start bgworkers immediately after an initial startup  
of the server, we should restart them immediately when reinitializing.  
  
Petr Jelinek and Robert Haas  

commit   : 364ddc3e5cbd01c93a39896b5260509129a9883e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 May 2014 23:16:19 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 May 2014 23:16:19 +0300    

The main target of this cleanup is the convertJsonb() function, but I also  
touched a lot of other things that I spotted into in the process.  
  
The new convertToJsonb() function uses an output buffer that's resized on  
demand, so the code to estimate of the size of JsonbValue is removed.  
  
The on-disk format was not changed, even though I refactored the structs  
used to handle it. The term "superheader" is replaced with "container".  
  
The jsonb_exists_any and jsonb_exists_all functions no longer sort the input  
array. That was a premature optimization, the idea being that if there are  
duplicates in the input array, you only need to check them once. Also,  
sorting the array saves some effort in the binary search used to find a key  
within an object. But there were drawbacks too: the sorting and  
deduplicating obviously isn't free, and in the typical case there are no  
duplicates to remove, and the gain in the binary search was minimal. Remove  
all that, which makes the code simpler too.  
  
This includes a bug-fix; the total length of the elements in a jsonb array  
or object mustn't exceed 2^28. That is now checked.  

commit   : 4d155d8b08fe08c1a1649fdbad61c6dcf4a8671f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 May 2014 14:54:43 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 May 2014 14:54:43 -0400    

Since the postmaster won't perform a crash-and-restart sequence  
for background workers which don't request shared memory access,  
we'd better make sure that they can't corrupt shared memory.  
  
Patch by me, review by Tom Lane.  

commit   : 04e5025be8bbe572e12b19c4ba9e2a8360b8ffe5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 May 2014 14:25:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 May 2014 14:25:11 -0400    

ActiveSnapshot needs to be set when we call ExecutorRewind because some  
plan node types may execute user-defined functions during their ReScan  
calls (nodeLimit.c does so, at least).  The wisdom of that is somewhat  
debatable, perhaps, but for now the simplest fix is to make sure the  
required context is valid.  Failure to do this typically led to a  
null-pointer-dereference core dump, though it's possible that in more  
complex cases a function could be executed with the wrong snapshot  
leading to very subtle misbehavior.  
  
Per report from Leif Jensen.  It's been broken for a long time, so  
back-patch to all active branches.  

commit   : e2ce9aa27bf20eff2d991d0267a15ea5f7024cd7    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 May 2014 13:19:02 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 7 May 2014 13:19:02 -0400    

The motivation for a crash and restart cycle when a backend dies is  
that it might have corrupted shared memory on the way down; and we  
can't recover reliably except by reinitializing everything.  But that  
doesn't apply to processes that don't touch shared memory.  Currently,  
there's nothing to prevent a background worker that doesn't request  
shared memory access from touching shared memory anyway, but that's a  
separate bug.  
  
Previous to this commit, the coding in postmaster.c was inconsistent:  
an exit status other than 0 or 1 didn't provoke a crash-and-restart,  
but failure to release the postmaster child slot did.  This change  
makes those cases consistent.  

commit   : 1891b415f0cf45d56f29af423598f8518754d675    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 May 2014 23:52:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 May 2014 23:52:30 -0400    

commit   : 348aa75a678069569923c501206d5a1ca03654e3    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 6 May 2014 19:35:24 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 6 May 2014 19:35:24 -0700    

Commit 4318daecc959886d001a6e79c6ea853e8b1dfb4b introduced a test that  
couldn't be made consistent between integer and floating-point  
timestamps.  
  
It was designed to test the longest possible interval output length,  
so removing four zeros from the number of hours, as this patch does,  
is not ideal. But the test still has some utility for its original  
purpose, and there aren't a lot of other good options.  
  
Noah Misch suggested a different approach where we test that the  
output either matches what we expect from integer timestamps or what  
we expect from floating-point timestamps. That seemed to obscure an  
otherwise simple test, however.  
  
Reviewed by Tom Lane and Noah Misch.  

commit   : 2c22afaa4e29cbd773bae3f043a941f82ff30e2d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 May 2014 22:49:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 May 2014 22:49:32 -0400    

The coding in JsonbHashScalarValue might have accidentally failed to fail  
given current representational choices, but the key word there would be  
"accidental".  Insert the appropriate datatype conversion macro.  And  
use the right conversion macro for hash_numeric's result, too.  
  
In passing make the code a bit cleaner and less repetitive by factoring  
out the xor step from the switch.  

commit   : 35c0cd3b05b0be18dc2d049c33b38a2d13993ffe    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 4 May 2014 13:18:55 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 4 May 2014 13:18:55 -0700    

Index-only scans avoid taking a lock on the VM buffer, which would  
cause a lot of contention. To be correct, that requires some intricate  
assumptions that weren't completely documented in the previous  
comment.  
  
Reviewed by Robert Haas.  

commit   : 3a9d430af515e9dd8a9d34a4011367e667a66521    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 6 May 2014 21:28:58 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 6 May 2014 21:28:58 -0400    

The main problem is that DocBook SGML allows indexterm elements just  
about everywhere, but DocBook XML is stricter.  For example, this common  
pattern  
  
    <varlistentry>  
     <indexterm>...</indexterm>  
     <term>...</term>  
     ...  
    </varlistentry>  
  
needs to be changed to something like  
  
    <varlistentry>  
     <term>...<indexterm>...</indexterm></term>  
     ...  
    </varlistentry>  
  
See also bb4eefe7bf518e42c73797ea37b033a5d8a8e70a.  
  
There is currently nothing in the build system that enforces that things  
stay valid, because that requires additional tools and will receive  
separate consideration.  

commit   : 84288a86ac74dbeae486b6ff699c017f7d9517bb    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2014 20:39:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2014 20:39:28 -0400    

Report by Tom Lane  

commit   : 9516668e48abcc5c036ecb199acf15e5bcc4b008    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2014 20:09:00 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2014 20:09:00 -0400    

Report by Tom Lane  

commit   : 250f259a44411d341e75928401503a681844c59d    
  
author   : Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 6 May 2014 22:50:06 +0100    
  
committer: Simon Riggs <simon@2ndQuadrant.com>    
date     : Tue, 6 May 2014 22:50:06 +0100    

Allow for translatable string, rather than use "or"  

commit   : 7c7b1f4ae5ea3b1b113682d4d4e5af4356b053bc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2014 15:33:25 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2014 15:33:25 -0400    

commit   : e0124230ba2b6778671f26b06af0d8d04bcb4d1c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 6 May 2014 13:37:46 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 6 May 2014 13:37:46 -0400    

The previous coding would potentially cause attaching to segment A to  
fail if segment B was at the same time in the process of going away.  
  
Andres Freund, with a comment tweak by me  

commit   : 4335c958154c39ef99a38dc953b3f803b13a1048    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2014 12:20:51 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2014 12:20:51 -0400    

Fix for commit 14ea89366fe321609afc5838ff9fe2ded1cd707d  
  
Report by Andres Freund  

commit   : 0a7832005792fa6dad171f9cadb8d587fe0dd800    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2014 12:12:18 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 6 May 2014 12:12:18 -0400    

This includes removing tabs after periods in C comments, which was  
applied to back branches, so this change should not effect backpatching.