PostgreSQL 9.1.21 commit log

commit   : 158a0fb254578e93cec7a940c780426217b79343    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 28 Mar 2016 16:16:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 28 Mar 2016 16:16:20 -0400    

commit   : 83b228a0babbbd637e830796a670a18a468732d5    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 28 Mar 2016 08:52:41 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 28 Mar 2016 08:52:41 +0200    

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

commit   : bb4b4d1cf9881334a5f038631eccf371df1841c0    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 27 Mar 2016 19:26:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 27 Mar 2016 19:26:26 -0400    

commit   : 598e2c55ebbbb292c4f79c4acdc8567bf18ef9be    
  
author   : Andres Freund <[email protected]>    
date     : Sun, 27 Mar 2016 17:47:46 +0200    
  
committer: Andres Freund <[email protected]>    
date     : Sun, 27 Mar 2016 17:47:46 +0200    

Returning the direct result of bit arithmetic, in a macro intended to be  
used in a boolean manner, can be problematic if the return value is  
stored in a variable of type 'bool'. If bool is implemented using C99's  
_Bool, that can lead to comparison failures if the variable is then  
compared again with the expression (see ginStepRight() for an example  
that fails), as _Bool forces the result to be 0/1. That happens in some  
configurations of newer MSVC compilers.  It's also problematic when  
storing the result of such an expression in a narrower type.  
  
Several gin macros have been declared in that style since gin's initial  
commit in 8a3631f8d86.  
  
There's a lot more macros like this, but this is the only one causing  
regression test failures; and I don't want to commit and backpatch a  
larger patch with lots of conflicts just before the next set of minor  
releases.  
  
Discussion: [email protected]  
Backpatch: All supported branches  

commit   : 528f112b049b22c72f1d16f22754585254d6115b    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 26 Mar 2016 15:58:44 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 26 Mar 2016 15:58:44 -0400    

We really need to sync all of our IANA-derived timezone code with upstream,  
but that's going to be a large patch and I certainly don't care to shove  
such a thing into stable branches immediately before a release.  As a  
stopgap, copy just the tzcode2016c logic that checks validity of timezone  
abbreviations.  This prevents getting multiple "time zone abbreviation  
differs from POSIX standard" bleats with tzdata 2014b and later.  

commit   : e5fd35cc54720c25c748d4cdf2c89f094865ad48    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 25 Mar 2016 19:03:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 25 Mar 2016 19:03:08 -0400    

DST law changes in Azerbaijan, Chile, Haiti, Palestine, and Russia (Altai,  
Astrakhan, Kirov, Sakhalin, Ulyanovsk regions).  Historical corrections  
for Lithuania, Moldova, Russia (Kaliningrad, Samara, Volgograd).  
  
As of 2015b, the keepers of the IANA timezone database started to use  
numeric time zone abbreviations (e.g., "+04") instead of inventing  
abbreviations not found in the wild like "ASTT".  This causes our rather  
old copy of zic to whine "warning: time zone abbreviation differs from  
POSIX standard" several times during "make install".  This warning is  
harmless according to the IANA folk, and I don't see any problems with  
these abbreviations in some simple tests; but it seems like now would be  
a good time to update our copy of the tzcode stuff.  I'll look into that  
soon.  

commit   : 2aa9fd9631fe11800092263c499bf77012067903    
  
author   : Andrew Dunstan <[email protected]>    
date     : Sat, 19 Mar 2016 18:59:41 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Sat, 19 Mar 2016 18:59:41 -0400    

Modern Perl has removed psed from its core distribution, so it might not  
be readily available on some build platforms. We therefore replace its  
use with a Perl script generated by s2p, which is equivalent to the sed  
script. The latter is retained for non-MSVC builds to avoid creating a  
new hard dependency on Perl for non-Windows tarball builds.  
  
Backpatch to all live branches.  
  
Michael Paquier and me.  

commit   : 1965a8ce1da1a8284530637b96115906722f1d03    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 16 Mar 2016 23:18:08 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 16 Mar 2016 23:18:08 -0400    

This didn't work because when we dropped and re-established a database  
connection, we did not bother to reset session-specific state such as  
the statements-are-prepared flags.  
  
The st->prepared[] array certainly needs to be flushed, and I cleared a  
couple of other fields as well that couldn't possibly retain meaningful  
state for a new connection.  
  
In passing, fix some bogus comments and strange field order choices.  
  
Per report from Robins Tharakan.  

commit   : 0c94970c932de50bfa4c57da815756de76b941f1    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 15 Mar 2016 13:19:58 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 15 Mar 2016 13:19:58 -0400    

Previously, we included <xlocale.h> only if necessary to get the definition  
of type locale_t.  According to notes in PGAC_TYPE_LOCALE_T, this is  
important because on some versions of glibc that file supplies an  
incompatible declaration of locale_t.  (This info may be obsolete, because  
on my RHEL6 box that seems to be the *only* definition of locale_t; but  
there may still be glibc's in the wild for which it's a live concern.)  
  
It turns out though that on FreeBSD and maybe other BSDen, you can get  
locale_t from stdlib.h or locale.h but mbstowcs_l() and friends only from  
<xlocale.h>.  This was leaving us compiling calls to mbstowcs_l() and  
friends with no visible prototype, which causes a warning and could  
possibly cause actual trouble, since it's not declared to return int.  
  
Hence, adjust the configure checks so that we'll include <xlocale.h>  
either if it's necessary to get type locale_t or if it's necessary to  
get a declaration of mbstowcs_l().  
  
Report and patch by Aleksander Alekseev, somewhat whacked around by me.  
Back-patch to all supported branches, since we have been using  
mbstowcs_l() since 9.1.  

commit   : 2d61d88d8d0be910b54d28448e3fc94f94995792    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 14 Mar 2016 11:31:22 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 14 Mar 2016 11:31:22 -0400    

On the machines I tried this on, pressing TAB after SECURITY LABEL led to  
being offered ON and FOR as intended, plus random other keywords (varying  
across machines).  But if you were a bit more unlucky you'd get a crash,  
as reported by [email protected] in bug #14019.  
  
Seems to have been an aboriginal error in the SECURITY LABEL patch,  
commit 4d355a8336e0f226.  Hence, back-patch to all supported versions.  
There's no bug in HEAD, though, thanks to our recent tab-completion  
rewrite.  

commit   : 3e6385e27105a95ccc00ae475a37f83d431fc730    
  
author   : Magnus Hagander <[email protected]>    
date     : Thu, 10 Mar 2016 13:48:58 +0100    
  
committer: Magnus Hagander <[email protected]>    
date     : Thu, 10 Mar 2016 13:48:58 +0100    

The Visual Studio 2013 CRT generates invalid code when it makes a 64-bit  
build that is later used on a CPU that supports AVX2 instructions using a  
version of Windows before 7SP1/2008R2SP1.  
  
Detect this combination, and in those cases turn off the generation of  
FMA3, per recommendation from the Visual Studio team.  
  
The bug is actually in the CRT shipping with Visual Studio 2013, but  
Microsoft have stated they're only fixing it in newer major versions.  
The fix is therefor conditioned specifically on being built with this  
version of Visual Studio, and not previous or later versions.  
  
Author: Christian Ullrich  

commit   : a62714fae23d2056242bb2ac872111cab8f9fbd1    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 9 Mar 2016 18:53:54 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 9 Mar 2016 18:53:54 -0800    

Renaming a file using rename(2) is not guaranteed to be durable in face  
of crashes. Use the previously added durable_rename()/durable_link_or_rename()  
in various places where we previously just renamed files.  
  
Most of the changed call sites are arguably not critical, but it seems  
better to err on the side of too much durability.  The most prominent  
known case where the previously missing fsyncs could cause data loss is  
crashes at the end of a checkpoint. After the actual checkpoint has been  
performed, old WAL files are recycled. When they're filled, their  
contents are fdatasynced, but we did not fsync the containing  
directory. An OS/hardware crash in an unfortunate moment could then end  
up leaving that file with its old name, but new content; WAL replay  
would thus not replay it.  
  
Reported-By: Tomas Vondra  
Author: Michael Paquier, Tomas Vondra, Andres Freund  
Discussion: [email protected]  
Backpatch: All supported branches  

commit   : d0e47bcd47bcfa4a3be020965c93980f5fad6e80    
  
author   : Andres Freund <[email protected]>    
date     : Wed, 9 Mar 2016 18:53:54 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Wed, 9 Mar 2016 18:53:54 -0800    

Renaming a file using rename(2) is not guaranteed to be durable in face  
of crashes; especially on filesystems like xfs and ext4 when mounted  
with data=writeback. To be certain that a rename() atomically replaces  
the previous file contents in the face of crashes and different  
filesystems, one has to fsync the old filename, rename the file, fsync  
the new filename, fsync the containing directory.  This sequence is not  
generally adhered to currently; which exposes us to data loss risks. To  
avoid having to repeat this arduous sequence, introduce  
durable_rename(), which wraps all that.  
  
Also add durable_link_or_rename(). Several places use link() (with a  
fallback to rename()) to rename a file, trying to avoid replacing the  
target file out of paranoia. Some of those rename sequences need to be  
durable as well. There seems little reason extend several copies of the  
same logic, so centralize the link() callers.  
  
This commit does not yet make use of the new functions; they're used in  
a followup commit.  
  
Author: Michael Paquier, Andres Freund  
Discussion: [email protected]  
Backpatch: All supported branches  

commit   : d485d9581dd3b85181aa39e18f130809bc129d5f    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 9 Mar 2016 14:51:02 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 9 Mar 2016 14:51:02 -0500    

An index search using a row comparison such as ROW(a, b) > ROW('x', 'y')  
would stop upon reaching a NULL entry in the "b" column, ignoring the  
fact that there might be non-NULL "b" values associated with later values  
of "a".  This happens because _bt_mark_scankey_required() marks the  
subsidiary scankey for "b" as required, which is just wrong: it's for  
a column after the one with the first inequality key (namely "a"), and  
thus can't be considered a required match.  
  
This bit of brain fade dates back to the very beginnings of our support  
for indexed ROW() comparisons, in 2006.  Kind of astonishing that no one  
came across it before Glen Takahashi, in bug #14010.  
  
Back-patch to all supported versions.  
  
Note: the given test case doesn't actually fail in unpatched 9.1, evidently  
because the fix for bug #6278 (i.e., stopping at nulls in either scan  
direction) is required to make it fail.  I'm sure I could devise a case  
that fails in 9.1 as well, perhaps with something involving making a cursor  
back up; but it doesn't seem worth the trouble.  

commit   : 814570418d5e6bccb766efbe86d27aef206e5511    
  
author   : Andres Freund <[email protected]>    
date     : Tue, 8 Mar 2016 14:59:29 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Tue, 8 Mar 2016 14:59:29 -0800    

ltree/ltree_gist/ltxtquery's headers stores data at MAXALIGN alignment,  
requiring some padding bytes. So far we left these uninitialized. Zero  
those by using palloc0.  
  
Author: Andres Freund  
Reported-By: Andres Freund / valgrind / buildarm animal skink  
Backpatch: 9.1-  

commit   : c5f1fbbfb51d852f0e9a1143dae9faa5186c1b2d    
  
author   : Andres Freund <[email protected]>    
date     : Tue, 8 Mar 2016 13:33:24 -0800    
  
committer: Andres Freund <[email protected]>    
date     : Tue, 8 Mar 2016 13:33:24 -0800    

plperl_ref_from_pg_array() didn't consider the case that postgrs arrays  
can have 0 dimensions (when they're empty) and accessed the first  
dimension without a check. Fix that by special casing the empty array  
case.  
  
Author: Alex Hunsaker  
Reported-By: Andres Freund / valgrind / buildfarm animal skink  
Discussion: [email protected]  
Backpatch: 9.1-  

commit   : 5a39c7395d2dcf44f62256ec05b66341149f222f    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 7 Mar 2016 10:40:44 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 7 Mar 2016 10:40:44 -0500    

A thinko in a96761391 caused pg_ctl to get it exactly backwards when  
deciding whether to report problems to the Windows eventlog or to stderr.  
Per bug #14001 from Manuel Mathar, who also identified the fix.  
Like the previous patch, back-patch to all supported branches.  

commit   : fe747b741d71a921c1a29f06902c73a263af7c65    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 6 Mar 2016 19:21:03 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 6 Mar 2016 19:21:03 -0500    

There were two places in spell.c that supposed that they could search  
for a location in a string produced by lowerstr() and then transpose  
the offset into the original string.  But this fails completely if  
lowerstr() transforms any characters into characters of different byte  
length, as can happen in Turkish UTF8 for instance.  
  
We'd added some comments about this coding in commit 51e78ab4ff328296,  
but failed to realize that it was not merely confusing but wrong.  
  
Coverity complained about this code years ago, but in such an opaque  
fashion that nobody understood what it was on about.  I'm not entirely  
sure that this issue *is* what it's on about, actually, but perhaps  
this patch will shut it up -- and in any case the problem is clear.  
  
Back-patch to all supported branches.  

commit   : 58c1af4fd0952a9ac45b06824dcaee6f5fbdd737    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 4 Mar 2016 12:11:30 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 4 Mar 2016 12:11:30 -0500    

I wasn't careful enough when back-patching.  

commit   : b4895bf796d66245080cb37acaf2b396014b7225    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 4 Mar 2016 11:53:20 -0500    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 4 Mar 2016 11:53:20 -0500    

The existing code confuses the byte length of the string (which is  
relevant when passing it to pg_strncasecmp) with the character length  
of the string (which is relevant when it is used with the SQL substring  
function).  Separate those two concepts.  
  
Report and patch by Kyotaro Horiguchi, reviewed by Thomas Munro and  
reviewed and further revised by me.  

commit   : f32b8bc9e0e0e3096bcdae15f9946b39851e10f9    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 29 Feb 2016 19:11:38 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 29 Feb 2016 19:11:38 -0500    

This error message was written with only ON SELECT rules in mind, but since  
then we also made RETURNING-clause targetlists go through the same logic.  
This means that you got a rather off-topic error message if you tried to  
add a rule with RETURNING to a table having dropped columns.  Ideally we'd  
just support that, but some preliminary investigation says that it might be  
a significant amount of work.  Seeing that Nicklas Avén's complaint is the  
first one we've gotten about this in the ten years or so that the code's  
been like that, I'm unwilling to put much time into it.  Instead, improve  
the error report by issuing a different message for RETURNING cases, and  
revise the associated comment based on this investigation.  
  
Discussion: [email protected]  

commit   : 0a3070baf3c48def1f7c46f57a6313adc26be4fa    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 29 Feb 2016 18:11:58 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 29 Feb 2016 18:11:58 -0300    

Author: Amit Langote  

commit   : 397d247bac480c2ea7689b057bc9eb3ab49c87a5    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 29 Feb 2016 17:53:55 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 29 Feb 2016 17:53:55 -0300    

The docs were advising to use /usr/local/pgsql/man instead, but that's  
wrong.  
  
Reported-By: Slawomir Sudnik  
Backpatch-To: 9.1  
Bug: #13894  

commit   : 7d6c58aa1114a6482722c125d44b4eb15fe5df18    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 28 Feb 2016 23:39:20 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 28 Feb 2016 23:39:20 -0500    

A failure partway through PGLC_localeconv() led to a situation where  
the next call would call free_struct_lconv() a second time, leading  
to free() on already-freed strings, typically leading to a core dump.  
Add a flag to remember whether we need to do that.  
  
Per report from Thom Brown.  His example case only provokes the failure  
as far back as 9.4, but nonetheless this code is obviously broken, so  
back-patch to all supported branches.  

commit   : 5d312ef1b2b38d0db90394691694238194172e84    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Sun, 21 Feb 2016 09:04:59 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Sun, 21 Feb 2016 09:04:59 +0900    

With suggentions from Tom Lane.  

commit   : ca32f125b92c91c2abd02e25aede7b52b318f840    
  
author   : Simon Riggs <[email protected]>    
date     : Fri, 19 Feb 2016 08:35:02 +0000    
  
committer: Simon Riggs <[email protected]>    
date     : Fri, 19 Feb 2016 08:35:02 +0000    

StartupSUBTRANS() incorrectly handled cases near the max pageid in the subtrans  
data structure, which in some cases could lead to errors in startup for Hot  
Standby.  
This patch wraps the pageids correctly, avoiding any such errors.  
Identified by exhaustive crash testing by Jeff Janes.  
  
Jeff Janes  

commit   : 0f359c7de9f5f8fceedfebfae0b0cbbf01d1f5bf    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 18 Feb 2016 15:40:36 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 18 Feb 2016 15:40:36 -0500    

Dead or half-dead index leaf pages were incorrectly reported as live, as a  
consequence of a code rearrangement I made (during a moment of severe brain  
fade, evidently) in commit d287818eb514d431.  
  
The index metapage was not counted in index_size, causing that result to  
not agree with the actual index size on-disk.  
  
Index root pages were not counted in internal_pages, which is inconsistent  
compared to the case of a root that's also a leaf (one-page index), where  
the root would be counted in leaf_pages.  Aside from that inconsistency,  
this could lead to additional transient discrepancies between the reported  
page counts and index_size, since it's possible for pgstatindex's scan to  
see zero or multiple pages marked as BTP_ROOT, if the root moves due to  
a split during the scan.  With these fixes, index_size will always be  
exactly one page more than the sum of the displayed page counts.  
  
Also, the index_size result was incorrectly documented as being measured in  
pages; it's always been measured in bytes.  (While fixing that, I couldn't  
resist doing some small additional wordsmithing on the pgstattuple docs.)  
  
Including the metapage causes the reported index_size to not be zero for  
an empty index.  To preserve the desired property that the pgstattuple  
regression test results are platform-independent (ie, BLCKSZ configuration  
independent), scale the index_size result in the regression tests.  
  
The documentation issue was reported by Otsuka Kenji, and the inconsistent  
root page counting by Peter Geoghegan; the other problems noted by me.  
Back-patch to all supported branches, because this has been broken for  
a long time.  

commit   : 875973f5d756a56ea3589c059fc83664e2bb010e    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 16 Feb 2016 21:08:15 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 16 Feb 2016 21:08:15 -0500    

A function name that's double-quoted in SQL can contain almost any  
characters, but we were using that name directly as part of the name  
generated for the Python-level function, and Python doesn't like  
anything that isn't pretty much a standard identifier.  To fix,  
replace anything that isn't an ASCII letter or digit with an underscore  
in the generated name.  This doesn't create any risk of duplicate Python  
function names because we were already appending the function OID to  
the generated name to ensure uniqueness.  Per bug #13960 from Jim Nasby.  
  
Patch by Jim Nasby, modified a bit by me.  Back-patch to all  
supported branches.  

commit   : 56f5e77f6c6e1ad1df1cdec4d8179886bef88075    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 16 Feb 2016 13:43:03 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 16 Feb 2016 13:43:03 -0500    

Clarify the description of which transactions will block a CREATE INDEX  
CONCURRENTLY command from proceeding, and mention that the index might  
still not be usable after CREATE INDEX completes.  (This happens if the  
index build detected broken HOT chains, so that pg_index.indcheckxmin gets  
set, and there are open old transactions preventing the xmin horizon from  
advancing past the index's initial creation.  I didn't want to explain what  
broken HOT chains are, though, so I omitted an explanation of exactly when  
old transactions prevent the index from being used.)  
  
Per discussion with Chris Travers.  Back-patch to all supported branches,  
since the same text appears in all of them.  

commit   : 38e617df36958660eee37571e3cc1713e3a49a4f    
  
author   : Tatsuo Ishii <[email protected]>    
date     : Tue, 16 Feb 2016 15:36:52 +0900    
  
committer: Tatsuo Ishii <[email protected]>    
date     : Tue, 16 Feb 2016 15:36:52 +0900    

Change "In this case" to "In the example above" to clarify what it  
actually refers to.  

commit   : 0b2aefe74afaf418ca74f31fc3ef39f2a3cd336a    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 15 Feb 2016 20:33:43 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 15 Feb 2016 20:33:43 -0300    

The original code wasn't careful to test the file descriptor returned by  
PQsocket() for an invalid socket.  If an invalid socket did turn up,  
that would amount to calling FD_ISSET with fd = -1, whereby undefined  
behavior can be invoked.  
  
To fix, test file descriptor for validity and stop further processing if  
that fails.  
  
Problem noticed by Coverity.  
  
There is an existing FD_ISSET callsite that does check for invalid  
sockets beforehand, but the error message reported by it was  
strerror(errno); in testing the aforementioned change, that turns out to  
result in "bad socket: Success" which isn't terribly helpful.  Instead  
use PQerrorMessage() in both places which is more likely to contain an  
useful error message.  
  
Backpatch-through: 9.1.  

commit   : 1f52d23ef2565d1cd7d72292882776ab56ce64ad    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 15 Feb 2016 17:11:52 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 15 Feb 2016 17:11:52 -0500    

Reportedly, some compilers warn about tests like "c < 0" if c is unsigned,  
and hence complain about the character range checks I added in commit  
3bb3f42f3749d40b8d4de65871e8d828b18d4a45.  This is a bit of a pain since  
the regex library doesn't really want to assume that chr is unsigned.  
However, since any such reconfiguration would involve manual edits of  
regcustom.h anyway, we can put it on the shoulders of whoever wants to  
do that to adjust this new range-checking macro correctly.  
  
Per gripes from Coverity and Andres.  

commit   : f97664cf54a2e1bf7d727b1c86b1d9b41e1eaba6    
  
author   : Noah Misch <[email protected]>    
date     : Wed, 10 Feb 2016 20:34:02 -0500    
  
committer: Noah Misch <[email protected]>    
date     : Wed, 10 Feb 2016 20:34:02 -0500    

Many automated test suites call pg_ctl.  Buildfarm members axolotl,  
hornet, mandrill, shearwater, sungazer and tern have failed when server  
shutdown took longer than the pg_ctl default 60s timeout.  This addition  
permits slow hosts to easily raise the timeout without us editing a  
--timeout argument into every test suite pg_ctl call.  Back-patch to 9.1  
(all supported versions) for the sake of automated testing.  
  
Reviewed by Tom Lane.  

commit   : e56acbe2a3d942e0f029ecdb1eb8b11f7b9e99b2    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 10 Feb 2016 19:30:12 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 10 Feb 2016 19:30:12 -0500    

It turns out that on FreeBSD-derived platforms (including OS X), the  
*scanf() family of functions is pretty much brain-dead about multibyte  
characters.  In particular it will apply isspace() to individual bytes  
of input even when those bytes are part of a multibyte character, thus  
allowing false recognition of a field-terminating space.  
  
We appear to have little alternative other than instituting a coding  
rule that *scanf() is not to be used if the input string might contain  
multibyte characters.  (There was some discussion of relying on "%ls",  
but that probably just moves the portability problem somewhere else,  
and besides it doesn't fully prevent BSD *scanf() from using isspace().)  
  
This patch is a down payment on that: it gets rid of use of sscanf()  
to parse ispell dictionary files, which are certainly at great risk  
of having a problem.  The code is cleaner this way anyway, though  
a bit longer.  
  
In passing, improve a few comments.  
  
Report and patch by Artur Zakirov, reviewed and somewhat tweaked by me.  
Back-patch to all supported branches.