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