PostgreSQL 9.3.13 commit log

Stamp 9.3.13.

commit   : cd5a6521fa8e9d51090330eb500157079fda1381    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 9 May 2016 16:53:56 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 9 May 2016 16:53:56 -0400    

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   : b81b97794cc81780105024667766d2f2f63fc62e    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 9 May 2016 10:08:57 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 9 May 2016 10:08:57 -0400    

Click here for diff

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

M src/backend/po/fr.po
M src/backend/po/it.po
M src/backend/po/pt_BR.po
M src/bin/initdb/po/it.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/it.po
M src/bin/pg_controldata/po/de.po
M src/bin/pg_controldata/po/it.po
M src/bin/pg_ctl/po/it.po
M src/bin/pg_dump/po/it.po
M src/bin/pg_resetxlog/po/it.po
M src/bin/psql/po/de.po
M src/bin/psql/po/it.po
M src/bin/scripts/po/it.po
M src/interfaces/libpq/po/pt_BR.po
M src/pl/plperl/po/it.po
M src/pl/plpython/po/it.po
M src/pl/tcl/po/it.po

Release notes for 9.5.3, 9.4.8, 9.3.13, 9.2.17, 9.1.22.

commit   : 3f13193dd142a50b37641fcc311e40f13c60d290    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 7 May 2016 17:26:24 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 7 May 2016 17:26:24 -0400    

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

Distrust external OpenSSL clients; clear err queue

commit   : a9d8644de09e9b27ea9eb9148d2476b0d6c9eb90    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 8 Apr 2016 13:48:14 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 8 Apr 2016 13:48:14 -0400    

Click here for diff

OpenSSL has an unfortunate tendency to mix per-session state error  
handling with per-thread error handling.  This can cause problems when  
programs that link to libpq with OpenSSL enabled have some other use of  
OpenSSL; without care, one caller of OpenSSL may cause problems for the  
other caller.  Backend code might similarly be affected, for example  
when a third party extension independently uses OpenSSL without taking  
the appropriate precautions.  
  
To fix, don't trust other users of OpenSSL to clear the per-thread error  
queue.  Instead, clear the entire per-thread queue ahead of certain I/O  
operations when it appears that there might be trouble (these I/O  
operations mostly need to call SSL_get_error() to check for success,  
which relies on the queue being empty).  This is slightly aggressive,  
but it's pretty clear that the other callers have a very dubious claim  
to ownership of the per-thread queue.  Do this is both frontend and  
backend code.  
  
Finally, be more careful about clearing our own error queue, so as to  
not cause these problems ourself.  It's possibly that control previously  
did not always reach SSLerrmessage(), where ERR_get_error() was supposed  
to be called to clear the queue's earliest code.  Make sure  
ERR_get_error() is always called, so as to spare other users of OpenSSL  
the possibility of similar problems caused by libpq (as opposed to  
problems caused by a third party OpenSSL library like PHP's OpenSSL  
extension).  Again, do this is both frontend and backend code.  
  
See bug #12799 and https://bugs.php.net/bug.php?id=68276  
  
Based on patches by Dave Vitek and Peter Eisentraut.  
  
From: Peter Geoghegan <[email protected]>  

M src/backend/libpq/be-secure.c
M src/interfaces/libpq/fe-secure.c

Fix pg_upgrade to not fail when new-cluster TOAST rules differ from old.

commit   : e1d88f983e4037f209d6274acfe0c20e6cb42472    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 May 2016 22:05:51 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 May 2016 22:05:51 -0400    

Click here for diff

This patch essentially reverts commit 4c6780fd17aa43ed, in favor of a much  
simpler solution for the case where the new cluster would choose to create  
a TOAST table but the old cluster doesn't have one: just don't create a  
TOAST table.  
  
The existing code failed in at least two different ways if the situation  
arose: (1) ALTER TABLE RESET didn't grab an exclusive lock, so that the  
lock sanity check in create_toast_table failed; (2) pg_upgrade did not  
provide a pg_type OID for the new toast table, so that the crosscheck in  
TypeCreate failed.  While both these problems were introduced by later  
patches, they show that the hack being used to cause TOAST table creation  
is overwhelmingly fragile (and untested).  I also note that before the  
TypeCreate crosscheck was added, the code would have resulted in assigning  
an indeterminate pg_type OID to the toast table, possibly causing a later  
OID conflict in that catalog; so that it didn't really work even when  
committed.  
  
If we simply don't create a TOAST table, there will only be a problem if  
the code tries to store a tuple that's wider than a page, and field  
compression isn't sufficient to get it under a page.  Given that the TOAST  
creation threshold is intended to be about a quarter of a page, it's very  
hard to believe that cross-version differences in the do-we-need-a-toast-  
table heuristic could result in an observable problem.  So let's just  
follow the old version's conclusion about whether a TOAST table is needed.  
  
(If we ever do change needs_toast_table() so much that this conclusion  
doesn't apply, we can devise a solution at that time, and hopefully do  
it in a less klugy way than 4c6780fd17aa43ed did.)  
  
Back-patch to 9.3, like the previous patch.  
  
Discussion: <[email protected]>  

M contrib/pg_upgrade/dump.c
M contrib/pg_upgrade/pg_upgrade.c
M contrib/pg_upgrade/pg_upgrade.h
M src/backend/catalog/toasting.c

Fix possible read past end of string in to_timestamp().

commit   : 462456d8d08339cbceb0cd3dad32bdddb0531ba5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 6 May 2016 12:09:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 6 May 2016 12:09:20 -0400    

Click here for diff

to_timestamp() handles the TH/th format codes by advancing over two input  
characters, whatever those are.  It failed to notice whether there were  
two characters available to be skipped, making it possible to advance  
the pointer past the end of the input string and keep on parsing.  
A similar risk existed in the handling of "Y,YYY" format: it would advance  
over three characters after the "," whether or not three characters were  
available.  
  
In principle this might be exploitable to disclose contents of server  
memory.  But the security team concluded that it would be very hard to use  
that way, because the parsing loop would stop upon hitting any zero byte,  
and TH/th format codes can't be consecutive --- they have to follow some  
other format code, which would have to match whatever data is there.  
So it seems impractical to examine memory very much beyond the end of the  
input string via this bug; and the input string will always be in local  
memory not in disk buffers, making it unlikely that anything very  
interesting is close to it in a predictable way.  So this doesn't quite  
rise to the level of needing a CVE.  
  
Thanks to Wolf Roediger for reporting this bug.  

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

Update time zone data files to tzdata release 2016d.

commit   : d30c67af801dd4d380657d24a3211cfd4e0c4823    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 5 May 2016 20:08:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 5 May 2016 20:08:58 -0400    

Click here for diff

DST law changes in Russia (Magadan, Tomsk regions) and Venezuela.  
Historical corrections for Russia.  There are new zone names Europe/Kirov  
and Asia/Tomsk reflecting the fact that these regions now have different  
time zone histories from adjacent regions.  

M src/timezone/data/asia
M src/timezone/data/europe
M src/timezone/data/northamerica
M src/timezone/data/southamerica
M src/timezone/data/zone.tab
M src/timezone/data/zone1970.tab
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Default

doc: Fix more typos

commit   : 74324092a41707413ee529a789d53c166a0e2543    
  
author   : Peter Eisentraut <[email protected]>    
date     : Wed, 4 May 2016 14:07:00 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Wed, 4 May 2016 14:07:00 -0400    

Click here for diff

From: Alexander Law <[email protected]>  

M doc/src/sgml/ecpg.sgml
M doc/src/sgml/pg_xlogdump.sgml

doc: Fix typos

commit   : e0e023b2e7763729b88c2f80f288141d0de99938    
  
author   : Peter Eisentraut <[email protected]>    
date     : Tue, 3 May 2016 21:06:25 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Tue, 3 May 2016 21:06:25 -0400    

Click here for diff

From: Alexander Law <[email protected]>  

M doc/src/sgml/ecpg.sgml
M doc/src/sgml/protocol.sgml

Fix configure's incorrect version tests for flex and perl.

commit   : 6c2e2b341ae659079810a75fec9f93c1a8a2dd16    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 May 2016 11:18:11 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 May 2016 11:18:11 -0400    

Click here for diff

awk's equality-comparison operator is "==" not "=".  We got this right  
in many places, but not in configure's checks for supported version  
numbers of flex and perl.  It hadn't been noticed because unsupported  
versions are so old as to be basically extinct in the wild, and because  
the only consequence is whether or not a WARNING flies by during  
configure.  
  
Daniel Gustafsson noted the problem with respect to the test for flex,  
I found the other by reviewing other awk calls.  

M config/perl.m4
M config/programs.m4
M configure

Remove unused macros.

commit   : 586d75ace4fd5ff1680606b105a4df552d354bd4    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Mon, 2 May 2016 10:07:49 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Mon, 2 May 2016 10:07:49 +0300    

Click here for diff

CHECK_PAGE_OFFSET_RANGE() has been unused forever.  
CHECK_RELATION_BLOCK_RANGE() has been unused in pgstatindex.c ever since  
bt_page_stats() and bt_page_items() functions were moved from pgstattuple  
to pageinspect module. It still exists in pageinspect/btreefuncs.c.  
  
Daniel Gustafsson  

M contrib/pageinspect/btreefuncs.c
M contrib/pgstattuple/pgstatindex.c

Fix mishandling of equivalence-class tests in parameterized plans.

commit   : 67349e5a844728d11e59e54cfedac1d3592e429c    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 29 Apr 2016 20:19:38 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 29 Apr 2016 20:19:38 -0400    

Click here for diff

Given a three-or-more-way equivalence class, such as X.Y = Y.Y = Z.Z,  
it was possible for the planner to omit one of the quals needed to  
enforce that all members of the equivalence class are actually equal.  
This only happened in the case of a parameterized join node for two  
of the relations, that is a plan tree like  
  
	Nested Loop  
	  ->  Scan X  
	  ->  Nested Loop  
	    ->  Scan Y  
	    ->  Scan Z  
	          Filter: Z.Z = X.X  
  
The eclass machinery normally expects to apply X.X = Y.Y when those  
two relations are joined, but in this shape of plan tree they aren't  
joined until the top node --- and, if the lower nested loop is marked  
as parameterized by X, the top node will assume that the relevant eclass  
condition(s) got pushed down into the lower node.  On the other hand,  
the scan of Z assumes that it's only responsible for constraining Z.Z  
to match any one of the other eclass members.  So one or another of  
the required quals sometimes fell between the cracks, depending on  
whether consideration of the eclass in get_joinrel_parampathinfo()  
for the lower nested loop chanced to generate X.X = Y.Y or X.X = Z.Z  
as the appropriate constraint there.  If it generated the latter,  
it'd erroneously suppose that the Z scan would take care of matters.  
To fix, force X.X = Y.Y to be generated and applied at that join node  
when this case occurs.  
  
This is *extremely* hard to hit in practice, because various planner  
behaviors conspire to mask the problem; starting with the fact that the  
planner doesn't really like to generate a parameterized plan of the  
above shape.  (It might have been impossible to hit it before we  
tweaked things to allow this plan shape for star-schema cases.)  Many  
thanks to Alexander Kirkouski for submitting a reproducible test case.  
  
The bug can be demonstrated in all branches back to 9.2 where parameterized  
paths were introduced, so back-patch that far.  

M src/backend/optimizer/path/equivclass.c
M src/backend/optimizer/util/relnode.c
M src/include/optimizer/paths.h
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql

Adjust DatumGetBool macro, this time for sure.

commit   : 707c44fe257bc2a7be8acd2d9a072a83e21a60e3    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 28 Apr 2016 11:50:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 28 Apr 2016 11:50:58 -0400    

Click here for diff

Commit 23a41573c attempted to fix the DatumGetBool macro to ignore bits  
in a Datum that are to the left of the actual bool value.  But it did that  
by casting the Datum to bool; and on compilers that use C99 semantics for  
bool, that ends up being a whole-word test, not a 1-byte test.  This seems  
to be the true explanation for contrib/seg failing in VS2015.  To fix, use  
GET_1_BYTE() explicitly.  I think in the previous patch, I'd had some idea  
of not having to commit to bool being exactly 1 byte wide, but regardless  
of what the compiler's bool is, boolean columns and Datums are certainly  
1 byte wide.  
  
The previous fix was (eventually) back-patched into all active versions,  
so do likewise with this one.  

M src/include/postgres.h

pg_upgrade: Fix indentation of if() block

commit   : 4f29edbb1603c552eade920ded85c0c6794a9063    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 28 Apr 2016 08:29:02 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 28 Apr 2016 08:29:02 -0400    

Click here for diff

Incorrect indentation introduced in commit  
3d2e1851096752c3ca4dee5c16b552332de09946.  
  
Reported-by: Andres Freund  
  
Backpatch-through: 9.3 and 9.4 only  

M src/bin/pg_dump/pg_dump.c

Rename strtoi() to strtoint().

commit   : 252c3589536e409a1270eb70f7f301ce14cf7ea1    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 23 Apr 2016 16:53:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 23 Apr 2016 16:53:15 -0400    

Click here for diff

NetBSD has seen fit to invent a libc function named strtoi(), which  
conflicts with the long-established static functions of the same name in  
datetime.c and ecpg's interval.c.  While muttering darkly about intrusions  
on application namespace, we'll rename our functions to avoid the conflict.  
  
Back-patch to all supported branches, since this would affect attempts  
to build any of them on recent NetBSD.  
  
Thomas Munro  

M src/backend/utils/adt/datetime.c
M src/interfaces/ecpg/pgtypeslib/interval.c

doc: Fix typos

commit   : 23da66f0005ace958c10de03e1ce20217fc5999f    
  
author   : Peter Eisentraut <[email protected]>    
date     : Sat, 23 Apr 2016 14:48:02 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Sat, 23 Apr 2016 14:48:02 -0400    

Click here for diff

From: Erik Rijkers <[email protected]>  

M doc/src/sgml/pgbench.sgml

Add putenv support for msvcrt from Visual Studio 2013

commit   : ab5c6d01f6dbe036469fd77b488a21ca8d7d26f1    
  
author   : Magnus Hagander <[email protected]>    
date     : Fri, 22 Apr 2016 05:18:59 -0400    
  
committer: Magnus Hagander <[email protected]>    
date     : Fri, 22 Apr 2016 05:18:59 -0400    

Click here for diff

This was missed when VS 2013 support was added.  
  
Michael Paquier  

M src/port/win32env.c

Fix planner failure with full join in RHS of left join.

commit   : d9742ac4636ec847f9fd54c9d690da7402319063    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 20:05:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 20:05:58 -0400    

Click here for diff

Given a left join containing a full join in its righthand side, with  
the left join's joinclause referencing only one side of the full join  
(in a non-strict fashion, so that the full join doesn't get simplified),  
the planner could fail with "failed to build any N-way joins" or related  
errors.  This happened because the full join was seen as overlapping the  
left join's RHS, and then recent changes within join_is_legal() caused  
that function to conclude that the full join couldn't validly be formed.  
Rather than try to rejigger join_is_legal() yet more to allow this,  
I think it's better to fix initsplan.c so that the required join order  
is explicit in the SpecialJoinInfo data structure.  The previous coding  
there essentially ignored full joins, relying on the fact that we don't  
flatten them in the joinlist data structure to preserve their ordering.  
That's sufficient to prevent a wrong plan from being formed, but as this  
example shows, it's not sufficient to ensure that the right plan will  
be formed.  We need to work a bit harder to ensure that the right plan  
looks sane according to the SpecialJoinInfos.  
  
Per bug #14105 from Vojtech Rylko.  This was apparently induced by  
commit 8703059c6 (though now that I've seen it, I wonder whether there  
are related cases that could have failed before that); so back-patch  
to all active branches.  Unfortunately, that patch also went into 9.0,  
so this bug is a regression that won't be fixed in that branch.  

M src/backend/optimizer/plan/initsplan.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql

Improve TranslateSocketError() to handle more Windows error codes.

commit   : 82bf369ed6eac67c7a6138591bd38136daad7223    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 16:58:47 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 16:58:47 -0400    

Click here for diff

The coverage was rather lean for cases that bind() or listen() might  
return.  Add entries for everything that there's a direct equivalent  
for in the set of Unix errnos that elog.c has heard of.  

M src/backend/port/win32/socket.c
M src/include/port/win32.h

Remove dead code in win32.h.

commit   : 87351503a0f62993be62d1faf9419d4ed222c514    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 16:16:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 16:16:19 -0400    

Click here for diff

There's no longer a need for the MSVC-version-specific code stanza that  
forcibly redefines errno code symbols, because since commit 73838b52 we're  
unconditionally redefining them in the stanza before this one anyway.  
Now it's merely confusing and ugly, so get rid of it; and improve the  
comment that explains what's going on here.  
  
Although this is just cosmetic, back-patch anyway since I'm intending  
to back-patch some less-cosmetic changes in this same hunk of code.  

M src/include/port/win32.h

Provide errno-translation wrappers around bind() and listen() on Windows.

commit   : 8f9518414baccac15bb028312f8db3b98e527c5c    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 15:44:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 15:44:18 -0400    

Click here for diff

Fix Windows builds to report something useful rather than "could not bind  
IPv4 socket: No error" when bind() fails.  
  
Back-patch of commits d1b7d4877b9a71f4 and 22989a8e34168f57.  
  
Discussion: <[email protected]>  

M src/backend/port/win32/socket.c
M src/include/port/win32.h

Fix ruleutils.c's dumping of ScalarArrayOpExpr containing an EXPR_SUBLINK.

commit   : e5882f26b38c6510a22263566548060a3153cc09    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 14:20:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 21 Apr 2016 14:20:18 -0400    

Click here for diff

When we shoehorned "x op ANY (array)" into the SQL syntax, we created a  
fundamental ambiguity as to the proper treatment of a sub-SELECT on the  
righthand side: perhaps what's meant is to compare x against each row of  
the sub-SELECT's result, or perhaps the sub-SELECT is meant as a scalar  
sub-SELECT that delivers a single array value whose members should be  
compared against x.  The grammar resolves it as the former case whenever  
the RHS is a select_with_parens, making the latter case hard to reach ---  
but you can get at it, with tricks such as attaching a no-op cast to the  
sub-SELECT.  Parse analysis would throw away the no-op cast, leaving a  
parsetree with an EXPR_SUBLINK SubLink directly under a ScalarArrayOpExpr.  
ruleutils.c was not clued in on this fine point, and would naively emit  
"x op ANY ((SELECT ...))", which would be parsed as the first alternative,  
typically leading to errors like "operator does not exist: text = text[]"  
during dump/reload of a view or rule containing such a construct.  To fix,  
emit a no-op cast when dumping such a parsetree.  This might well be  
exactly what the user wrote to get the construct accepted in the first  
place; and even if she got there with some other dodge, it is a valid  
representation of the parsetree.  
  
Per report from Karl Czajkowski.  He mentioned only a case involving  
RLS policies, but actually the problem is very old, so back-patch to  
all supported branches.  
  
Report: <[email protected]>  

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

Honor PGCTLTIMEOUT environment variable for pg_regress' startup wait.

commit   : 691073bd8d59daedde3d0183f18a99363a557fd3    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 20 Apr 2016 23:48:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 20 Apr 2016 23:48:13 -0400    

Click here for diff

In commit 2ffa86962077c588 we made pg_ctl recognize an environment variable  
PGCTLTIMEOUT to set the default timeout for starting and stopping the  
postmaster.  However, pg_regress uses pg_ctl only for the "stop" end of  
that; it has bespoke code for starting the postmaster, and that code has  
historically had a hard-wired 60-second timeout.  Further buildfarm  
experience says it'd be a good idea if that timeout were also controlled  
by PGCTLTIMEOUT, so let's make it so.  Like the previous patch, back-patch  
to all active branches.  
  
Discussion: <[email protected]>  

M src/test/regress/pg_regress.c

Further reduce the number of semaphores used under --disable-spinlocks.

commit   : 6ec1ff852f0ab13973979df311b0ac2be9e207b1    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 18 Apr 2016 13:33:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 18 Apr 2016 13:33:07 -0400    

Click here for diff

Per discussion, there doesn't seem to be much value in having  
NUM_SPINLOCK_SEMAPHORES set to 1024: under any scenario where you are  
running more than a few backends concurrently, you really had better have a  
real spinlock implementation if you want tolerable performance.  And 1024  
semaphores is a sizable fraction of the system-wide SysV semaphore limit  
on many platforms.  Therefore, reduce this setting's default value to 128  
to make it less likely to cause out-of-semaphores problems.  

M src/include/pg_config_manual.h

Fix --disable-spinlocks in 9.2 and 9.3 branches.

commit   : 35166fd7614ed4f03e31f7ce1227c70103de22c9    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 18 Apr 2016 13:19:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 18 Apr 2016 13:19:52 -0400    

Click here for diff

My back-patch of the 9.4-era commit 44cd47c1d49655c5 into 9.2 and 9.3 fixed  
HPPA builds as expected, but it broke --disable-spinlocks builds, because  
the dummy spinlock is initialized before the underlying semaphore  
infrastructure is alive.  In 9.4 and up this works because of commit  
daa7527afc227443, which decoupled initialization of an slock_t variable  
from access to the actual system semaphore object.  The best solution  
seems to be to back-port that patch, which should be a net win anyway  
because it improves the usability of --disable-spinlocks builds in the  
older branches; and it's been out long enough now to not be worrisome  
from a stability perspective.  

M src/backend/postmaster/postmaster.c
M src/backend/storage/ipc/ipci.c
M src/backend/storage/ipc/shmem.c
M src/backend/storage/lmgr/spin.c
M src/include/pg_config_manual.h
M src/include/storage/s_lock.h
M src/include/storage/spin.h

Fix missing "static".

commit   : 0a32768c1059bffd32621dba5f19528c946c7d6f    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 16 Apr 2016 14:50:54 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 16 Apr 2016 14:50:54 -0400    

Click here for diff

Per buildfarm member pademelon.  

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

Make fallback implementation of pg_memory_barrier() work in 9.2 and 9.3.

commit   : 992df96580c544dc3f72b38d8e0a946f2b462749    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 16 Apr 2016 10:42:07 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 16 Apr 2016 10:42:07 -0400    

Click here for diff

Back-patch 9.4-era commit 44cd47c1d49655c5 into 9.2 and 9.3.  As with  
my back-patches of yesterday, this was not seen as necessary at the time  
because we didn't expect barrier.h to need to work before 9.4, but  
commit 37de8de9e33606a0 invalidated that theory.  
  
Per an attempt to run gaur and pademelon over old branches they've  
not been run on since ~2013.  

M src/backend/main/main.c

doc: Add missing parentheses

commit   : 9b2dc0884d723bad744bc55190da2ad96d920a6d    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 15 Apr 2016 20:44:10 -0400    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 15 Apr 2016 20:44:10 -0400    

Click here for diff

From: Alexander Law <[email protected]>  

M doc/src/sgml/ecpg.sgml

Sync 9.2 and 9.3 versions of barrier.h with 9.4's version.

commit   : f4f4f6990e9f3aa75b609b986e594b6951d04927    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 15 Apr 2016 16:49:48 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 15 Apr 2016 16:49:48 -0400    

Click here for diff

We weren't particularly maintaining barrier.h before 9.4, because nothing  
was using it in those branches.  Well, nothing until commit 37de8de9e got  
back-patched.  That broke 9.2 and 9.3 for some non-mainstream platforms  
that we haven't been testing in the buildfarm, including icc on ia64,  
HPPA, and Alpha.  
  
This commit effectively back-patches commits e5592c61a, 89779bf2c,  
and 747ca6697, though I did it just by copying the file (less copyright  
date updates) rather than by cherry-picking those commits.  
  
Per an attempt to run gaur and pademelon over old branches they've  
not been run on since ~2013.  

M src/include/storage/barrier.h

Fix non-C89-compliant initialization of array in parallel.c.

commit   : 6e53bb4fdca945d0867e11551bab019c555ecf26    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 14 Apr 2016 19:22:50 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 14 Apr 2016 19:22:50 -0700    

Click here for diff

In newer branches this was already fixed in 59202fae04. Found using  
clang's -Wc99-extensions.  

M src/bin/pg_dump/parallel.c

Remove trailing commas in enums.

commit   : f1d26d3e0a7f0e1928cfb672c6c56fc342174a58    
  
author   : Andres Freund <[email protected]>    
date     : Thu, 14 Apr 2016 18:54:06 -0700    
  
committer: Andres Freund <[email protected]>    
date     : Thu, 14 Apr 2016 18:54:06 -0700    

Click here for diff

These aren't valid C89. Found thanks to gcc's -Wc90-c99-compat. These  
exist in differing places in most supported branches.  

M src/backend/access/transam/xlog.c
M src/include/catalog/objectaccess.h
M src/include/pgstat.h
M src/include/utils/jsonapi.h

Fix pg_dump so pg_upgrade'ing an extension with simple opfamilies works.

commit   : 34bf6bc56cc8ad201dbba3e82d73e9f52fb57809    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 13 Apr 2016 18:57:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 13 Apr 2016 18:57:52 -0400    

Click here for diff

As reported by Michael Feld, pg_upgrade'ing an installation having  
extensions with operator families that contain just a single operator class  
failed to reproduce the extension membership of those operator families.  
This caused no immediate ill effects, but would create problems when later  
trying to do a plain dump and restore, because the seemingly-not-part-of-  
the-extension operator families would appear separately in the pg_dump  
output, and then would conflict with the families created by loading the  
extension.  This has been broken ever since extensions were introduced,  
and many of the standard contrib extensions are affected, so it's a bit  
astonishing nobody complained before.  
  
The cause of the problem is a perhaps-ill-considered decision to omit  
such operator families from pg_dump's output on the grounds that the  
CREATE OPERATOR CLASS commands could recreate them, and having explicit  
CREATE OPERATOR FAMILY commands would impede loading the dump script into  
pre-8.3 servers.  Whatever the merits of that decision when 8.3 was being  
written, it looks like a poor tradeoff now.  We can fix the pg_upgrade  
problem simply by removing that code, so that the operator families are  
dumped explicitly (and then will be properly made to be part of their  
extensions).  
  
Although this fixes the behavior of future pg_upgrade runs, it does nothing  
to clean up existing installations that may have improperly-linked operator  
families.  Given the small number of complaints to date, maybe we don't  
need to worry about providing an automated solution for that; anyone who  
needs to clean it up can do so with manual "ALTER EXTENSION ADD OPERATOR  
FAMILY" commands, or even just ignore the duplicate-opfamily errors they  
get during a pg_restore.  In any case we need this fix.  
  
Back-patch to all supported branches.  
  
Discussion: <[email protected]>  

M src/bin/pg_dump/pg_dump.c

Fix freshly-introduced PL/Python portability bug.

commit   : f6b81162c5fc83f51921d8184bad5248c5eb1144    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Apr 2016 18:17:02 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Apr 2016 18:17:02 -0400    

Click here for diff

It turns out that those PyErr_Clear() calls I removed from plpy_elog.c  
in 7e3bb080387f4143 et al were not quite as random as they appeared: they  
mask a Python 2.3.x bug.  (Specifically, it turns out that PyType_Ready()  
can fail if the error indicator is set on entry, and PLy_traceback's fetch  
of frame.f_code may be the first operation in a session that requires the  
"frame" type to be readied.  Ick.)  Put back the clear call, but in a more  
centralized place closer to what it's protecting, and this time with a  
comment warning what it's really for.  
  
Per buildfarm member prairiedog.  Although prairiedog was only failing  
on HEAD, it seems clearly possible for this to occur in older branches  
as well, so back-patch to 9.2 the same as the previous patch.  

M src/pl/plpython/plpy_elog.c

Fix access-to-already-freed-memory issue in plpython's error handling.

commit   : 8d82e6e28e22edf8082810dbba137c7f400af7b8    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 10 Apr 2016 23:15:55 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 10 Apr 2016 23:15:55 -0400    

Click here for diff

PLy_elog() could attempt to access strings that Python had already freed,  
because the strings that PLy_get_spi_error_data() returns are simply  
pointers into storage associated with the error "val" PyObject.  That's  
fine at the instant PLy_get_spi_error_data() returns them, but just after  
that PLy_traceback() intentionally releases the only refcount on that  
object, allowing it to be freed --- so that the strings we pass to  
ereport() are dangling pointers.  
  
In principle this could result in garbage output or a coredump.  In  
practice, I think the risk is pretty low, because there are no Python  
operations between where we decrement that refcount and where we use the  
strings (and copy them into PG storage), and thus no reason for Python  
to recycle the storage.  Still, it's clearly hazardous, and it leads to  
Valgrind complaints when running under a Valgrind that hasn't been  
lobotomized to ignore Python memory allocations.  
  
The code was a mess anyway: we fetched the error data out of Python  
(clearing Python's error indicator) with PyErr_Fetch, examined it, pushed  
it back into Python with PyErr_Restore (re-setting the error indicator),  
then immediately pulled it back out with another PyErr_Fetch.  Just to  
confuse matters even more, there were some gratuitous-and-yet-hazardous  
PyErr_Clear calls in the "examine" step, and we didn't get around to doing  
PyErr_NormalizeException until after the second PyErr_Fetch, making it even  
less clear which object was being manipulated where and whether we still  
had a refcount on it.  (If PyErr_NormalizeException did substitute a  
different "val" object, it's possible that the problem could manifest for  
real, because then we'd be doing assorted Python stuff with no refcount  
on the object we have string pointers into.)  
  
So, rearrange all that into some semblance of sanity, and don't decrement  
the refcount on the Python error objects until the end of PLy_elog().  
In HEAD, I failed to resist the temptation to reformat some messy bits  
from 5c3c3cd0a3046339 along the way.  
  
Back-patch as far as 9.2, because the code is substantially the same  
that far back.  I believe that 9.1 has the bug as well; but the code  
around it is rather different and I don't want to take a chance on  
breaking something for what seems a low-probability problem.  

M src/pl/plpython/plpy_elog.c

Fix possible use of uninitialised value in ts_headline()

commit   : 9d3fb209a07656fdee6f190013ecfcd1c590bedb    
  
author   : Teodor Sigaev <[email protected]>    
date     : Fri, 8 Apr 2016 21:25:59 +0300    
  
committer: Teodor Sigaev <[email protected]>    
date     : Fri, 8 Apr 2016 21:25:59 +0300    

Click here for diff

Found during investigation of failure of skink buildfarm member and its  
valgrind report.  
  
Backpatch to all supported branches  

M src/backend/tsearch/wparser_def.c

Turn down MSVC compiler verbosity

commit   : ca5d6edbfe6bb060e815ef0195ed67c05842bede    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 8 Apr 2016 12:25:10 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 8 Apr 2016 12:25:10 -0400    

Click here for diff

Most of what is produced by the detailed verbosity level is of no  
interest at all, so switch to the normal level for more usable output.  
  
Christian Ullrich  
  
Backpatch to all live branches  

M src/tools/msvc/build.pl

Fix broken ALTER INDEX documentation

commit   : fa4eab862b064ded953dfd95218cf99efddf6a90    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 5 Apr 2016 19:03:42 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 5 Apr 2016 19:03:42 -0300    

Click here for diff

Commit b8a91d9d1c put the description of the new IF EXISTS clause in the  
wrong place -- move it where it belongs.  
  
Backpatch to 9.2.  

M doc/src/sgml/ref/alter_index.sgml

Fix latent portability issue in pgwin32_dispatch_queued_signals().

commit   : 43b73d1a40463ff1fe7dee4d61a46a158629ab2b    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Apr 2016 11:13:17 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Apr 2016 11:13:17 -0400    

Click here for diff

The first iteration of the signal-checking loop would compute sigmask(0)  
which expands to 1<<(-1) which is undefined behavior according to the  
C standard.  The lack of field reports of trouble suggest that it  
evaluates to 0 on all existing Windows compilers, but that's hardly  
something to rely on.  Since signal 0 isn't a queueable signal anyway,  
we can just make the loop iterate from 1 instead, and save a few cycles  
as well as avoiding the undefined behavior.  
  
In passing, avoid evaluating the volatile expression UNBLOCKED_SIGNAL_QUEUE  
twice in a row; there's no reason to waste cycles like that.  
  
Noted by Aleksander Alekseev, though this isn't his proposed fix.  
Back-patch to all supported branches.  

M src/backend/port/win32/signal.c

Remove TZ environment-variable entry from postgres reference page.

commit   : cbf4f6bb34fc77f6698ff036e16e0739357cedd0    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Mar 2016 21:38:15 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Mar 2016 21:38:15 -0400    

Click here for diff

The server hasn't paid attention to the TZ environment variable since  
commit ca4af308c32d03db, but that commit missed removing this documentation  
reference, as did commit d883b916a947a3c6 which added the reference where  
it now belongs (initdb).  
  
Back-patch to 9.2 where the behavior changed.  Also back-patch  
d883b916a947a3c6 as needed.  
  
Matthew Somerville  

M doc/src/sgml/ref/initdb.sgml
M doc/src/sgml/ref/postgres-ref.sgml

Avoid possibly-unsafe use of Windows' FormatMessage() function.

commit   : 11cc7bb8825efc74c9418f6e88d448cc253c47b0    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 29 Mar 2016 11:54:57 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 29 Mar 2016 11:54:57 -0400    

Click here for diff

Whenever this function is used with the FORMAT_MESSAGE_FROM_SYSTEM flag,  
it's good practice to include FORMAT_MESSAGE_IGNORE_INSERTS as well.  
Otherwise, if the message contains any %n insertion markers, the function  
will try to fetch argument strings to substitute --- which we are not  
passing, possibly leading to a crash.  This is exactly analogous to the  
rule about not giving printf() a format string you're not in control of.  
  
Noted and patched by Christian Ullrich.  
Back-patch to all supported branches.  

M src/backend/libpq/auth.c
M src/backend/port/win32/socket.c
M src/interfaces/libpq/fe-auth.c
M src/port/dirmod.c