Stamp 9.4.7.
commit : d77841d1cebd3514603af055f141a84c8e53cbd3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Mar 2016 16:09:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Mar 2016 16:09:55 -0400
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 : a08a6dca995528cbf011cd8251daf1c190dd324d
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 28 Mar 2016 08:48:08 +0200
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 28 Mar 2016 08:48:08 +0200
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 515f3c859e6f29c11e1e7749591508d6fb761c2c
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/pl.po
M src/backend/po/pt_BR.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/pl.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/pl.po
M src/bin/pg_ctl/po/fr.po
M src/bin/pg_ctl/po/pl.po
M src/bin/pg_ctl/po/pt_BR.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/pl.po
M src/bin/pg_dump/po/pt_BR.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/pl.po
M src/bin/scripts/po/fr.po
M src/bin/scripts/po/pl.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/pl.po
M src/pl/plpython/po/fr.po
M src/pl/plpython/po/pl.po
M src/pl/plpython/po/pt_BR.po
Release notes for 9.5.2, 9.4.7, 9.3.12, 9.2.16, 9.1.21.
commit : 8c3672f0a35ea0b981c4a328b3c6d80a3b99a8b9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 27 Mar 2016 19:26:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 27 Mar 2016 19:26:26 -0400
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
Change various Gin*Is* macros to return 0/1.
commit : 6faea0169082b4218588e575c3db8b26458664df
author : Andres Freund <andres@anarazel.de>
date : Sun, 27 Mar 2016 17:47:53 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sun, 27 Mar 2016 17:47:53 +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
M src/include/access/gin_private.h
Modernize zic's test for valid timezone abbreviations.
commit : a330da405285c57e3a46c5fe12d1f555340e9e15
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Mar 2016 15:58:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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.
M src/timezone/zic.c
Update time zone data files to tzdata release 2016c.
commit : de371e68a598868b412f2b5b4211f912a519c491
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Mar 2016 19:03:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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.
M src/timezone/data/asia
M src/timezone/data/australasia
M src/timezone/data/europe
M src/timezone/data/iso3166.tab
M src/timezone/data/leapseconds
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/America.txt
M src/timezone/tznames/Antarctica.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Pacific.txt
Remove dependency on psed for MSVC builds.
commit : 6336ca916b366ea2e0fdded00aaccb725978962d
author : Andrew Dunstan <andrew@dunslane.net>
date : Sat, 19 Mar 2016 18:36:35 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
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.
A src/backend/utils/Gen_dummy_probes.pl
M src/tools/msvc/Solution.pm
Fix phony .PHONY.
commit : b190fe95bbf9222143c449afdc1c59783653e0b9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Mar 2016 17:19:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Mar 2016 17:19:37 -0400
A couple makefiles had misspelled the magic .PHONY target as PHONY.
M contrib/test_decoding/Makefile
Fix assorted breakage in to_char()'s OF format option.
commit : 17a250b189a94a470e37ce14d0ebf72390c86d4d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Mar 2016 15:50:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Mar 2016 15:50:33 -0400
In HEAD, fix incorrect field width for hours part of OF when tm_gmtoff is
negative. This was introduced by commit 2d87eedc1d4468d3 as a result of
falsely applying a pattern that's correct when + signs are omitted, which
is not the case for OF.
In 9.4, fix missing abs() call that allowed a sign to be attached to the
minutes part of OF. This was fixed in 9.5 by 9b43d73b3f9bef27, but for
inscrutable reasons not back-patched.
In all three versions, ensure that the sign of tm_gmtoff is correctly
reported even when the GMT offset is less than 1 hour.
Add regression tests, which evidently we desperately need here.
Thomas Munro and Tom Lane, per report from David Fetter
M src/backend/utils/adt/formatting.c
M src/test/regress/expected/timestamptz.out
M src/test/regress/sql/timestamptz.sql
Fix "pg_bench -C -M prepared".
commit : 23cb32660c841d21a376642e40d8cfbea6c5f010
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Mar 2016 23:18:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Mar 2016 23:18:07 -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.
M contrib/pgbench/pgbench.c
Fix typos in comments
commit : b0bdc3f182995658f42470a6f5314ea58f48c6d8
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 15 Mar 2016 17:57:16 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 15 Mar 2016 17:57:16 -0300
M src/backend/access/transam/xlog.c
Cope if platform declares mbstowcs_l(), but not locale_t, in <xlocale.h>.
commit : 00fd43499184bf39a7017a3c15990a40e99e4fd2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Mar 2016 13:19:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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.
M config/c-library.m4
M configure
M configure.in
M src/include/pg_config.h.in
M src/include/pg_config.h.win32
M src/include/utils/pg_locale.h
Add missing NULL terminator to list_SECURITY_LABEL_preposition[].
commit : 13108dd0e245055d9600c932cd9ea72ca7eb8eec
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 14 Mar 2016 11:31:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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 nummervet@mail.ru 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.
M src/bin/psql/tab-complete.c
Avoid crash on old Windows with AVX2-capable CPU for VS2013 builds
commit : 8857488b64c34c8084a14ebefbd667fd5285d1a8
author : Magnus Hagander <magnus@hagander.net>
date : Thu, 10 Mar 2016 13:48:58 +0100
committer: Magnus Hagander <magnus@hagander.net>
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
M src/backend/main/main.c
Avoid unlikely data-loss scenarios due to rename() without fsync.
commit : 4f37d091694d77b15f36a8a220025f5faa1ed296
author : Andres Freund <andres@anarazel.de>
date : Wed, 9 Mar 2016 18:53:54 -0800
committer: Andres Freund <andres@anarazel.de>
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.9060302@2ndquadrant.com
Backpatch: All supported branches
M contrib/pg_stat_statements/pg_stat_statements.c
M src/backend/access/transam/timeline.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogarchive.c
M src/backend/postmaster/pgarch.c
M src/backend/utils/misc/guc.c
Introduce durable_rename() and durable_link_or_rename().
commit : 43b491a817fb494bef22c9e8374a9fddfd30ebda
author : Andres Freund <andres@anarazel.de>
date : Wed, 9 Mar 2016 18:53:54 -0800
committer: Andres Freund <andres@anarazel.de>
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.9060302@2ndquadrant.com
Backpatch: All supported branches
M src/backend/replication/slot.c
M src/backend/storage/file/fd.c
M src/backend/storage/file/reinit.c
M src/include/storage/fd.h
Fix incorrect handling of NULL index entries in indexed ROW() comparisons.
commit : da936200dbd92509768376b8ca198cfcbeec738b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 9 Mar 2016 14:51:01 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
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.
M src/backend/access/nbtree/nbtutils.c
M src/test/regress/expected/rowtypes.out
M src/test/regress/sql/rowtypes.sql
Add valgrind suppressions for python code.
commit : 7e31314c5fcf942a900cce4637a27594ee32a65b
author : Andres Freund <andres@anarazel.de>
date : Tue, 8 Mar 2016 17:34:09 -0800
committer: Andres Freund <andres@anarazel.de>
date : Tue, 8 Mar 2016 17:34:09 -0800
Python's allocator does some low-level tricks for efficiency;
unfortunately they trigger valgrind errors. Those tricks can be disabled
making instrumentation easier; but few people testing postgres will have
such a build of python. So add broad suppressions of the resulting
errors.
See also https://svn.python.org/projects/python/trunk/Misc/README.valgrind
This possibly will suppress valid errors, but without it it's basically
impossible to use valgrind with plpython code.
Author: Andres Freund
Backpatch: 9.4, where we started to maintain valgrind suppressions
M src/tools/valgrind.supp
Add valgrind suppressions for bootstrap related code.
commit : 6416b1d422e588b0064d09e6a201d184b70638c1
author : Andres Freund <andres@anarazel.de>
date : Tue, 8 Mar 2016 19:21:28 -0800
committer: Andres Freund <andres@anarazel.de>
date : Tue, 8 Mar 2016 19:21:28 -0800
Author: Andres Freund
Backpatch: 9.4, where we started to maintain valgrind suppressions
M src/tools/valgrind.supp
ltree: Zero padding bytes when allocating memory for externally visible data.
commit : 8457c69feaf572a2d3025e47b6bed92bb8cb719b
author : Andres Freund <andres@anarazel.de>
date : Tue, 8 Mar 2016 14:59:29 -0800
committer: Andres Freund <andres@anarazel.de>
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-
M contrib/ltree/_ltree_gist.c
M contrib/ltree/_ltree_op.c
M contrib/ltree/ltree_gist.c
M contrib/ltree/ltree_op.c
M contrib/ltree/ltxtquery_io.c
plperl: Correctly handle empty arrays in plperl_ref_from_pg_array.
commit : 6041d388c40a23ee0e7b313baeceb8998eed54bf
author : Andres Freund <andres@anarazel.de>
date : Tue, 8 Mar 2016 13:33:24 -0800
committer: Andres Freund <andres@anarazel.de>
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: 20160308063240.usnzg6bsbjrne667@alap3.anarazel.de
Backpatch: 9.1-
M src/pl/plperl/plperl.c
Fix minor typo in logical-decoding docs.
commit : 2afe95448adf897bf2563fcd4c2cfb30a99949c8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Mar 2016 21:52:30 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Mar 2016 21:52:30 -0500
David Rowley
M doc/src/sgml/logicaldecoding.sgml
Further improvements to c8f621c43.
commit : e3e84fd35838a43feef94ea78534713d745e9a08
author : Andres Freund <andres@anarazel.de>
date : Mon, 7 Mar 2016 14:24:58 -0800
committer: Andres Freund <andres@anarazel.de>
date : Mon, 7 Mar 2016 14:24:58 -0800
Coverity and inspection for the issue addressed in fd45d16f found some
questionable code.
Specifically coverity noticed that the wrong length was added in
ReorderBufferSerializeChange() - without immediate negative consequences
as the variable isn't used afterwards. During code-review and testing I
noticed that a bit of space was wasted when allocating tuple bufs in
several places. Thirdly, the debug memset()s in
ReorderBufferGetTupleBuf() reduce the error checking valgrind can do.
Backpatch: 9.4, like c8f621c43.
M src/backend/replication/logical/decode.c
M src/backend/replication/logical/reorderbuffer.c
Fix backwards test for Windows service-ness in pg_ctl.
commit : 89f8372cb3a223cace21d4037336bfb37e8dbf3c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Mar 2016 10:40:44 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
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.
M src/bin/pg_ctl/pg_ctl.c
Fix wrong allocation size in c8f621c43.
commit : fb3ea0465c1710c565e98d4b3e37aebb4e487eaf
author : Andres Freund <andres@anarazel.de>
date : Sun, 6 Mar 2016 16:27:20 -0800
committer: Andres Freund <andres@anarazel.de>
date : Sun, 6 Mar 2016 16:27:20 -0800
In c8f621c43 I forgot to account for MAXALIGN when allocating a new
tuplebuf in ReorderBufferGetTupleBuf(). That happens to currently not
cause active problems on a number of platforms because the affected
pointer is already aligned, but others, like ppc and hppa, trigger this
in the regression test, due to a debug memset clearing memory.
Fix that.
Backpatch: 9.4, like the previous commit.
M src/backend/replication/logical/reorderbuffer.c
Fix not-terribly-safe coding in NIImportOOAffixes() and NIImportAffixes().
commit : 3fa4715c506128405631e84bc91efb90e95b0ca7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 6 Mar 2016 19:21:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
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.
M src/backend/tsearch/spell.c
Add valgrind suppression for padding bytes in twophase records.
commit : 61920837b595a8c2678bd422f34fd2f556c22965
author : Andres Freund <andres@anarazel.de>
date : Sat, 5 Mar 2016 18:24:23 -0800
committer: Andres Freund <andres@anarazel.de>
date : Sat, 5 Mar 2016 18:24:23 -0800
Backpatch of 9a0a12f683235d3e10b873baba974f6414297a7e.
M src/tools/valgrind.supp
logical decoding: Fix handling of large old tuples with replica identity full.
commit : 3b94b3a496fd978ce481ba147627569bf7adc58f
author : Andres Freund <andres@anarazel.de>
date : Sat, 5 Mar 2016 18:02:20 -0800
committer: Andres Freund <andres@anarazel.de>
date : Sat, 5 Mar 2016 18:02:20 -0800
When decoding the old version of an UPDATE or DELETE change, and if that
tuple was bigger than MaxHeapTupleSize, we either Assert'ed out, or
failed in more subtle ways in non-assert builds. Normally individual
tuples aren't bigger than MaxHeapTupleSize, with big datums toasted.
But that's not the case for the old version of a tuple for logical
decoding; the replica identity is logged as one piece. With the default
replica identity btree limits that to small tuples, but that's not the
case for FULL.
Change the tuple buffer infrastructure to separate allocate over-large
tuples, instead of always going through the slab cache.
This unfortunately requires changing the ReorderBufferTupleBuf
definition, we need to store the allocated size someplace. To avoid
requiring output plugins to recompile, don't store HeapTupleHeaderData
directly after HeapTupleData, but point to it via t_data; that leaves
rooms for the allocated size. As there's no reason for an output plugin
to look at ReorderBufferTupleBuf->t_data.header, remove the field. It
was just a minor convenience having it directly accessible.
Reported-By: Adam Dratwiński
Discussion: CAKg6ypLd7773AOX4DiOGRwQk1TVOQKhNwjYiVjJnpq8Wo+i62Q@mail.gmail.com
M contrib/test_decoding/expected/toast.out
M contrib/test_decoding/sql/toast.sql
M src/backend/replication/logical/decode.c
M src/backend/replication/logical/reorderbuffer.c
M src/include/replication/reorderbuffer.h
logical decoding: old/newtuple in spooled UPDATE changes was switched around.
commit : a50f50a652779c65607284110bf1046bbe4fb380
author : Andres Freund <andres@anarazel.de>
date : Sat, 5 Mar 2016 18:02:20 -0800
committer: Andres Freund <andres@anarazel.de>
date : Sat, 5 Mar 2016 18:02:20 -0800
Somehow I managed to flip the order of restoring old & new tuples when
de-spooling a change in a large transaction from disk. This happens to
only take effect when a change is spooled to disk which has old/new
versions of the tuple. That only is the case for UPDATEs where he
primary key changed or where replica identity is changed to FULL.
The tests didn't catch this because either spooled updates, or updates
that changed primary keys, were tested; not both at the same time.
Found while adding tests for the following commit.
Backpatch: 9.4, where logical decoding was added
M contrib/test_decoding/expected/ddl.out
M contrib/test_decoding/sql/ddl.sql
M src/backend/replication/logical/reorderbuffer.c
logical decoding: Tell reorderbuffer about all xids.
commit : 465dd92d98e42233df8bce6fbe8c90a65853536b
author : Andres Freund <andres@anarazel.de>
date : Sat, 5 Mar 2016 18:02:20 -0800
committer: Andres Freund <andres@anarazel.de>
date : Sat, 5 Mar 2016 18:02:20 -0800
Logical decoding's reorderbuffer keeps transactions in an LSN ordered
list for efficiency. To make that's efficiently possible upper-level
xids are forced to be logged before nested subtransaction xids. That
only works though if these records are all looked at: Unfortunately we
didn't do so for e.g. row level locks, which are otherwise uninteresting
for logical decoding.
This could lead to errors like:
"ERROR: subxact logged without previous toplevel record".
It's not sufficient to just look at row locking records, the xid could
appear first due to a lot of other types of records (which will trigger
the transaction to be marked logged with MarkCurrentTransactionIdLoggedIfAny).
So invent infrastructure to tell reorderbuffer about xids seen, when
they'd otherwise not pass through reorderbuffer.c.
Reported-By: Jarred Ward
Bug: #13844
Discussion: 20160105033249.1087.66040@wrigleys.postgresql.org
Backpatch: 9.4, where logical decoding was added
M contrib/test_decoding/Makefile
A contrib/test_decoding/expected/xact.out
A contrib/test_decoding/sql/xact.sql
M src/backend/replication/logical/decode.c
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/logical/snapbuild.c
M src/include/replication/reorderbuffer.h
Ignore recovery_min_apply_delay until recovery has reached consistent state
commit : a9613ee692463c6ff061227c3ca63075ea1f10f1
author : Fujii Masao <fujii@postgresql.org>
date : Sun, 6 Mar 2016 02:29:04 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Sun, 6 Mar 2016 02:29:04 +0900
Previously recovery_min_apply_delay was applied even before recovery
had reached consistency. This could cause us to wait a long time
unexpectedly for read-only connections to be allowed. It's problematic
because the standby was useless during that wait time.
This patch changes recovery_min_apply_delay so that it's applied once
the database has reached the consistent state. That is, even if the delay
is set, the standby tries to replay WAL records as fast as possible until
it has reached consistency.
Author: Michael Paquier
Reviewed-By: Julien Rouhaud
Reported-By: Greg Clough
Backpatch: 9.4, where recovery_min_apply_delay was added
Bug: #13770
Discussion: http://www.postgresql.org/message-id/20151111155006.2644.84564@wrigleys.postgresql.org
M doc/src/sgml/recovery-config.sgml
M src/backend/access/transam/xlog.c
Fix compile breakage due to 0315dfa8f4afa8390383119330ca0bf241be4ad4.
commit : 21050917d6c6f52ed3b06f0ee3fc210caaf42e8c
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 4 Mar 2016 12:11:30 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 4 Mar 2016 12:11:30 -0500
I wasn't careful enough when back-patching.
M src/bin/psql/tab-complete.c
Fix query-based tab completion for multibyte characters.
commit : 8de488d009e6280f4b80b634ee0fe79b6b34689e
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 4 Mar 2016 11:53:20 -0500
committer: Robert Haas <rhaas@postgresql.org>
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.
M src/bin/psql/tab-complete.c
Add 'tap_tests' flag in config_default.pl
commit : c7327561f75717205d0790e8629b5ea676b8b962
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 4 Mar 2016 12:59:47 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 4 Mar 2016 12:59:47 -0300
This makes the flag more visible for testers using the default file as a
template, increasing the likelyhood that the test suite will be run.
Also have the flag be displayed in the fake "configure" output, if set.
This patch is two new lines only, but perltidy decides to shift things
around which makes it appear a bit bigger.
Author: Michaël Paquier
Reviewed-by: Craig Ringer
Discussion: https://www.postgresql.org/message-id/CAB7nPqRet6UAP2APhZAZw%3DVhJ6w-Q-gGLdZkrOqFgd2vc9-ZDw%40mail.gmail.com
M src/tools/msvc/Solution.pm
M src/tools/msvc/config_default.pl
Force synchronous_commit=on in test_decoding's concurrent_ddl_dml.spec.
commit : d750b20101fddefa352cf4e1ce45d6d569bda8e8
author : Andres Freund <andres@anarazel.de>
date : Thu, 3 Mar 2016 17:09:08 -0800
committer: Andres Freund <andres@anarazel.de>
date : Thu, 3 Mar 2016 17:09:08 -0800
Otherwise running installcheck-force on a server with
synchronous_commit=off will result in the tests failing. All the other
tests already do so...
Backpatch: 9.4, where logical decoding was added
M contrib/test_decoding/specs/concurrent_ddl_dml.spec
Fix json_to_record() bug with nested objects.
commit : 597e41e45eec8038b8c2c1153d1d050bfafeacbf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Mar 2016 23:31:39 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Mar 2016 23:31:39 -0500
A thinko concerning nesting depth caused json_to_record() to produce bogus
output if a field of its input object contained a sub-object with a field
name matching one of the requested output column names. Per bug #13996
from Johann Visagie.
I added a regression test case based on his example, plus parallel tests
for json_to_recordset, jsonb_to_record, jsonb_to_recordset. The latter
three do not exhibit the same bug (which suggests that we may be missing
some opportunities to share code...) but testing seems like a good idea
in any case.
Back-patch to 9.4 where these functions were introduced.
M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/json.out
M src/test/regress/expected/jsonb.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/jsonb.sql
Improve error message for rejecting RETURNING clauses with dropped columns.
commit : 55965eb7d2f28d9325e80b7dd6f593bb22aa29b9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Feb 2016 19:11:38 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
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: 1456176604.17219.9.camel@jordogskog.no
M src/backend/rewrite/rewriteDefine.c
Fix typos
commit : 0bd51dee6e9c15f9283224cb0a475c20b7ef3e86
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 29 Feb 2016 18:11:58 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 29 Feb 2016 18:11:58 -0300
Author: Amit Langote
M src/backend/replication/syncrep.c
doc: document MANPATH as /usr/local/pgsql/share/man
commit : 8504ec929de7eb9ac49a019194f6ec2788caabba
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 29 Feb 2016 17:53:55 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.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
M doc/src/sgml/installation.sgml
Remove useless unary plus.
commit : 0a20d07ea6558484b51e57cbcab11f97180a3dee
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Feb 2016 10:48:40 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Feb 2016 10:48:40 -0500
It's harmless, but might confuse readers. Seems to have been introduced
in 6bc8ef0b7f1f1df3. Back-patch, just to avoid cosmetic cross-branch
differences.
Amit Langote
M src/backend/utils/init/postinit.c
Fix incorrect varlevelsup in security_barrier_replace_vars().
commit : 9b69d5c1daeb62804eeaeab2f804191dbe0a943d
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 29 Feb 2016 12:34:33 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 29 Feb 2016 12:34:33 +0000
When converting an RTE with securityQuals into a security barrier
subquery RTE, ensure that the Vars in the new subquery's targetlist
all have varlevelsup = 0 so that they correctly refer to the
underlying base relation being wrapped.
The original code was creating new Vars by copying them from existing
Vars referencing the base relation found elsewhere in the query, but
failed to account for the fact that such Vars could come from sublink
subqueries, and hence have varlevelsup > 0. In practice it looks like
this could only happen with nested security barrier views, where the
outer view has a WHERE clause containing a correlated subquery, due to
the order in which the Vars are processed.
Bug: #13988
Reported-by: Adam Guthrie
Backpatch-to: 9.4, where updatable SB views were introduced
M src/backend/optimizer/prep/prepsecurity.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql
Avoid multiple free_struct_lconv() calls on same data.
commit : 80c925c7b4efcd80a8c648ca94ba1fabbd2863ae
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Feb 2016 23:39:20 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
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.
M src/backend/utils/adt/pg_locale.c
Fix typos
commit : f6a605702aa15f7a49da1ec0ab60a8abd956c139
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 25 Feb 2016 20:50:20 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 25 Feb 2016 20:50:20 -0300
Backpatch to: 9.4
M src/include/replication/reorderbuffer.h
MSVC: Clean tmp_check directory of pg_controldata test suite.
commit : 78e329340e0518894f5a865c6bb7c0fc77a577b6
author : Noah Misch <noah@leadboat.com>
date : Wed, 24 Feb 2016 23:41:33 -0500
committer: Noah Misch <noah@leadboat.com>
date : Wed, 24 Feb 2016 23:41:33 -0500
Back-patch to 9.4, where the suite was introduced.
M src/tools/msvc/clean.bat
Fix wording in the Tutorial document.
commit : 5c4973118755c6294a1c823bb95427dadbb1c28e
author : Tatsuo Ishii <ishii@postgresql.org>
date : Sun, 21 Feb 2016 09:04:59 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Sun, 21 Feb 2016 09:04:59 +0900
With suggentions from Tom Lane.
M doc/src/sgml/start.sgml
Correct StartupSUBTRANS for page wraparound
commit : 6830cae5f862276a52dc8a50edf1d34996539a3c
author : Simon Riggs <simon@2ndQuadrant.com>
date : Fri, 19 Feb 2016 08:32:28 +0000
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Fri, 19 Feb 2016 08:32:28 +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
M src/backend/access/transam/subtrans.c
pg_upgrade: suppress creation of delete script
commit : bec4d0ffb2fb50d2d36dca99599514eef315c865
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 18 Feb 2016 18:32:26 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 18 Feb 2016 18:32:26 -0500
Suppress creation of the pg_upgrade delete script when the new data
directory is inside the old data directory.
Reported-by: IRC
Backpatch-through: 9.3, where delete script tests were added
M contrib/pg_upgrade/check.c
Fix multiple bugs in contrib/pgstattuple's pgstatindex() function.
commit : b7547166fec6b103a6839018f2f7a3500e9bc842
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 18 Feb 2016 15:40:35 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
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.
M contrib/pgstattuple/expected/pgstattuple.out
M contrib/pgstattuple/pgstatindex.c
M contrib/pgstattuple/sql/pgstattuple.sql
M doc/src/sgml/pgstattuple.sgml
Make plpython cope with funny characters in function names.
commit : f461fa7d07389e09dcc46d994cac02e52ce89e6b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Feb 2016 21:08:15 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
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.
M src/pl/plpython/expected/plpython_test.out
M src/pl/plpython/plpy_procedure.c
M src/pl/plpython/sql/plpython_test.sql
Improve documentation about CREATE INDEX CONCURRENTLY.
commit : da5cf6ace1cf0b14085242696b89742d3979920a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Feb 2016 13:43:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
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.
M doc/src/sgml/ref/create_index.sgml
Improve wording in the planner doc
commit : 77c616a79dc9e852fa66cc69e6b4997511cc4dfa
author : Tatsuo Ishii <ishii@postgresql.org>
date : Tue, 16 Feb 2016 15:36:52 +0900
committer: Tatsuo Ishii <ishii@postgresql.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.
M doc/src/sgml/planstats.sgml
Correct the formulas for System V IPC parameters SEMMNI and SEMMNS in docs.
commit : 2f66e29db40d24c201094c2921411f894692635e
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 16 Feb 2016 14:49:47 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 16 Feb 2016 14:49:47 +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://www.postgresql.org/message-id/20160203.125119.66820697.horiguchi.kyotaro@lab.ntt.co.jp
M doc/src/sgml/runtime.sgml
pgbench: avoid FD_ISSET on an invalid file descriptor
commit : ccbb01ff4a4cac8622930ef6475ed3cf8281e4c7
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 15 Feb 2016 20:33:43 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
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.
M contrib/pgbench/pgbench.c
Suppress compiler warnings about useless comparison of unsigned to zero.
commit : e3ad502740e818335a930c38528b747edebf3684
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 15 Feb 2016 17:11:52 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
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.
M src/backend/regex/regc_lex.c
M src/include/regex/regcustom.h
Accept pg_ctl timeout from the PGCTLTIMEOUT environment variable.
commit : 4492ab53b360eaebbd5bcfec2fb36d753da3e199
author : Noah Misch <noah@leadboat.com>
date : Wed, 10 Feb 2016 20:34:02 -0500
committer: Noah Misch <noah@leadboat.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.
M doc/src/sgml/ref/pg_ctl-ref.sgml
M src/bin/pg_ctl/pg_ctl.c
Avoid use of sscanf() to parse ispell dictionary files.
commit : 19e469410a8ccdc0c0d6cb362a02e35d1bb65c8a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 10 Feb 2016 19:30:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
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.
M src/backend/tsearch/spell.c