PostgreSQL 9.1.22 commit log

commit   : ddb0843d44a53518cfbbb5c2fd535021d75d07cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 May 2016 16:57:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 May 2016 16:57:25 -0400    

commit   : e712933c80a15719293f0c55eeb02e0aae401820    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 9 May 2016 10:10:35 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Mon, 9 May 2016 10:10:35 -0400    

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

commit   : be13ee5ab0fe2ef0addce61089d052d0a1658e24    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 May 2016 17:26:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 May 2016 17:26:24 -0400    

commit   : 9b676fd49a34e1e4001f19331e9cb4a8d688bb06    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Apr 2016 13:48:14 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 8 Apr 2016 13:48:14 -0400    

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 <pg@bowt.ie>  

commit   : 7bad282c34d967be71f52b8812834beb060a68da    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 12:09:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 May 2016 12:09:20 -0400    

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.  

commit   : bfc39da640310b81d81cc7a03bc778d959624a1f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 20:08:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 May 2016 20:08:58 -0400    

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.  

commit   : b94906f2d3222d56bf0935be565c2a94a84e858f    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 4 May 2016 14:07:00 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Wed, 4 May 2016 14:07:00 -0400    

From: Alexander Law <exclusion@gmail.com>  

commit   : acf913480e2869949d9113444ff3073eab243855    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 3 May 2016 21:06:25 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Tue, 3 May 2016 21:06:25 -0400    

From: Alexander Law <exclusion@gmail.com>  

commit   : 6e3702e627b04b5a9c7fe2167b6d1fe1a57f0920    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 May 2016 11:18:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 May 2016 11:18:11 -0400    

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.  

commit   : c2c19afc82fb6a2fb97ed3479135a2e89e3c72e0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 2 May 2016 10:07:49 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 2 May 2016 10:07:49 +0300    

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  

commit   : a6c6789c46843988f8eef4afc462311f41bd6e27    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Apr 2016 11:50:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 28 Apr 2016 11:50:58 -0400    

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.  

commit   : cbff4b7085d779759e0e287ec3534d3da9ce72ab    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Apr 2016 16:53:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Apr 2016 16:53:15 -0400    

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  

commit   : 6882dbd342d197e5f0bcc59059005780bc5c49a9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 20:05:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 20:05:58 -0400    

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.  

commit   : 9028f404ef9605b585c176f7b0924069884cabfe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 16:58:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 16:58:47 -0400    

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.  

commit   : 5b13ad976a0143fbed15612db8962faa33e8d979    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 16:16:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 16:16:19 -0400    

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.  

commit   : b2bb59bd51849d4eec777171f6e402581e00d654    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 15:44:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 15:44:18 -0400    

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: <4065.1452450340@sss.pgh.pa.us>  

commit   : 663624e60bd679ef7d4abeca1e68aceb5f2f5bbe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 14:20:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Apr 2016 14:20:18 -0400    

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: <20160421001832.GB7976@moraine.isi.edu>  

commit   : 4c1c9f80b769120f2e809aa6447383c95c7705cf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Apr 2016 23:48:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Apr 2016 23:48:13 -0400    

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: <13969.1461191936@sss.pgh.pa.us>  

commit   : f719cd9bfbcf98ce9423b5c01184cf3bc627bbd7    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 15 Apr 2016 20:44:10 -0400    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 15 Apr 2016 20:44:10 -0400    

From: Alexander Law <exclusion@gmail.com>  

commit   : ccf893c4bdef19a778a621a4290c85716a257e72    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Apr 2016 18:54:06 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 14 Apr 2016 18:54:06 -0700    

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

commit   : 3ef1f3a3ec1dee5a95a91124359f1bb58502afb4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Apr 2016 18:57:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Apr 2016 18:57:52 -0400    

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: <20228.1460575691@sss.pgh.pa.us>  

commit   : 94cda4f1065bcd21bdce664dc03eaa31faba0442    
  
author   : Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 8 Apr 2016 21:26:25 +0300    
  
committer: Teodor Sigaev <teodor@sigaev.ru>    
date     : Fri, 8 Apr 2016 21:26:25 +0300    

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

commit   : d2189a8026dbfa7542c96e4a63ef09b02e625748    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 8 Apr 2016 12:25:10 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 8 Apr 2016 12:25:10 -0400    

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  

commit   : b1b6aa88b146e0e7ca9b2eb5911d1f56064ccabb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Apr 2016 11:13:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Apr 2016 11:13:17 -0400    

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.  

commit   : 6cd30292bfc38edcae0c1d9c127265cfe665a569    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Mar 2016 11:54:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 29 Mar 2016 11:54:58 -0400    

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.