PostgreSQL 9.5.1 commit log

Stamp 9.5.1.

commit   : 616eaa396a9bf82d8208a79367d784590be9370d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Feb 2016 16:12:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Feb 2016 16:12:28 -0500    

Click here for diff

M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc

Translation updates

commit   : 477bee7dc66e5c227f621564b5c448ba8948406b    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Feb 2016 14:21:00 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 8 Feb 2016 14:21:00 -0500    

Click here for diff

Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: f323fead9293175a0c3320116c97e4be56b9be61  

M src/backend/po/de.po
M src/backend/po/pl.po
M src/backend/po/ru.po
M src/bin/initdb/nls.mk
A src/bin/initdb/po/ko.po
M src/bin/pg_basebackup/nls.mk
A src/bin/pg_basebackup/po/ko.po
M src/bin/pg_controldata/nls.mk
A src/bin/pg_controldata/po/ko.po
M src/bin/pg_controldata/po/pl.po
M src/bin/pg_ctl/nls.mk
A src/bin/pg_ctl/po/ko.po
M src/bin/pg_dump/nls.mk
M src/bin/pg_dump/po/de.po
A src/bin/pg_dump/po/ko.po
M src/bin/pg_dump/po/pl.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetxlog/nls.mk
A src/bin/pg_resetxlog/po/ko.po
M src/bin/pg_resetxlog/po/pl.po
M src/bin/pg_rewind/nls.mk
A src/bin/pg_rewind/po/ko.po
M src/bin/psql/po/pl.po
M src/bin/psql/po/ru.po
M src/bin/scripts/nls.mk
A src/bin/scripts/po/ko.po
M src/interfaces/ecpg/ecpglib/nls.mk
A src/interfaces/ecpg/ecpglib/po/ko.po
M src/interfaces/libpq/nls.mk
A src/interfaces/libpq/po/ko.po
M src/pl/plperl/nls.mk
A src/pl/plperl/po/ko.po
M src/pl/plpgsql/src/nls.mk
A src/pl/plpgsql/src/po/ko.po
M src/pl/plpython/po/de.po
M src/pl/plpython/po/ru.po
M src/pl/tcl/nls.mk
A src/pl/tcl/po/ko.po

Last-minute updates for release notes.

commit   : 129b6cf5ebc26f23d13371561bb9df643b3f6592    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Feb 2016 10:49:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Feb 2016 10:49:37 -0500    

Click here for diff

Security: CVE-2016-0773  

M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
M doc/src/sgml/release-9.5.sgml

Fix some regex issues with out-of-range characters and large char ranges.

commit   : a61de2bc13354148fb0e3b2f5ef82fdbd41c51cc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Feb 2016 10:25:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Feb 2016 10:25:40 -0500    

Click here for diff

Previously, our regex code defined CHR_MAX as 0xfffffffe, which is a  
bad choice because it is outside the range of type "celt" (int32).  
Characters approaching that limit could lead to infinite loops in logic  
such as "for (c = a; c <= b; c++)" where c is of type celt but the  
range bounds are chr.  Such loops will work safely only if CHR_MAX+1  
is representable in celt, since c must advance to beyond b before the  
loop will exit.  
  
Fortunately, there seems no reason not to restrict CHR_MAX to 0x7ffffffe.  
It's highly unlikely that Unicode will ever assign codes that high, and  
none of our other backend encodings need characters beyond that either.  
  
In addition to modifying the macro, we have to explicitly enforce character  
range restrictions on the values of \u, \U, and \x escape sequences, else  
the limit is trivially bypassed.  
  
Also, the code for expanding case-independent character ranges in bracket  
expressions had a potential integer overflow in its calculation of the  
number of characters it could generate, which could lead to allocating too  
small a character vector and then overwriting memory.  An attacker with the  
ability to supply arbitrary regex patterns could easily cause transient DOS  
via server crashes, and the possibility for privilege escalation has not  
been ruled out.  
  
Quite aside from the integer-overflow problem, the range expansion code was  
unnecessarily inefficient in that it always produced a result consisting of  
individual characters, abandoning the knowledge that we had a range to  
start with.  If the input range is large, this requires excessive memory.  
Change it so that the original range is reported as-is, and then we add on  
any case-equivalent characters that are outside that range.  With this  
approach, we can bound the number of individual characters allowed without  
sacrificing much.  This patch allows at most 100000 individual characters,  
which I believe to be more than the number of case pairs existing in  
Unicode, so that the restriction will never be hit in practice.  
  
It's still possible for range() to take awhile given a large character code  
range, so also add statement-cancel detection to its loop.  The downstream  
function dovec() also lacked cancel detection, and could take a long time  
given a large output from range().  
  
Per fuzz testing by Greg Stark.  Back-patch to all supported branches.  
  
Security: CVE-2016-0773  

M src/backend/regex/regc_lex.c
M src/backend/regex/regc_locale.c
M src/backend/regex/regcomp.c
M src/include/regex/regcustom.h
M src/test/regress/expected/regex.out
M src/test/regress/sql/regex.sql

Fix overeager pushdown of HAVING clauses when grouping sets are used.

commit   : 87dbc72a79bbd84aaba3a8c543a093106392da8d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 8 Feb 2016 11:03:31 +0100    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 8 Feb 2016 11:03:31 +0100    

Click here for diff

In 61444bfb we started to allow HAVING clauses to be fully pushed down  
into WHERE, even when grouping sets are in use. That turns out not to  
work correctly, because grouping sets can "produce" NULLs, meaning that  
filtering in WHERE and HAVING can have different results, even when no  
aggregates or volatile functions are involved.  
  
Instead only allow pushdown of empty grouping sets.  
  
It'd be nice to do better, but the exact mechanics of deciding which  
cases are safe are still being debated. It's important to give correct  
results till we find a good solution, and such a solution might not be  
appropriate for backpatching anyway.  
  
Bug: #13863  
Reported-By: 'wrb'  
Diagnosed-By: Dean Rasheed  
Author: Andrew Gierth  
Reviewed-By: Dean Rasheed and Andres Freund  
Discussion: 20160113183558.12989.56904@wrigleys.postgresql.org  
Backpatch: 9.5, where grouping sets were introduced  

M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/groupingsets.out
M src/test/regress/sql/groupingsets.sql

Improve documentation about PRIMARY KEY constraints.

commit   : 65f1510a82a2e792b8b0c4ffacdb4e996410d943    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Feb 2016 16:02:44 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Feb 2016 16:02:44 -0500    

Click here for diff

Get rid of the false implication that PRIMARY KEY is exactly equivalent to  
UNIQUE + NOT NULL.  That was more-or-less true at one time in our  
implementation, but the standard doesn't say that, and we've grown various  
features (many of them required by spec) that treat a pkey differently from  
less-formal constraints.  Per recent discussion on pgsql-general.  
  
I failed to resist the temptation to do some other wordsmithing in the  
same area.  

M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/create_table.sgml

Fix deparsing of ON CONFLICT arbiter WHERE clauses.

commit   : 82406d6ff1aa9f2e77536d91492a2d2b7e20b5c7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Feb 2016 14:57:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Feb 2016 14:57:24 -0500    

Click here for diff

The parser doesn't allow qualification of column names appearing in  
these clauses, but ruleutils.c would sometimes qualify them, leading  
to dump/reload failures.  Per bug #13891 from Onder Kalaci.  
  
(In passing, make stanzas in ruleutils.c that save/restore varprefix  
more consistent.)  
  
Peter Geoghegan  

M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/rules.out

Release notes for 9.5.1, 9.4.6, 9.3.11, 9.2.15, 9.1.20.

commit   : bd0302c39d8439912c0643058913236e69128830    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Feb 2016 14:16:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Feb 2016 14:16:31 -0500    

Click here for diff

M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
M doc/src/sgml/release-9.5.sgml

ExecHashRemoveNextSkewBucket must physically copy tuples to main hashtable.

commit   : 129db3cbee704e71cff9f90f62691488c8ef768d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Feb 2016 12:29:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Feb 2016 12:29:17 -0500    

Click here for diff

Commit 45f6240a8fa9d355 added an assumption in ExecHashIncreaseNumBatches  
and ExecHashIncreaseNumBuckets that they could find all tuples in the main  
hash table by iterating over the "dense storage" introduced by that patch.  
However, ExecHashRemoveNextSkewBucket continued its old practice of simply  
re-linking deleted skew tuples into the main table's hashchains.  Hence,  
such tuples got lost during any subsequent increase in nbatch or nbuckets,  
and would never get joined, as reported in bug #13908 from Seth P.  
  
I (tgl) think that the aforesaid commit has got multiple design issues  
and should be reworked rather completely; but there is no time for that  
right now, so band-aid the problem by making ExecHashRemoveNextSkewBucket  
physically copy deleted skew tuples into the "dense storage" arena.  
  
The added test case is able to exhibit the problem by means of fooling the  
planner with a WHERE condition that it will underestimate the selectivity  
of, causing the initial nbatch estimate to be too small.  
  
Tomas Vondra and Tom Lane.  Thanks to David Johnston for initial  
investigation into the bug report.  

M src/backend/executor/nodeHash.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql

Improve HJDEBUG code a bit.

commit   : 2b94b5ef8df1b037307634f8d0f881e2651d654e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Feb 2016 15:05:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Feb 2016 15:05:23 -0500    

Click here for diff

Commit 30d7ae3c76d2de144232ae6ab328ca86b70e72c3 introduced an HJDEBUG  
stanza that probably didn't compile at the time, and definitely doesn't  
compile now, because it refers to a nonexistent variable.  It doesn't seem  
terribly useful anyway, so just get rid of it.  
  
While I'm fooling with it, use %z modifier instead of the obsolete hack of  
casting size_t to unsigned long, and include the HashJoinTable's address in  
each printout so that it's possible to distinguish the activities of  
multiple hashjoins occurring in one query.  
  
Noted while trying to use HJDEBUG to investigate bug #13908.  Back-patch  
to 9.5, because code that doesn't compile is certainly not very helpful.  

M src/backend/executor/nodeHash.c

Force certain “pljava” custom GUCs to be PGC_SUSET.

commit   : 0089dd34aa9bc5a1272c4c2fbcf183a0f983cf73    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 5 Feb 2016 20:22:51 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 5 Feb 2016 20:22:51 -0500    

Click here for diff

Future PL/Java versions will close CVE-2016-0766 by making these GUCs  
PGC_SUSET.  This PostgreSQL change independently mitigates that PL/Java  
vulnerability, helping sites that update PostgreSQL more frequently than  
PL/Java.  Back-patch to 9.1 (all supported versions).  

M src/backend/utils/misc/guc.c

Update time zone data files to tzdata release 2016a.

commit   : 37e6946329005b143d2b2f924e39e590661e1fab    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Feb 2016 10:59:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 5 Feb 2016 10:59:09 -0500    

Click here for diff

DST law changes in Cayman Islands, Metlakatla, Trans-Baikal Territory  
(Zabaykalsky Krai).  Historical corrections for Pakistan.  

M src/timezone/data/asia
M src/timezone/data/backward
M src/timezone/data/backzone
M src/timezone/data/europe
M src/timezone/data/northamerica
M src/timezone/data/zone.tab
M src/timezone/data/zone1970.tab

postgres_fdw: Avoid possible misbehavior when RETURNING tableoid column only.

commit   : d160e2a343996030804cc6b74cc5a0b133dae950    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 4 Feb 2016 22:15:50 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 4 Feb 2016 22:15:50 -0500    

Click here for diff

deparseReturningList ended up adding up RETURNING NULL to the code, but  
code elsewhere saw an empty list of attributes and concluded that it  
should not expect tuples from the remote side.  
  
Etsuro Fujita and Robert Haas, reviewed by Thom Brown  

M contrib/postgres_fdw/deparse.c
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql

When modifying a foreign table, initialize tableoid field properly.

commit   : 453d40817cd27910930248ab23a1e81fa04628f1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 4 Feb 2016 21:15:57 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 4 Feb 2016 21:15:57 -0500    

Click here for diff

Failure to do this can cause AFTER ROW triggers or RETURNING expressions  
that reference this field to misbehave.  
  
Etsuro Fujita, reviewed by Thom Brown  

M src/backend/executor/nodeModifyTable.c

Simplify syntax diagram for REINDEX.

commit   : 3676136ffc5cb20163540332670df90b029a8317    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Feb 2016 13:58:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Feb 2016 13:58:40 -0500    

Click here for diff

Since there currently is only one possible parenthesized option, namely  
VERBOSE, it's a bit pointless to show it with "{ } [, ... ]".  The curly  
braces are useless and therefore confusing, as seen in a recent question  
from Karsten Hilbert.  Remove the extra decoration for the time being;  
we can put it back when and if REINDEX grows some more options.  

M doc/src/sgml/ref/reindex.sgml

In pg_dump, ensure that view triggers are processed after view rules.

commit   : b99dd71705eaf2d73c9f45086ceef7e9075c1c2f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Feb 2016 00:26:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 4 Feb 2016 00:26:10 -0500    

Click here for diff

If a view is split into CREATE TABLE + CREATE RULE to break a circular  
dependency, then any triggers on the view must be dumped/reloaded after  
the CREATE RULE; else the backend may reject the CREATE TRIGGER because  
it's the wrong type of trigger for a plain table.  This works all right  
in plain dump/restore because of pg_dump's sorting heuristic that places  
triggers after rules.  However, when using parallel restore, the ordering  
must be enforced by a dependency --- and we didn't have one.  
  
Fixing this is a mere matter of adding an addObjectDependency() call,  
except that we need to be able to find all the triggers belonging to the  
view relation, and there was no easy way to do that.  Add fields to  
pg_dump's TableInfo struct to remember where the associated TriggerInfo  
struct(s) are.  
  
Per bug report from Dennis Kögel.  The failure can be exhibited at least  
as far back as 9.1, so back-patch to all supported branches.  

M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/bin/pg_dump/pg_dump_sort.c

Add hstore_to_jsonb() and hstore_to_jsonb_loose() to hstore documentation.

commit   : b523a5c0e5329f7b9e1f15a189dda6936384e630    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Feb 2016 12:56:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Feb 2016 12:56:40 -0500    

Click here for diff

These were never documented anywhere user-visible.  Tut tut.  

M doc/src/sgml/hstore.sgml

Fix IsValidJsonNumber() to notice trailing non-alphanumeric garbage.

commit   : 1c291624b29dae2049ff1c7008563fbca85df658    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Feb 2016 01:39:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 3 Feb 2016 01:39:08 -0500    

Click here for diff

Commit e09996ff8dee3f70 was one brick shy of a load: it didn't insist  
that the detected JSON number be the whole of the supplied string.  
This allowed inputs such as "2016-01-01" to be misdetected as valid JSON  
numbers.  Per bug #13906 from Dmitry Ryabov.  
  
In passing, be more wary of zero-length input (I'm not sure this can  
happen given current callers, but better safe than sorry), and do some  
minor cosmetic cleanup.  

M contrib/hstore/expected/hstore.out
M contrib/hstore/sql/hstore.sql
M src/backend/utils/adt/json.c

Fix pg_description entries for jsonb_to_record() and jsonb_to_recordset().

commit   : f39c927114941cd1f245ef77df7776b0583057b0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Feb 2016 11:39:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 2 Feb 2016 11:39:50 -0500    

Click here for diff

All the other jsonb function descriptions refer to the arguments as being  
"jsonb", but these two said "json".  Make it consistent.  Per bug #13905  
from Petru Florin Mihancea.  
  
No catversion bump --- we can't force one in the back branches, and this  
isn't very critical anyway.  

M src/include/catalog/pg_proc.h

Fix typo in comment

commit   : 081f7fe11024d281e6aae0904a5ff03bfa6f0811    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 2 Feb 2016 13:49:02 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 2 Feb 2016 13:49:02 +0100    

Click here for diff

M src/bin/pg_basebackup/pg_recvlogical.c

Fix lossy KNN GiST when ordering operator returns non-float8 value.

commit   : 62e0ade9aa89c8f88ce506e1cb4be6e3697ee2d0    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Tue, 2 Feb 2016 15:21:03 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Tue, 2 Feb 2016 15:21:03 +0300    

Click here for diff

KNN GiST with recheck flag should return to executor the same type as ordering  
operator, GiST detects this type by looking to return type of function which  
implements ordering operator. But occasionally detecting code works after  
replacing ordering operator function to distance support function.  
Distance support function always returns float8, so, detecting code get float8  
instead of actual return type of ordering operator.  
  
Built-in opclasses don't have ordering operator which doesn't return  
non-float8 value, so, tests are impossible here, at least now.  
  
Backpatch to 9.5 where lozzy KNN was introduced.  
  
Author: Alexander Korotkov  
Report by: Artur Zakirov  

M src/backend/access/gist/gistscan.c

pgbench: Install guards against obscure overflow conditions.

commit   : 829757c8a225e5b81a398823d77fa6c0809cf863    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 1 Feb 2016 08:23:41 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 1 Feb 2016 08:23:41 -0500    

Click here for diff

Dividing INT_MIN by -1 or taking INT_MIN modulo -1 can sometimes  
cause floating-point exceptions or otherwise misbehave.  
  
Fabien Coelho and Michael Paquier  

M src/bin/pgbench/pgbench.c

Make sure ecpg header files do not have a comment lasting several lines, one of which is a preprocessor directive. This leads ecpg to incorrectly parse the comment as nested.

commit   : 40482e606733675eb9e5b2f7221186cf81352da1    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Mon, 1 Feb 2016 13:10:40 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Mon, 1 Feb 2016 13:10:40 +0100    

Click here for diff

M src/interfaces/ecpg/include/datetime.h
M src/interfaces/ecpg/include/decimal.h

Fix misspelled function name in comment.

commit   : 6ceca3f4a2195e4a58da91062afa909e08a74f8c    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 1 Feb 2016 10:10:24 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 1 Feb 2016 10:10:24 +0200    

Click here for diff

M src/backend/access/transam/xloginsert.c

Fix error in documentated use of mingw-w64 compilers

commit   : a16763d892b8c145ec99bba3e61fd81a27a581df    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 30 Jan 2016 19:28:44 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 30 Jan 2016 19:28:44 -0500    

Click here for diff

Error reported by Igal Sapir.  

M doc/src/sgml/installation.sgml

Fix incorrect pattern-match processing in psql’s \det command.

commit   : 56251f3965ac5563bb19ef8f17ee27ac95359ce7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Jan 2016 10:28:02 +0100    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 29 Jan 2016 10:28:02 +0100    

Click here for diff

listForeignTables' invocation of processSQLNamePattern did not match up  
with the other ones that handle potentially-schema-qualified names; it  
failed to make use of pg_table_is_visible() and also passed the name  
arguments in the wrong order.  Bug seems to have been aboriginal in commit  
0d692a0dc9f0e532.  It accidentally sort of worked as long as you didn't  
inquire too closely into the behavior, although the silliness was later  
exposed by inconsistencies in the test queries added by 59efda3e50ca4de6  
(which I probably should have questioned at the time, but didn't).  
  
Per bug #13899 from Reece Hart.  Patch by Reece Hart and Tom Lane.  
Back-patch to all affected branches.  

M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/bin/psql/describe.c

Fix syntax descriptions for replication commands in logicaldecoding.sgml

commit   : cb89a3afaa7196954fed42b7b823b5cdfbf2a455    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 29 Jan 2016 12:14:56 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 29 Jan 2016 12:14:56 +0900    

Click here for diff

Patch-by: Oleksandr Shulgin  
Reviewed-by: Craig Ringer and Fujii Masao  
Backpatch-through: 9.4 where logical decoding was introduced  

M doc/src/sgml/logicaldecoding.sgml

Add [NO]BYPASSRLS options to CREATE USER and ALTER USER docs.

commit   : db58a95931daaa6a593f9d7968bf6adec070ce6d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 28 Jan 2016 09:29:04 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 28 Jan 2016 09:29:04 -0500    

Click here for diff

Patch-by: Filip Rembiałkowski  
Reviewed-by: Robert Haas  
Backpatch-through: 9.5  

M doc/src/sgml/ref/alter_user.sgml
M doc/src/sgml/ref/create_user.sgml

Fix spi_worker mention in bgworker documentation

commit   : 950beba0035e862e1f884c1222895055dfcf1500    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 28 Jan 2016 14:08:21 +0100    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 28 Jan 2016 14:08:21 +0100    

Click here for diff

The documentation mentioned contrib/ but the module was moved to  
src/test/modules/ by commit 22dfd116a127a of 9.5 era.  
  
Problem pointed out by Dickson Guedes in bug #13896  
Backpatch-to: 9.5.  

M doc/src/sgml/bgworker.sgml

Fix startup so that log prefix %h works for the log_connections message.

commit   : 2acb682f68255e9df4f31ff6421d900a467a4675    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Jan 2016 15:38:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Jan 2016 15:38:33 -0500    

Click here for diff

We entirely randomly chose to initialize port->remote_host just after  
printing the log_connections message, when we could perfectly well do it  
just before, allowing %h and %r to work for that message.  Per gripe from  
Artem Tomyuk.  

M src/backend/postmaster/postmaster.c

Revert “Fix broken multibyte regression tests.”

commit   : e8267aba5fcf9f107cd20b8d0e7d199ecaf74a27    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Tue, 26 Jan 2016 09:00:33 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Tue, 26 Jan 2016 09:00:33 +0900    

Click here for diff

This reverts commit 479cb1e420c40d78b49535c0ceeaa5f65c7d6797.  
  
The commit was plain wrong as pointed out in:  
http://www.postgresql.org/message-id/27771.1448736909@sss.pgh.pa.us  

M src/test/mb/expected/big5.out
M src/test/mb/expected/euc_jp.out
M src/test/mb/expected/euc_kr.out
M src/test/mb/expected/euc_tw.out
M src/test/mb/expected/gb18030.out
M src/test/mb/expected/mule_internal.out
M src/test/mb/expected/sjis.out
M src/test/mb/expected/utf8.out

pg_dump: Fix quoting of domain constraint names

commit   : 1e910cf5baf35721b1d889bd3e976e49e0694857    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 22 Jan 2016 20:04:35 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 22 Jan 2016 20:04:35 -0300    

Click here for diff

The original code was adding double quotes to an already-quoted  
identifier, leading to nonsensical results.  Remove the quoting call.  
  
I introduced the broken code in 7eca575d1c of 9.5 era, so backpatch to  
9.5.  
  
Report and patch by Elvis Pranskevichus  
Reviewed by Michael Paquier  

M src/bin/pg_dump/pg_dump.c

Improve levenshtein() docs.

commit   : 042a3e2353e366cc1e571078fd92c7365fe12d46    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Jan 2016 12:29:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Jan 2016 12:29:07 -0500    

Click here for diff

Fix chars-vs-bytes confusion here too.  Improve poor grammar and  
markup.  

M doc/src/sgml/fuzzystrmatch.sgml

Remove new coupling between NAMEDATALEN and MAX_LEVENSHTEIN_STRLEN.

commit   : 47acf3add32eb59fc3717ffbe21fd872b037a8f2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Jan 2016 11:53:06 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Jan 2016 11:53:06 -0500    

Click here for diff

Commit e529cd4ffa605c6f introduced an Assert requiring NAMEDATALEN to be  
less than MAX_LEVENSHTEIN_STRLEN, which has been 255 for a long time.  
Since up to that instant we had always allowed NAMEDATALEN to be  
substantially more than that, this was ill-advised.  
  
It's debatable whether we need MAX_LEVENSHTEIN_STRLEN at all (versus  
putting a CHECK_FOR_INTERRUPTS into the loop), or whether it has to be  
so tight; but this patch takes the narrower approach of just not applying  
the MAX_LEVENSHTEIN_STRLEN limit to calls from the parser.  
  
Trusting the parser for this seems reasonable, first because the strings  
are limited to NAMEDATALEN which is unlikely to be hugely more than 256,  
and second because the maximum distance is tightly constrained by  
MAX_FUZZY_DISTANCE (though we'd forgotten to make use of that limit in one  
place).  That means the cost is not really O(mn) but more like O(max(m,n)).  
  
Relaxing the limit for user-supplied calls is left for future research;  
given the lack of complaints to date, it doesn't seem very high priority.  
  
In passing, fix confusion between lengths-in-bytes and lengths-in-chars  
in comments and error messages.  
  
Per gripe from Kevin Day; solution suggested by Robert Haas.  Back-patch  
to 9.5 where the unwanted restriction was introduced.  

M contrib/fuzzystrmatch/fuzzystrmatch.c
M src/backend/parser/parse_relation.c
M src/backend/utils/adt/levenshtein.c
M src/include/utils/builtins.h

Add defenses against putting expanded objects into Const nodes.

commit   : e80c85e4e8d9b7bd02ff5737f7a740487cee71d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jan 2016 12:55:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Jan 2016 12:55:59 -0500    

Click here for diff

Putting a reference to an expanded-format value into a Const node would be  
a bad idea for a couple of reasons.  It'd be possible for the supposedly  
immutable Const to change value, if something modified the referenced  
variable ... in fact, if the Const's reference were R/W, any function that  
has the Const as argument might itself change it at runtime.  Also, because  
datumIsEqual() is pretty simplistic, the Const might fail to compare equal  
to other Consts that it should compare equal to, notably including copies  
of itself.  This could lead to unexpected planner behavior, such as "could  
not find pathkey item to sort" errors or inferior plans.  
  
I have not been able to find any way to get an expanded value into a Const  
within the existing core code; but Paul Ramsey was able to trigger the  
problem by writing a datatype input function that returns an expanded  
value.  
  
The best fix seems to be to establish a rule that varlena values being  
placed into Const nodes should be passed through pg_detoast_datum().  
That will do nothing (and cost little) in normal cases, but it will flatten  
expanded values and thereby avoid the above problems.  Also, it will  
convert short-header or compressed values into canonical format, which will  
avoid possible unexpected lack-of-equality issues for those cases too.  
And it provides a last-ditch defense against putting a toasted value into  
a Const, which we already knew was dangerous, cf commit 2b0c86b66563cf2f.  
(In the light of this discussion, I'm no longer sure that that commit  
provided 100% protection against such cases, but this fix should do it.)  
  
The test added in commit 65c3d05e18e7c530 to catch datatype input functions  
with unstable results would fail for functions that returned expanded  
values; but it seems a bit uncharitable to deem a result unstable just  
because it's expressed in expanded form, so revise the coding so that we  
check for bitwise equality only after applying pg_detoast_datum().  That's  
a sufficient condition anyway given the new rule about detoasting when  
forming a Const.  
  
Back-patch to 9.5 where the expanded-object facility was added.  It's  
possible that this should go back further; but in the absence of clear  
evidence that there's any live bug in older branches, I'll refrain for now.  

M src/backend/nodes/makefuncs.c
M src/backend/optimizer/util/clauses.c
M src/backend/parser/parse_coerce.c
M src/backend/parser/parse_type.c
M src/include/nodes/primnodes.h

Properly install dynloader.h on MSVC builds

commit   : 34bda20ae516585b6e07d6d4b4176268f19e7c52    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Jan 2016 23:30:29 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 19 Jan 2016 23:30:29 -0500    

Click here for diff

This will enable PL/Java to be cleanly compiled, as dynloader.h is a  
requirement.  
  
Report by Chapman Flack  
  
Patch by Michael Paquier  
  
Backpatch through 9.1  

M src/backend/utils/fmgr/dfmgr.c
M src/tools/msvc/Install.pm
M src/tools/msvc/Solution.pm
M src/tools/msvc/clean.bat

Fix typo.

commit   : 77a1863c94e21eceaef65eab0b4bd24eea57ef97    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Mon, 18 Jan 2016 21:26:30 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Mon, 18 Jan 2016 21:26:30 +0900    

Click here for diff

Reported by KOIZUMI Satoru.  

M doc/src/sgml/datatype.sgml

Remove dead code in pg_dump.

commit   : 6b3b3a502e5d96cd992470bd408dd7457139caf0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Jan 2016 11:38:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Jan 2016 11:38:40 -0500    

Click here for diff

Coverity quite reasonably complained that this check for fout==NULL  
occurred after we'd already dereferenced fout.  However, the check  
is just dead code since there is no code path by which CreateArchive  
can return a null pointer.  Errors such as can't-open-that-file are  
reported down inside CreateArchive, and control doesn't return.  
So let's silence the warning by removing the dead code, rather than  
continuing to pretend it does something.  
  
Coverity didn't complain about this before 5b5fea2a1, so back-patch  
to 9.5 like that patch.  

M src/bin/pg_dump/pg_dump.c

Fix spelling mistake.

commit   : 0760225ccf611310e8e2afc6fe22e606a8f9bf18    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 14 Jan 2016 23:12:05 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 14 Jan 2016 23:12:05 -0500    

Click here for diff

Same patch submitted independently by David Rowley and Peter Geoghegan.  

M src/bin/pg_upgrade/controldata.c

Properly close token in sspi authentication

commit   : 3276ca303d44025a5e1232a1e62152ea95a26b03    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 14 Jan 2016 13:06:03 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 14 Jan 2016 13:06:03 +0100    

Click here for diff

We can never leak more than one token, but we shouldn't do that. We  
don't bother closing it in the error paths since the process will  
exit shortly anyway.  
  
Christian Ullrich  

M src/backend/libpq/auth.c

Handle extension members when first setting object dump flags in pg_dump.

commit   : c42df2d46c4223127116b1d7eb27719adbba39ab    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jan 2016 18:55:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jan 2016 18:55:27 -0500    

Click here for diff

pg_dump's original approach to handling extension member objects was to  
run around and clear (or set) their dump flags rather late in its data  
collection process.  Unfortunately, quite a lot of code expects those flags  
to be valid before that; which was an entirely reasonable expectation  
before we added extensions.  In particular, this explains Karsten Hilbert's  
recent report of pg_upgrade failing on a database in which an extension  
has been installed into the pg_catalog schema.  Its objects are initially  
marked as not-to-be-dumped on the strength of their schema, and later we  
change them to must-dump because we're doing a binary upgrade of their  
extension; but we've already skipped essential tasks like making associated  
DO_SHELL_TYPE objects.  
  
To fix, collect extension membership data first, and incorporate it in the  
initial setting of the dump flags, so that those are once again correct  
from the get-go.  This has the undesirable side effect of slightly  
lengthening the time taken before pg_dump acquires table locks, but testing  
suggests that the increase in that window is not very much.  
  
Along the way, get rid of ugly special-case logic for deciding whether  
to dump procedural languages, FDWs, and foreign servers; dump decisions  
for those are now correct up-front, too.  
  
In 9.3 and up, this also fixes erroneous logic about when to dump event  
triggers (basically, they were *always* dumped before).  In 9.5 and up,  
transform objects had that problem too.  
  
Since this problem came in with extensions, back-patch to all supported  
versions.  

M src/bin/pg_dump/common.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h

Access pg_dump’s options structs through Archive struct, not directly.

commit   : 6adba13e42a34750ef2f88ec0780db8416d8bf2e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jan 2016 17:48:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Jan 2016 17:48:33 -0500    

Click here for diff

Rather than passing around DumpOptions and RestoreOptions as separate  
arguments, add fields to struct Archive to carry pointers to these objects,  
and access them through those fields when needed.  There already was a  
RestoreOptions pointer in Archive, though for no obvious reason it was part  
of the "private" struct rather than out where pg_dump.c could see it.  
  
Doing this allows reversion of quite a lot of parameter-addition changes  
made in commit 0eea8047bf, which is a good thing IMO because this will  
reduce the code delta between 9.4 and 9.5, probably easing a few future  
back-patch efforts.  Moreover, the previous commit only added a DumpOptions  
argument to functions that had to have it at the time, which means we could  
anticipate still more code churn (and more back-patch hazard) as the  
requirement spread further.  I'd hit exactly that problem in my upcoming  
patch to fix extension membership marking, which is what motivated me to  
do this.  

M src/bin/pg_dump/common.c
M src/bin/pg_dump/parallel.c
M src/bin/pg_dump/parallel.h
M src/bin/pg_dump/pg_backup.h
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_archiver.h
M src/bin/pg_dump/pg_backup_custom.c
M src/bin/pg_dump/pg_backup_directory.c
M src/bin/pg_dump/pg_backup_null.c
M src/bin/pg_dump/pg_backup_tar.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/bin/pg_dump/pg_restore.c

Use LOAD not actual code execution to pull in plpython library.

commit   : 5ef26b8de3a12b0766334a19665d8b0f494a6af8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jan 2016 20:06:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jan 2016 20:06:36 -0500    

Click here for diff

Commit 866566a690bb9916 is insufficient to prevent dump/reload failures  
when using transform modules in a database with both plpython2 and  
plpython3 installed.  The reason is that the transform extension scripts  
use DO blocks as a mechanism to pull in the libpython library before  
creating the transform function.  It's necessary to preload the library  
because the dynamic loader won't do it for us on every platform, leading  
to "unresolved symbol" failures when the transform library is loaded.  
But it's *not* necessary to execute Python code, and doing so will  
provoke a multiple-Pythons-are-loaded error even after the preceding  
commit.  
  
To fix, use LOAD instead of a DO block.  That requires superuser privilege,  
but creation of a C function does anyway.  It also embeds knowledge of  
the underlying library name for each PL language; but that's wired into  
the initdb-time contents of pg_pltemplate too, so that doesn't seem like  
a large problem either.  Note that CREATE TRANSFORM as such doesn't call  
the language module at all.  
  
Per a report from Paul Jones.  Back-patch to 9.5 where transform modules  
were introduced.  

M contrib/hstore_plperl/hstore_plperl–1.0.sql
M contrib/hstore_plperl/hstore_plperlu–1.0.sql
M contrib/hstore_plpython/hstore_plpython2u–1.0.sql
M contrib/hstore_plpython/hstore_plpython3u–1.0.sql
M contrib/hstore_plpython/hstore_plpythonu–1.0.sql
M contrib/ltree_plpython/ltree_plpython2u–1.0.sql
M contrib/ltree_plpython/ltree_plpython3u–1.0.sql
M contrib/ltree_plpython/ltree_plpythonu–1.0.sql

Avoid dump/reload problems when using both plpython2 and plpython3.

commit   : db8fa56d6ad15621ad4f74667bfd59533408ce16    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jan 2016 19:55:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Jan 2016 19:55:39 -0500    

Click here for diff

Commit 803716013dc1350f installed a safeguard against loading plpython2  
and plpython3 at the same time, but asserted that both could still be  
used in the same database, just not in the same session.  However, that's  
not actually all that practical because dumping and reloading will fail  
(since both libraries necessarily get loaded into the restoring session).  
pg_upgrade is even worse, because it checks for missing libraries by  
loading every .so library mentioned in the entire installation into one  
session, so that you can have only one across the whole cluster.  
  
We can improve matters by not throwing the error immediately in _PG_init,  
but only when and if we're asked to do something that requires calling  
into libpython.  This ameliorates both of the above situations, since  
while execution of CREATE LANGUAGE, CREATE FUNCTION, etc will result in  
loading plpython, it isn't asked to do anything interesting (at least  
not if check_function_bodies is off, as it will be during a restore).  
  
It's possible that this opens some corner-case holes in which a crash  
could be provoked with sufficient effort.  However, since plpython  
only exists as an untrusted language, any such crash would require  
superuser privileges, making it "don't do that" not a security issue.  
To reduce the hazards in this area, the error is still FATAL when it  
does get thrown.  
  
Per a report from Paul Jones.  Back-patch to 9.2, which is as far back  
as the patch applies without work.  (It could be made to work in 9.1,  
but given the lack of previous complaints, I'm disinclined to expend  
effort so far back.  We've been pretty desultory about support for  
Python 3 in 9.1 anyway.)  

M src/pl/plpython/plpy_main.c

doc: Fix typo in logical decoding documentation

commit   : c43129e714dd20180d6e5868e8679398ab6c5d24    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 10 Jan 2016 20:12:27 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Sun, 10 Jan 2016 20:12:27 -0500    

Click here for diff

From: Petr Jelinek <petr@2ndquadrant.com>  

M doc/src/sgml/logicaldecoding.sgml

Remove a useless PG_GETARG_DATUM() call from jsonb_build_array.

commit   : 57da416933db2aee75485eff67b732063c978a48    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Jan 2016 17:39:45 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Jan 2016 17:39:45 -0500    

Click here for diff

This loop uselessly fetched the argument after the one it's currently  
looking at.  No real harm is done since we couldn't possibly fetch off  
the end of memory, but it's confusing to the reader.  
  
Also remove a duplicate (and therefore confusing) PG_ARGISNULL check in  
jsonb_build_object.  
  
I happened to notice these things while trolling for missed null-arg  
checks earlier today.  Back-patch to 9.5, not because there is any  
real bug, but just because 9.5 and HEAD are still in sync in this  
file and we might as well keep them so.  
  
In passing, re-pgindent.  

M src/backend/utils/adt/jsonb.c

Clean up some lack-of-STRICT issues in the core code, too.

commit   : aa7e04cb56373f2209d30c89cd41b20191f252f9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Jan 2016 16:58:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Jan 2016 16:58:32 -0500    

Click here for diff

A scan for missed proisstrict markings in the core code turned up  
these functions:  
  
brin_summarize_new_values  
pg_stat_reset_single_table_counters  
pg_stat_reset_single_function_counters  
pg_create_logical_replication_slot  
pg_create_physical_replication_slot  
pg_drop_replication_slot  
  
The first three of these take OID, so a null argument will normally look  
like a zero to them, resulting in "ERROR: could not open relation with OID  
0" for brin_summarize_new_values, and no action for the pg_stat_reset_XXX  
functions.  The other three will dump core on a null argument, though this  
is mitigated by the fact that they won't do so until after checking that  
the caller is superuser or has rolreplication privilege.  
  
In addition, the pg_logical_slot_get/peek[_binary]_changes family was  
intentionally marked nonstrict, but failed to make nullness checks on all  
the arguments; so again a null-pointer-dereference crash is possible but  
only for superusers and rolreplication users.  
  
Add the missing ARGISNULL checks to the latter functions, and mark the  
former functions as strict in pg_proc.  Make that change in the back  
branches too, even though we can't force initdb there, just so that  
installations initdb'd in future won't have the issue.  Since none of these  
bugs rise to the level of security issues (and indeed the pg_stat_reset_XXX  
functions hardly misbehave at all), it seems sufficient to do this.  
  
In addition, fix some order-of-operations oddities in the slot_get_changes  
family, mostly cosmetic, but not the part that moves the function's last  
few operations into the PG_TRY block.  As it stood, there was significant  
risk for an error to exit without clearing historical information from  
the system caches.  
  
The slot_get_changes bugs go back to 9.4 where that code was introduced.  
Back-patch appropriate subsets of the pg_proc changes into all active  
branches, as well.  

M src/backend/replication/logical/logicalfuncs.c
M src/include/catalog/pg_proc.h

Clean up code for widget_in() and widget_out().

commit   : 605afeca346e10aade853254d22ab89aa44ef467    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Jan 2016 13:44:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Jan 2016 13:44:27 -0500    

Click here for diff

Given syntactically wrong input, widget_in() could call atof() with an  
indeterminate pointer argument, typically leading to a crash; or if it  
didn't do that, it might return a NULL pointer, which again would lead  
to a crash since old-style C functions aren't supposed to do things  
that way.  Fix that by correcting the off-by-one syntax test and  
throwing a proper error rather than just returning NULL.  
  
Also, since widget_in and widget_out have been marked STRICT for a  
long time, their tests for null inputs are just dead code; remove 'em.  
In the oldest branches, also improve widget_out to use snprintf not  
sprintf, just to be sure.  
  
In passing, get rid of a long-since-useless sprintf into a local buffer  
that nothing further is done with, and make some other minor coding  
style cleanups.  
  
In the intended regression-testing usage of these functions, none of  
this is very significant; but if the regression test database were  
left around in a production installation, these bugs could amount  
to a minor security hazard.  
  
Piotr Stefaniak, Michael Paquier, and Tom Lane  

M src/test/regress/regress.c

Add STRICT to some C functions created by the regression tests.

commit   : 4e1ccc7e449aed32e63e53bc36e023f9259f2e09    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Jan 2016 13:02:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Jan 2016 13:02:54 -0500    

Click here for diff

These functions readily crash when passed a NULL input value.  The tests  
themselves do not pass NULL values to them; but when the regression  
database is used as a basis for fuzz testing, they cause a lot of noise.  
Also, if someone were to leave a regression database lying about in a  
production installation, these would create a minor security hazard.  
  
Andreas Seltenreich  

M src/test/regress/input/create_function_2.source
M src/test/regress/output/create_function_2.source

PL/Python: Make tests pass with Python 3.5

commit   : a66c1fcdd7e4291561c5cdebc1d02784050260e2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jan 2016 11:39:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 8 Jan 2016 11:39:28 -0500    

Click here for diff

The error message wording for AttributeError has changed in Python 3.5.  
For the plpython_error test, add a new expected file.  In the  
plpython_subtransaction test, we didn't really care what the exception  
is, only that it is something coming from Python.  So use a generic  
exception instead, which has a message that doesn't vary across  
versions.  
  
Back-patch of commit f16d52269a196f7f303abe3b978d95ade265f05f, which  
was previously back-patched into 9.2-9.4, but missed 9.5.  

M src/pl/plpython/expected/README
A src/pl/plpython/expected/plpython_error_5.out
M src/pl/plpython/expected/plpython_subtransaction.out
M src/pl/plpython/expected/plpython_subtransaction_0.out
M src/pl/plpython/expected/plpython_subtransaction_5.out
M src/pl/plpython/sql/plpython_subtransaction.sql

Fix typo in comment

commit   : 6a1a44037b63e1c0e51dd2ca7374191c2f5362b1    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Fri, 8 Jan 2016 08:56:03 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Fri, 8 Jan 2016 08:56:03 +0100    

Click here for diff

Tatsuro Yamada  

M src/include/port/atomics/arch-x86.h

Fix unobvious interaction between -X switch and subdirectory creation.

commit   : 506ef1d07f8b51e9799f6856b03a4317297a39cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jan 2016 18:20:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jan 2016 18:20:57 -0500    

Click here for diff

Turns out the only reason initdb -X worked is that pg_mkdir_p won't  
whine if you point it at something that's a symlink to a directory.  
Otherwise, the attempt to create pg_xlog/ just like all the other  
subdirectories would have failed.  Let's be a little more explicit  
about what's happening.  Oversight in my patch for bug #13853  
(mea culpa for not testing -X ...)  

M src/bin/initdb/initdb.c

Use plain mkdir() not pg_mkdir_p() to create subdirectories of PGDATA.

commit   : 32e7e7fa77bab73c9df8ea4bdb1fd65793451ff6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jan 2016 15:22:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Jan 2016 15:22:01 -0500    

Click here for diff

When we're creating subdirectories of PGDATA during initdb, we know darn  
well that the parent directory exists (or should exist) and that the new  
subdirectory doesn't (or shouldn't).  There is therefore no need to use  
anything more complicated than mkdir().  Using pg_mkdir_p() just opens us  
up to unexpected failure modes, such as the one exhibited in bug #13853  
from Nuri Boardman.  It's not very clear why pg_mkdir_p() went wrong there,  
but it is clear that we didn't need to be trying to create parent  
directories in the first place.  We're not even saving any code, as proven  
by the fact that this patch nets out at minus five lines.  
  
Since this is a response to a field bug report, back-patch to all branches.  

M src/bin/initdb/initdb.c

Windows: Make pg_ctl reliably detect service status

commit   : 744d01c9a188eef546dae6a4c3c4d0a19eb20a08    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 7 Jan 2016 11:59:08 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 7 Jan 2016 11:59:08 -0300    

Click here for diff

pg_ctl is using isatty() to verify whether the process is running in a  
terminal, and if not it sends its output to Windows' Event Log ... which  
does the wrong thing when the output has been redirected to a pipe, as  
reported in bug #13592.  
  
To fix, make pg_ctl use the code we already have to detect service-ness:  
in the master branch, move src/backend/port/win32/security.c to src/port  
(with suitable tweaks so that it runs properly in backend and frontend  
environments); pg_ctl already has access to pgport so it Just Works.  In  
older branches, that's likely to cause trouble, so instead duplicate the  
required code in pg_ctl.c.  
  
Author: Michael Paquier  
Bug report and diagnosis: Egon Kocjan  
Backpatch: all supported branches  

M src/bin/pg_ctl/pg_ctl.c

Fix typo in create_transform.sgml.

commit   : 9919f4fef1df2edf40e1a2a2971f97ff2d23cc3c    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Wed, 6 Jan 2016 08:01:40 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Wed, 6 Jan 2016 08:01:40 +0900    

Click here for diff

M doc/src/sgml/ref/create_transform.sgml

Sort $(wildcard) output where needed for reproducible build output.

commit   : 8805af0886c671adcaf0200d70549d5d933f5cf2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Jan 2016 15:47:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Jan 2016 15:47:05 -0500    

Click here for diff

The order of inclusion of .o files makes a difference in linker output;  
not a functional difference, but still a bitwise difference, which annoys  
some packagers who would like reproducible builds.  
  
Report and patch by Christoph Berg  

M contrib/hstore_plperl/Makefile
M contrib/hstore_plpython/Makefile
M contrib/ltree_plpython/Makefile
M src/bin/pg_xlogdump/Makefile

Make pg_receivexlog silent with 9.3 and older servers

commit   : 7ef311eb426b2ab01831cc5f1502a5b838c8cdd3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 5 Jan 2016 17:25:12 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 5 Jan 2016 17:25:12 -0300    

Click here for diff

A pointless and confusing error message is shown to the user when  
attempting to identify a 9.3 or older remote server with a 9.5/9.6  
pg_receivexlog, because the return signature of IDENTIFY_SYSTEM was  
changed in 9.4.  There's no good reason for the warning message, so  
shuffle code around to keep it quiet.  
  
(pg_recvlogical is also affected by this commit, but since it obviously  
cannot work with 9.3 that doesn't actually matter much.)  
  
Backpatch to 9.5.  
  
Reported by Marco Nenciarini, who also wrote the initial patch.  Further  
tweaked by Robert Haas and Fujii Masao; reviewed by Michael Paquier and  
Craig Ringer.  

M src/bin/pg_basebackup/streamutil.c

Add to_regnamespace() and to_regrole() to the documentation.

commit   : 41abf185024c2a7d36c09e30654efe3d939362b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Jan 2016 12:35:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Jan 2016 12:35:18 -0500    

Click here for diff

Commits cb9fa802b32b222b and 0c90f6769de6a60f added these functions,  
but did not bother with documentation.  

M doc/src/sgml/func.sgml