commit : 4edcd5f5d23c55f60d6c11451437437611731fff author : Tom Lane <firstname.lastname@example.org> date : Mon, 28 Mar 2016 16:14:18 -0400 committer: Tom Lane <email@example.com> date : Mon, 28 Mar 2016 16:14:18 -0400
commit : 190e273416968205db5110a561f5a314ad4b0119 author : Peter Eisentraut <firstname.lastname@example.org> date : Mon, 28 Mar 2016 08:51:44 +0200 committer: Peter Eisentraut <email@example.com> date : Mon, 28 Mar 2016 08:51:44 +0200
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: e6b48ec6c3b5131c5fbfa642b5e56814f088e8d6
Release notes for 9.5.2, 9.4.7, 9.3.12, 9.2.16, 9.1.21.
commit : 938e74e0ddbdd6931f65c54d2035de937c212140 author : Tom Lane <firstname.lastname@example.org> date : Sun, 27 Mar 2016 19:26:26 -0400 committer: Tom Lane <email@example.com> date : Sun, 27 Mar 2016 19:26:26 -0400
Change various Gin*Is* macros to return 0/1.
commit : 290cc21de484da610090d5f62b98fd55e9f70ac7 author : Andres Freund <firstname.lastname@example.org> date : Sun, 27 Mar 2016 17:47:48 +0200 committer: Andres Freund <email@example.com> date : Sun, 27 Mar 2016 17:47:48 +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: 20150811154237.GD17575@awork2.anarazel.de Backpatch: All supported branches
Modernize zic's test for valid timezone abbreviations.
commit : 7a68106ec50515c54505348d494642de897a9416 author : Tom Lane <firstname.lastname@example.org> date : Sat, 26 Mar 2016 15:58:44 -0400 committer: Tom Lane <email@example.com> 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.
Update time zone data files to tzdata release 2016c.
commit : 96fa3745912cfe7d6cb57fb7145755b11b84eab0 author : Tom Lane <firstname.lastname@example.org> date : Fri, 25 Mar 2016 19:03:08 -0400 committer: Tom Lane <email@example.com> 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.
Remove dependency on psed for MSVC builds.
commit : 89bf78a9b185ae536e329986ea4a49abcaac0182 author : Andrew Dunstan <firstname.lastname@example.org> date : Sat, 19 Mar 2016 18:36:35 -0400 committer: Andrew Dunstan <email@example.com> date : Sat, 19 Mar 2016 18:36:35 -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.
Fix "pg_bench -C -M prepared".
commit : be6f9ea2eadc4d58ca6d338491f8451c90b5a369 author : Tom Lane <firstname.lastname@example.org> date : Wed, 16 Mar 2016 23:18:08 -0400 committer: Tom Lane <email@example.com> 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.
Cope if platform declares mbstowcs_l(), but not locale_t, in <xlocale.h>.
commit : e39f86fe000e64235801bb0fbeeade09dd562e1d author : Tom Lane <firstname.lastname@example.org> date : Tue, 15 Mar 2016 13:19:58 -0400 committer: Tom Lane <email@example.com> 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.
Add missing NULL terminator to list_SECURITY_LABEL_preposition.
commit : 39b3ea714212c6ea2878509303a89edd24a0a6b7 author : Tom Lane <firstname.lastname@example.org> date : Mon, 14 Mar 2016 11:31:22 -0400 committer: Tom Lane <email@example.com> 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 firstname.lastname@example.org 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.
Avoid crash on old Windows with AVX2-capable CPU for VS2013 builds
commit : 78b597808108a9837b7cc3660eec4ddb9471ab2f author : Magnus Hagander <email@example.com> date : Thu, 10 Mar 2016 13:48:58 +0100 committer: Magnus Hagander <firstname.lastname@example.org> 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
Avoid unlikely data-loss scenarios due to rename() without fsync.
commit : ce8f42919dfdf823e670fd3a007e2a1239a9391c author : Andres Freund <email@example.com> date : Wed, 9 Mar 2016 18:53:54 -0800 committer: Andres Freund <firstname.lastname@example.org> 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: 56583BDD.email@example.com Backpatch: All supported branches
Introduce durable_rename() and durable_link_or_rename().
commit : c224d44f77247a2eb8ce43fcaeb519f214c1b7d1 author : Andres Freund <firstname.lastname@example.org> date : Wed, 9 Mar 2016 18:53:54 -0800 committer: Andres Freund <email@example.com> 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: 56583BDD.firstname.lastname@example.org Backpatch: All supported branches
Fix incorrect handling of NULL index entries in indexed ROW() comparisons.
commit : c8e059724f35b32e4c54d24349a2e3675067e38c author : Tom Lane <email@example.com> date : Wed, 9 Mar 2016 14:51:01 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Wed, 9 Mar 2016 14:51:01 -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.
ltree: Zero padding bytes when allocating memory for externally visible data.
commit : 185c3d00aac10cc333997fa808372bfcfdda6118 author : Andres Freund <email@example.com> date : Tue, 8 Mar 2016 14:59:29 -0800 committer: Andres Freund <firstname.lastname@example.org> 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-
plperl: Correctly handle empty arrays in plperl_ref_from_pg_array.
commit : ee06c97e48754b252a95bb85a1d2ae9b38fb9081 author : Andres Freund <email@example.com> date : Tue, 8 Mar 2016 13:33:24 -0800 committer: Andres Freund <firstname.lastname@example.org> 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@example.com Backpatch: 9.1-
Fix backwards test for Windows service-ness in pg_ctl.
commit : 15d43196cde78fb46e989bbd6bb8d294fcf2f492 author : Tom Lane <firstname.lastname@example.org> date : Mon, 7 Mar 2016 10:40:44 -0500 committer: Tom Lane <email@example.com> 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.
Fix not-terribly-safe coding in NIImportOOAffixes() and NIImportAffixes().
commit : 8894c9f791c11e37d040634193caf3667f533111 author : Tom Lane <firstname.lastname@example.org> date : Sun, 6 Mar 2016 19:21:03 -0500 committer: Tom Lane <email@example.com> 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.
Fix compile breakage due to 0315dfa8f4afa8390383119330ca0bf241be4ad4.
commit : 756c0f42a9e07a1771715da0193921c2d0fc0253 author : Robert Haas <firstname.lastname@example.org> date : Fri, 4 Mar 2016 12:11:30 -0500 committer: Robert Haas <email@example.com> date : Fri, 4 Mar 2016 12:11:30 -0500
I wasn't careful enough when back-patching.
Fix query-based tab completion for multibyte characters.
commit : c658d5a9b6323ce16029fdcdbc6b93acc3c24114 author : Robert Haas <firstname.lastname@example.org> date : Fri, 4 Mar 2016 11:53:20 -0500 committer: Robert Haas <email@example.com> 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.
Improve error message for rejecting RETURNING clauses with dropped columns.
commit : dcba544dd5f76974ea273cd689ab9ff41a22af1e author : Tom Lane <firstname.lastname@example.org> date : Mon, 29 Feb 2016 19:11:38 -0500 committer: Tom Lane <email@example.com> 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: firstname.lastname@example.org
commit : 36d43f05109e944f431e85ff559727c411ab7089 author : Alvaro Herrera <email@example.com> date : Mon, 29 Feb 2016 18:11:58 -0300 committer: Alvaro Herrera <firstname.lastname@example.org> date : Mon, 29 Feb 2016 18:11:58 -0300
Author: Amit Langote
doc: document MANPATH as /usr/local/pgsql/share/man
commit : 6fdc6262ca188ad7f4c7a9857e28684328a9869b author : Alvaro Herrera <email@example.com> date : Mon, 29 Feb 2016 17:53:55 -0300 committer: Alvaro Herrera <firstname.lastname@example.org> 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
Avoid multiple free_struct_lconv() calls on same data.
commit : 47792639c3e320e8596205cb8a404bac1518e1de author : Tom Lane <email@example.com> date : Sun, 28 Feb 2016 23:39:20 -0500 committer: Tom Lane <firstname.lastname@example.org> 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.
Fix wording in the Tutorial document.
commit : 7cea53e2dcaa9100e8aab925e71fbc8a4b0c80d9 author : Tatsuo Ishii <email@example.com> date : Sun, 21 Feb 2016 09:04:59 +0900 committer: Tatsuo Ishii <firstname.lastname@example.org> date : Sun, 21 Feb 2016 09:04:59 +0900
With suggentions from Tom Lane.
Correct StartupSUBTRANS for page wraparound
commit : c063d3c438d745cae11170345148f03c6f42d077 author : Simon Riggs <simon@2ndQuadrant.com> date : Fri, 19 Feb 2016 08:33:52 +0000 committer: Simon Riggs <simon@2ndQuadrant.com> date : Fri, 19 Feb 2016 08:33:52 +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
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
commit : 29f299728be0de392d25c7f979968a43ae865202 author : Tom Lane <email@example.com> date : Thu, 18 Feb 2016 15:40:35 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Thu, 18 Feb 2016 15:40:35 -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.
Make plpython cope with funny characters in function names.
commit : 7d48349fd9cb3c64d53bdecac933f2c44c703f22 author : Tom Lane <email@example.com> date : Tue, 16 Feb 2016 21:08:15 -0500 committer: Tom Lane <firstname.lastname@example.org> 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.
Improve documentation about CREATE INDEX CONCURRENTLY.
commit : 528db6ab965d33cfcad7e460b1cc4416f3600c3a author : Tom Lane <email@example.com> date : Tue, 16 Feb 2016 13:43:03 -0500 committer: Tom Lane <firstname.lastname@example.org> 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.
Improve wording in the planner doc
commit : 779c46a39f04c7ea2f9aae3b92854b5a885fe07e author : Tatsuo Ishii <email@example.com> date : Tue, 16 Feb 2016 15:36:52 +0900 committer: Tatsuo Ishii <firstname.lastname@example.org> 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.
Correct the formulas for System V IPC parameters SEMMNI and SEMMNS in docs.
commit : 8a96651caa669610d4f39f7a289a78f807f5f363 author : Fujii Masao <email@example.com> date : Tue, 16 Feb 2016 15:05:30 +0900 committer: Fujii Masao <firstname.lastname@example.org> date : Tue, 16 Feb 2016 15:05:30 +0900
In runtime.sgml, the old formulas for calculating the reasonable values of SEMMNI and SEMMNS were incorrect. They have forgotten to count the number of semaphores which both the checkpointer process (introduced in 9.2) and the background worker processes (introduced in 9.3) need. This commit fixes those formulas so that they count the number of semaphores which the checkpointer process and the background worker processes need. Report and patch by Kyotaro Horiguchi. Only the patch for 9.3 was modified by me. Back-patch to 9.2 where the checkpointer process was added and the number of needed semaphores was increased. Author: Kyotaro Horiguchi Reviewed-by: Fujii Masao Backpatch: 9.2 Discussion: http://email@example.com
pgbench: avoid FD_ISSET on an invalid file descriptor
commit : daac53779acdab512e8347ce7472cf0923cd8598 author : Alvaro Herrera <firstname.lastname@example.org> date : Mon, 15 Feb 2016 20:33:43 -0300 committer: Alvaro Herrera <email@example.com> 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.
Suppress compiler warnings about useless comparison of unsigned to zero.
commit : e781baa6408e6f43ad71d4546cc47cb348b3104e author : Tom Lane <firstname.lastname@example.org> date : Mon, 15 Feb 2016 17:11:52 -0500 committer: Tom Lane <email@example.com> 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.
Accept pg_ctl timeout from the PGCTLTIMEOUT environment variable.
commit : 4421b5253f17c699eb6b371fdcdbc88729185aa1 author : Noah Misch <firstname.lastname@example.org> date : Wed, 10 Feb 2016 20:34:02 -0500 committer: Noah Misch <email@example.com> 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.
Avoid use of sscanf() to parse ispell dictionary files.
commit : 64f99a2ee393d80d063078d4afad3a57df028a2a author : Tom Lane <firstname.lastname@example.org> date : Wed, 10 Feb 2016 19:30:12 -0500 committer: Tom Lane <email@example.com> 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.