Stamp 9.4.1.
commit : d0f83327d3739a45102fdd486947248c70e0249d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Feb 2015 15:42:55 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Feb 2015 15:42:55 -0500
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
Last-minute updates for release notes.
commit : 3face5a8d9ffbb5d37b5c29949d4363bd64f7446
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Feb 2015 11:24:02 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Feb 2015 11:24:02 -0500
Add entries for security issues.
Security: CVE-2015-0241 through CVE-2015-0244
M doc/src/sgml/release-9.0.sgml
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
Be more careful to not lose sync in the FE/BE protocol.
commit : 57ec87c6b8dcb5258aae414fbdbeaf6eaf09feb1
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 2 Feb 2015 17:08:56 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 2 Feb 2015 17:08:56 +0200
If any error occurred while we were in the middle of reading a protocol
message from the client, we could lose sync, and incorrectly try to
interpret a part of another message as a new protocol message. That will
usually lead to an "invalid frontend message" error that terminates the
connection. However, this is a security issue because an attacker might
be able to deliberately cause an error, inject a Query message in what's
supposed to be just user data, and have the server execute it.
We were quite careful to not have CHECK_FOR_INTERRUPTS() calls or other
operations that could ereport(ERROR) in the middle of processing a message,
but a query cancel interrupt or statement timeout could nevertheless cause
it to happen. Also, the V2 fastpath and COPY handling were not so careful.
It's very difficult to recover in the V2 COPY protocol, so we will just
terminate the connection on error. In practice, that's what happened
previously anyway, as we lost protocol sync.
To fix, add a new variable in pqcomm.c, PqCommReadingMsg, that is set
whenever we're in the middle of reading a message. When it's set, we cannot
safely ERROR out and continue running, because we might've read only part
of a message. PqCommReadingMsg acts somewhat similarly to critical sections
in that if an error occurs while it's set, the error handler will force the
connection to be terminated, as if the error was FATAL. It's not
implemented by promoting ERROR to FATAL in elog.c, like ERROR is promoted
to PANIC in critical sections, because we want to be able to use
PG_TRY/CATCH to recover and regain protocol sync. pq_getmessage() takes
advantage of that to prevent an OOM error from terminating the connection.
To prevent unnecessary connection terminations, add a holdoff mechanism
similar to HOLD/RESUME_INTERRUPTS() that can be used hold off query cancel
interrupts, but still allow die interrupts. The rules on which interrupts
are processed when are now a bit more complicated, so refactor
ProcessInterrupts() and the calls to it in signal handlers so that the
signal handlers always call it if ImmediateInterruptOK is set, and
ProcessInterrupts() can decide to not do anything if the other conditions
are not met.
Reported by Emil Lenngren. Patch reviewed by Noah Misch and Andres Freund.
Backpatch to all supported versions.
Security: CVE-2015-0244
M src/backend/commands/copy.c
M src/backend/libpq/auth.c
M src/backend/libpq/pqcomm.c
M src/backend/postmaster/postmaster.c
M src/backend/replication/walsender.c
M src/backend/storage/lmgr/proc.c
M src/backend/tcop/fastpath.c
M src/backend/tcop/postgres.c
M src/backend/utils/error/elog.c
M src/backend/utils/init/globals.c
M src/include/libpq/libpq.h
M src/include/miscadmin.h
M src/include/tcop/fastpath.h
Prevent Valgrind Memcheck errors around px_acquire_system_randomness().
commit : ca84dfa90e9929737bda7393f88b488cb7161147
author : Noah Misch <noah@leadboat.com>
date : Mon, 2 Feb 2015 10:00:45 -0500
committer: Noah Misch <noah@leadboat.com>
date : Mon, 2 Feb 2015 10:00:45 -0500
This function uses uninitialized stack and heap buffers as supplementary
entropy sources. Mark them so Memcheck will not complain. Back-patch
to 9.4, where Valgrind Memcheck cooperation first appeared.
Marko Tiikkaja
M contrib/pgcrypto/random.c
Cherry-pick security-relevant fixes from upstream imath library.
commit : 258e294dbbd8cb55b7825759adee3156f6aaa744
author : Noah Misch <noah@leadboat.com>
date : Mon, 2 Feb 2015 10:00:45 -0500
committer: Noah Misch <noah@leadboat.com>
date : Mon, 2 Feb 2015 10:00:45 -0500
This covers alterations to buffer sizing and zeroing made between imath
1.3 and imath 1.20. Valgrind Memcheck identified the buffer overruns
and reliance on uninitialized data; their exploit potential is unknown.
Builds specifying --with-openssl are unaffected, because they use the
OpenSSL BIGNUM facility instead of imath. Back-patch to 9.0 (all
supported versions).
Security: CVE-2015-0243
M contrib/pgcrypto/imath.c
Fix buffer overrun after incomplete read in pullf_read_max().
commit : 82806cf4e5442db51f1ca62631ea15b3343a9a76
author : Noah Misch <noah@leadboat.com>
date : Mon, 2 Feb 2015 10:00:45 -0500
committer: Noah Misch <noah@leadboat.com>
date : Mon, 2 Feb 2015 10:00:45 -0500
Most callers pass a stack buffer. The ensuing stack smash can crash the
server, and we have not ruled out the viability of attacks that lead to
privilege escalation. Back-patch to 9.0 (all supported versions).
Marko Tiikkaja
Security: CVE-2015-0243
M contrib/pgcrypto/expected/pgp-info.out
M contrib/pgcrypto/expected/pgp-pubkey-decrypt.out
M contrib/pgcrypto/mbuf.c
M contrib/pgcrypto/sql/pgp-pubkey-decrypt.sql
port/snprintf(): fix overflow and do padding
commit : 2ac95c83ce9321cb428bf3508a606df31c762ef1
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 2 Feb 2015 10:00:45 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 2 Feb 2015 10:00:45 -0500
Prevent port/snprintf() from overflowing its local fixed-size
buffer and pad to the desired number of digits with zeros, even
if the precision is beyond the ability of the native sprintf().
port/snprintf() is only used on systems that lack a native
snprintf().
Reported by Bruce Momjian. Patch by Tom Lane. Backpatch to all
supported versions.
Security: CVE-2015-0242
M src/port/snprintf.c
to_char(): prevent writing beyond the allocated buffer
commit : 56d2bee9db219b21592c6fef9d29ce1d5e3c6c59
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 2 Feb 2015 10:00:45 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 2 Feb 2015 10:00:45 -0500
Previously very long localized month and weekday strings could
overflow the allocated buffers, causing a server crash.
Reported and patch reviewed by Noah Misch. Backpatch to all
supported versions.
Security: CVE-2015-0241
M src/backend/utils/adt/formatting.c
to_char(): prevent accesses beyond the allocated buffer
commit : 1628a0bbfa2e30cd52daaa3ae78961d301adad2f
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 2 Feb 2015 10:00:44 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 2 Feb 2015 10:00:44 -0500
Previously very long field masks for floats could access memory
beyond the existing buffer allocated to hold the result.
Reported by Andres Freund and Peter Geoghegan. Backpatch to all
supported versions.
Security: CVE-2015-0241
M src/backend/utils/adt/formatting.c
Doc: fix syntax description for psql's \setenv.
commit : e87dedc0c492a4dcc45ec4e424027a1180d7ebb6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Feb 2015 00:18:54 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Feb 2015 00:18:54 -0500
The variable name isn't optional --- looks like a copy-and-paste-o from
the \set command, where it is.
Dilip Kumar
M doc/src/sgml/ref/psql-ref.sgml
Translation updates
commit : 1de0702d92ed4288ae69c2b3587dddc023eb966f
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 1 Feb 2015 23:18:42 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 1 Feb 2015 23:18:42 -0500
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 19c72ea8d856d7b1d4f5d759a766c8206bf9ce53
M src/backend/nls.mk
M src/backend/po/de.po
M src/backend/po/es.po
A src/backend/po/id.po
M src/backend/po/ru.po
M src/bin/initdb/po/de.po
M src/bin/initdb/po/ru.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/pt_BR.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_config/po/es.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_resetxlog/po/es.po
M src/bin/psql/po/de.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/de.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/es.po
M src/pl/plpython/po/de.po
M src/pl/plpython/po/ru.po
M src/pl/tcl/po/es.po
doc: Improve claim about location of pg_service.conf
commit : 0ca8cc581e1fd097005bb31bfde516ce38c83d6e
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 1 Feb 2015 22:36:44 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 1 Feb 2015 22:36:44 -0500
The previous wording claimed that the file was always in /etc, but of
course this varies with the installation layout. Write instead that it
can be found via `pg_config --sysconfdir`. Even though this is still
somewhat incorrect because it doesn't account of moved installations, it
at least conveys that the location depends on the installation.
M doc/src/sgml/libpq.sgml
Release notes for 9.4.1, 9.3.6, 9.2.10, 9.1.15, 9.0.19.
commit : e29bbb9c6eb66e67597d70db747f33c7bc365ac8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 1 Feb 2015 16:53:17 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 1 Feb 2015 16:53:17 -0500
M doc/src/sgml/release-9.0.sgml
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
Fix documentation of psql's ECHO all mode.
commit : 02d0937f6467604e52833555fd35c5900936021d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 31 Jan 2015 18:35:17 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 31 Jan 2015 18:35:17 -0500
"ECHO all" is ignored for interactive input, and has been for a very long
time, though possibly not for as long as the documentation has claimed the
opposite. Fix that, and also note that empty lines aren't echoed, which
while dubious is another longstanding behavior (it's embedded in our
regression test files for one thing). Per bug #12721 from Hans Ginzel.
In HEAD, also improve the code comments in this area, and suppress an
unnecessary fflush(stdout) when we're not echoing. That would likely
be safe to back-patch, but I'll not risk it mere hours before a release
wrap.
M doc/src/sgml/ref/psql-ref.sgml
Update time zone data files to tzdata release 2015a.
commit : c2b06ab177577d05655ec57239d9a7f2c6e7d9cf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 Jan 2015 22:45:44 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 Jan 2015 22:45:44 -0500
DST law changes in Chile and Mexico (state of Quintana Roo).
Historical changes for Iceland.
M src/timezone/data/antarctica
M src/timezone/data/asia
M src/timezone/data/backward
M src/timezone/data/backzone
M src/timezone/data/europe
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/Default
Fix jsonb Unicode escape processing, and in consequence disallow \u0000.
commit : 4cbf390d5f0339f9846d4492b15f98b41bfffe12
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 Jan 2015 14:44:49 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 Jan 2015 14:44:49 -0500
We've been trying to support \u0000 in JSON values since commit
78ed8e03c67d7333, and have introduced increasingly worse hacks to try to
make it work, such as commit 0ad1a816320a2b53. However, it fundamentally
can't work in the way envisioned, because the stored representation looks
the same as for \\u0000 which is not the same thing at all. It's also
entirely bogus to output \u0000 when de-escaped output is called for.
The right way to do this would be to store an actual 0x00 byte, and then
throw error only if asked to produce de-escaped textual output. However,
getting to that point seems likely to take considerable work and may well
never be practical in the 9.4.x series.
To preserve our options for better behavior while getting rid of the nasty
side-effects of 0ad1a816320a2b53, revert that commit in toto and instead
throw error if \u0000 is used in a context where it needs to be de-escaped.
(These are the same contexts where non-ASCII Unicode escapes throw error
if the database encoding isn't UTF8, so this behavior is by no means
without precedent.)
In passing, make both the \u0000 case and the non-ASCII Unicode case report
ERRCODE_UNTRANSLATABLE_CHARACTER / "unsupported Unicode escape sequence"
rather than claiming there's something wrong with the input syntax.
Back-patch to 9.4, where we have to do something because 0ad1a816320a2b53
broke things for many cases having nothing to do with \u0000. 9.3 also has
bogus behavior, but only for that specific escape value, so given the lack
of field complaints it seems better to leave 9.3 alone.
M doc/src/sgml/json.sgml
M doc/src/sgml/release-9.4.sgml
M src/backend/utils/adt/json.c
M src/test/regress/expected/json.out
M src/test/regress/expected/json_1.out
M src/test/regress/expected/jsonb.out
M src/test/regress/expected/jsonb_1.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/jsonb.sql
Fix Coverity warning about contrib/pgcrypto's mdc_finish().
commit : 70da7aeba1f845d2f0bb864031e0bea21b384ca7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 Jan 2015 13:04:59 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 Jan 2015 13:04:59 -0500
Coverity points out that mdc_finish returns a pointer to a local buffer
(which of course is gone as soon as the function returns), leaving open
a risk of misbehaviors possibly as bad as a stack overwrite.
In reality, the only possible call site is in process_data_packets()
which does not examine the returned pointer at all. So there's no
live bug, but nonetheless the code is confusing and risky. Refactor
to avoid the issue by letting process_data_packets() call mdc_finish()
directly instead of going through the pullf_read() API.
Although this is only cosmetic, it seems good to back-patch so that
the logic in pgp-decrypt.c stays in sync across all branches.
Marko Kreen
M contrib/pgcrypto/pgp-decrypt.c
Fix assorted oversights in range selectivity estimation.
commit : b6a164e5cb389a52b2187bbacdcdaab46e236418
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 Jan 2015 12:30:41 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 Jan 2015 12:30:41 -0500
calc_rangesel() failed outright when comparing range variables to empty
constant ranges with < or >=, as a result of missing cases in a switch.
It also produced a bogus estimate for > comparison to an empty range.
On top of that, the >= and > cases were mislabeled throughout. For
nonempty constant ranges, they managed to produce the right answers
anyway as a result of counterbalancing typos.
Also, default_range_selectivity() omitted cases for elem <@ range,
range &< range, and range &> range, so that rather dubious defaults
were applied for these operators.
In passing, rearrange the code in rangesel() so that the elem <@ range
case is handled in a less opaque fashion.
Report and patch by Emre Hasegeli, some additional work by me
M src/backend/utils/adt/rangetypes_selfuncs.c
M src/include/catalog/pg_operator.h
M src/test/regress/expected/rangetypes.out
M src/test/regress/sql/rangetypes.sql
Fix query-duration memory leak with GIN rescans.
commit : dc40ca696313ee8f7e75bb7628990e6e138b0e01
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 30 Jan 2015 17:58:23 +0100
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 30 Jan 2015 17:58:23 +0100
The requiredEntries / additionalEntries arrays were not freed in
freeScanKeys() like other per-key stuff.
It's not obvious, but startScanKey() was only ever called after the keys
have been initialized with ginNewScanKey(). That's why it doesn't need to
worry about freeing existing arrays. The ginIsNewKey() test in gingetbitmap
was never true, because ginrescan free's the existing keys, and it's not OK
to call gingetbitmap twice in a row without calling ginrescan in between.
To make that clear, remove the unnecessary ginIsNewKey(). And just to be
extra sure that nothing funny happens if there is an existing key after all,
call freeScanKeys() to free it if it exists. This makes the code more
straightforward.
(I'm seeing other similar leaks in testing a query that rescans an GIN index
scan, but that's a different issue. This just fixes the obvious leak with
those two arrays.)
Backpatch to 9.4, where GIN fast scan was added.
M src/backend/access/gin/ginget.c
M src/backend/access/gin/ginscan.c
M src/include/access/gin_private.h
Allow pg_dump to use jobs and serializable transactions together.
commit : cb0168528280fcf5ad5fc6f745603080b979511a
author : Kevin Grittner <kgrittn@postgresql.org>
date : Fri, 30 Jan 2015 08:57:53 -0600
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Fri, 30 Jan 2015 08:57:53 -0600
Since 9.3, when the --jobs option was introduced, using it together
with the --serializable-deferrable option generated multiple
errors. We can get correct behavior by allowing the connection
which acquires the snapshot to use SERIALIZABLE, READ ONLY,
DEFERRABLE and pass that to the workers running the other
connections using REPEATABLE READ, READ ONLY. This is a bit of a
kluge since the SERIALIZABLE behavior is achieved by running some
of the participating connections at a different isolation level,
but it is a simple and safe change, suitable for back-patching.
This will be followed by a proposal for a more invasive fix with
some slight behavioral changes on just the master branch, based on
suggestions from Andres Freund, but the kluge will be applied to
master until something is agreed along those lines.
Back-patched to 9.3, where the --jobs option was added.
Based on report from Alexander Korotkov
M src/bin/pg_dump/pg_dump.c
Fix BuildIndexValueDescription for expressions
commit : b1700055c2fb60292067a9e39554dedce68569f7
author : Stephen Frost <sfrost@snowman.net>
date : Thu, 29 Jan 2015 21:59:43 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Thu, 29 Jan 2015 21:59:43 -0500
In 804b6b6db4dcfc590a468e7be390738f9f7755fb we modified
BuildIndexValueDescription to pay attention to which columns are visible
to the user, but unfortunatley that commit neglected to consider indexes
which are built on expressions.
Handle error-reporting of violations of constraint indexes based on
expressions by not returning any detail when the user does not have
table-level SELECT rights.
Backpatch to 9.0, as the prior commit was.
Pointed out by Tom.
M src/backend/access/index/genam.c
Handle unexpected query results, especially NULLs, safely in connectby().
commit : 202621d0471b56c3355af1f2134cf868a6f9b4bd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 29 Jan 2015 20:18:37 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 29 Jan 2015 20:18:37 -0500
connectby() didn't adequately check that the constructed SQL query returns
what it's expected to; in fact, since commit 08c33c426bfebb32 it wasn't
checking that at all. This could result in a null-pointer-dereference
crash if the constructed query returns only one column instead of the
expected two. Less excitingly, it could also result in surprising data
conversion failures if the constructed query returned values that were
not I/O-conversion-compatible with the types specified by the query
calling connectby().
In all branches, insist that the query return at least two columns;
this seems like a minimal sanity check that can't break any reasonable
use-cases.
In HEAD, insist that the constructed query return the types specified by
the outer query, including checking for typmod incompatibility, which the
code never did even before it got broken. This is to hide the fact that
the implementation does a conversion to text and back; someday we might
want to improve that.
In back branches, leave that alone, since adding a type check in a minor
release is more likely to break things than make people happy. Type
inconsistencies will continue to work so long as the actual type and
declared type are I/O representation compatible, and otherwise will fail
the same way they used to.
Also, in all branches, be on guard for NULL results from the constructed
query, which formerly would cause null-pointer dereference crashes.
We now print the row with the NULL but don't recurse down from it.
In passing, get rid of the rather pointless idea that
build_tuplestore_recursively() should return the same tuplestore that's
passed to it.
Michael Paquier, adjusted somewhat by me
M contrib/tablefunc/expected/tablefunc.out
M contrib/tablefunc/sql/tablefunc.sql
M contrib/tablefunc/tablefunc.c
Properly terminate the array returned by GetLockConflicts().
commit : 76e962750f0b2557e6a356c35d7c66fe8fb263b0
author : Andres Freund <andres@anarazel.de>
date : Thu, 29 Jan 2015 17:49:03 +0100
committer: Andres Freund <andres@anarazel.de>
date : Thu, 29 Jan 2015 17:49:03 +0100
GetLockConflicts() has for a long time not properly terminated the
returned array. During normal processing the returned array is zero
initialized which, while not pretty, is sufficient to be recognized as
a invalid virtual transaction id. But the HotStandby case is more than
aesthetically broken: The allocated (and reused) array is neither
zeroed upon allocation, nor reinitialized, nor terminated.
Not having a terminating element means that the end of the array will
not be recognized and that recovery conflict handling will thus read
ahead into adjacent memory. Only terminating when hitting memory
content that looks like a invalid virtual transaction id. Luckily
this seems so far not have caused significant problems, besides making
recovery conflict more expensive.
Discussion: 20150127142713.GD29457@awork2.anarazel.de
Backpatch into all supported branches.
M src/backend/storage/lmgr/lock.c
Fix bug where GIN scan keys were not initialized with gin_fuzzy_search_limit.
commit : 28a37deab30b6946558de3cafe78daa4823e23c3
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 29 Jan 2015 19:35:55 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 29 Jan 2015 19:35:55 +0200
When gin_fuzzy_search_limit was used, we could jump out of startScan()
without calling startScanKey(). That was harmless in 9.3 and below, because
startScanKey()() didn't do anything interesting, but in 9.4 it initializes
information needed for skipping entries (aka GIN fast scans), and you
readily get a segfault if it's not done. Nevertheless, it was clearly wrong
all along, so backpatch all the way to 9.1 where the early return was
introduced.
(AFAICS startScanKey() did nothing useful in 9.3 and below, because the
fields it initialized were already initialized in ginFillScanKey(), but I
don't dare to change that in a minor release. ginFillScanKey() is always
called in gingetbitmap() even though there's a check there to see if the
scan keys have already been initialized, because they never are; ginrescan()
free's them.)
In the passing, remove unnecessary if-check from the second inner loop in
startScan(). We already check in the first loop that the condition is true
for all entries.
Reported by Olaf Gawenda, bug #12694, Backpatch to 9.1 and above, although
AFAICS it causes a live bug only in 9.4.
M src/backend/access/gin/ginget.c
Clean up range-table building in copy.c
commit : b40fe42781f524c37073275e089edf795fbc3d66
author : Stephen Frost <sfrost@snowman.net>
date : Wed, 28 Jan 2015 17:42:51 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Wed, 28 Jan 2015 17:42:51 -0500
Commit 804b6b6db4dcfc590a468e7be390738f9f7755fb added the build of a
range table in copy.c to initialize the EState es_range_table since it
can be needed in error paths. Unfortunately, that commit didn't
appreciate that some code paths might end up not initializing the rte
which is used to build the range table.
Fix that and clean up a couple others things along the way- build it
only once and don't explicitly set it on the !is_from path as it
doesn't make any sense there (cstate is palloc0'd, so this isn't an
issue from an initializing standpoint either).
The prior commit went back to 9.0, but this only goes back to 9.1 as
prior to that the range table build happens immediately after building
the RTE and therefore doesn't suffer from this issue.
Pointed out by Robert.
M src/backend/commands/copy.c
Fix column-privilege leak in error-message paths
commit : 3cc74a3d61f26e6558ee662b6700f74962bd1d8b
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 12 Jan 2015 17:04:11 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 12 Jan 2015 17:04:11 -0500
While building error messages to return to the user,
BuildIndexValueDescription, ExecBuildSlotValueDescription and
ri_ReportViolation would happily include the entire key or entire row in
the result returned to the user, even if the user didn't have access to
view all of the columns being included.
Instead, include only those columns which the user is providing or which
the user has select rights on. If the user does not have any rights
to view the table or any of the columns involved then no detail is
provided and a NULL value is returned from BuildIndexValueDescription
and ExecBuildSlotValueDescription. Note that, for key cases, the user
must have access to all of the columns for the key to be shown; a
partial key will not be returned.
Back-patch all the way, as column-level privileges are now in all
supported versions.
This has been assigned CVE-2014-8161, but since the issue and the patch
have already been publicized on pgsql-hackers, there's no point in trying
to hide this commit.
M src/backend/access/index/genam.c
M src/backend/access/nbtree/nbtinsert.c
M src/backend/commands/copy.c
M src/backend/commands/matview.c
M src/backend/commands/trigger.c
M src/backend/executor/execMain.c
M src/backend/executor/execUtils.c
M src/backend/utils/adt/ri_triggers.c
M src/backend/utils/sort/tuplesort.c
M src/test/regress/expected/privileges.out
M src/test/regress/sql/privileges.sql
Fix NUMERIC field access macros to treat NaNs consistently.
commit : 3d5e857ab1ed7dbac28e6c0aea580d1dfb9dc9ed
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 Jan 2015 12:06:36 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 Jan 2015 12:06:36 -0500
Commit 145343534c153d1e6c3cff1fa1855787684d9a38 arranged to store numeric
NaN values as short-header numerics, but the field access macros did not
get the memo: they thought only "SHORT" numerics have short headers.
Most of the time this makes no difference because we don't access the
weight or dscale of a NaN; but numeric_send does that. As pointed out
by Andrew Gierth, this led to fetching uninitialized bytes.
AFAICS this could not have any worse consequences than that; in particular,
an unaligned stored numeric would have been detoasted by PG_GETARG_NUMERIC,
so that there's no risk of a fetch off the end of memory. Still, the code
is wrong on its own terms, and it's not hard to foresee future changes that
might expose us to real risks. So back-patch to all affected branches.
M src/backend/utils/adt/numeric.c
Fix volatile-safety issue in dblink's materializeQueryResult().
commit : e4021a2ba647e61340b096d49b1a657eeafdc617
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 26 Jan 2015 15:17:36 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 26 Jan 2015 15:17:36 -0500
Some fields of the sinfo struct are modified within PG_TRY and then
referenced within PG_CATCH, so as with recent patch to async.c, "volatile"
is necessary for strict POSIX compliance; and that propagates to a couple
of subroutines as well as materializeQueryResult() itself. I think the
risk of actual issues here is probably higher than in async.c, because
storeQueryResult() is likely to get inlined into materializeQueryResult(),
leaving the compiler free to conclude that its stores into sinfo fields are
dead code.
M contrib/dblink/dblink.c
Fix volatile-safety issue in pltcl_SPI_execute_plan().
commit : dd9d78f595a124591eadb97d71813fc71fd767a5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 26 Jan 2015 12:18:25 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 26 Jan 2015 12:18:25 -0500
The "callargs" variable is modified within PG_TRY and then referenced
within PG_CATCH, which is exactly the coding pattern we've now found
to be unsafe. Marking "callargs" volatile would be problematic because
it is passed by reference to some Tcl functions, so fix the problem
by not modifying it within PG_TRY. We can just postpone the free()
till we exit the PG_TRY construct, as is already done elsewhere in this
same file.
Also, fix failure to free(callargs) when exiting on too-many-arguments
error. This is only a minor memory leak, but a leak nonetheless.
In passing, remove some unnecessary "volatile" markings in the same
function. Those doubtless are there because gcc 2.95.3 whinged about
them, but we now know that its algorithm for complaining is many bricks
shy of a load.
This is certainly a live bug with compilers that optimize similarly
to current gcc, so back-patch to all active branches.
M src/pl/tcl/pltcl.c
Fix volatile-safety issue in asyncQueueReadAllNotifications().
commit : df923be03d1123bfbc701dd9cf85cd44e1e84335
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 26 Jan 2015 11:57:36 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 26 Jan 2015 11:57:36 -0500
The "pos" variable is modified within PG_TRY and then referenced
within PG_CATCH, so for strict POSIX conformance it must be marked
volatile. Superficially the code looked safe because pos's address
was taken, which was sufficient to force it into memory ... but it's
not sufficient to ensure that the compiler applies updates exactly
where the program text says to. The volatility marking has to extend
into a couple of subroutines too, but I think that's probably a good
thing because the risk of out-of-order updates is mostly in those
subroutines not asyncQueueReadAllNotifications() itself. In principle
the compiler could have re-ordered operations such that an error could
be thrown while "pos" had an incorrect value.
It's unclear how real the risk is here, but for safety back-patch
to all active branches.
M src/backend/commands/async.c
Further cleanup of ReorderBufferCommit().
commit : f86a8955e8aae4da854e65b87b588e37ecb45918
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Jan 2015 22:49:59 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Jan 2015 22:49:59 -0500
On closer inspection, we can remove the "volatile" qualifier on
"using_subtxn" so long as we initialize that before the PG_TRY block,
which there's no particularly good reason not to do.
Also, push the "change" variable inside the PG_TRY so as to remove
all question of whether it needs "volatile", and remove useless
early initializations of "snapshow_now" and "using_subtxn".
M src/backend/replication/logical/reorderbuffer.c
Clean up assorted issues in ALTER SYSTEM coding.
commit : 138a5c4a909dc96c0f3a95123639ee7e014c7f38
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Jan 2015 20:19:07 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Jan 2015 20:19:07 -0500
Fix unsafe use of a non-volatile variable in PG_TRY/PG_CATCH in
AlterSystemSetConfigFile(). While at it, clean up a bundle of other
infelicities and outright bugs, including corner-case-incorrect linked list
manipulation, a poorly designed and worse documented parse-and-validate
function (which even included some randomly chosen hard-wired substitutes
for the specified elevel in one code path ... wtf?), direct use of open()
instead of fd.c's facilities, inadequate checking of write()'s return
value, and generally poorly written commentary.
M src/backend/utils/misc/guc-file.l
M src/backend/utils/misc/guc.c
Fix unsafe coding in ReorderBufferCommit().
commit : 91964c3ed1c49d9a8670d3f85a660181cc541c7c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jan 2015 13:25:22 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jan 2015 13:25:22 -0500
"iterstate" must be marked volatile since it's changed inside the PG_TRY
block and then used in the PG_CATCH stanza. Noted by Mark Wilding of
Salesforce. (We really need to see if we can't get the C compiler to warn
about this.)
Also, reset iterstate to NULL after the mainline ReorderBufferIterTXNFinish
call, to ensure the PG_CATCH block doesn't try to do that a second time.
M src/backend/replication/logical/reorderbuffer.c
Replace a bunch more uses of strncpy() with safer coding.
commit : d51d4ff311d01de8521acedb0a6f7c242648a231
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jan 2015 13:05:45 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jan 2015 13:05:45 -0500
strncpy() has a well-deserved reputation for being unsafe, so make an
effort to get rid of nearly all occurrences in HEAD.
A large fraction of the remaining uses were passing length less than or
equal to the known strlen() of the source, in which case no null-padding
can occur and the behavior is equivalent to memcpy(), though doubtless
slower and certainly harder to reason about. So just use memcpy() in
these cases.
In other cases, use either StrNCpy() or strlcpy() as appropriate (depending
on whether padding to the full length of the destination buffer seems
useful).
I left a few strncpy() calls alone in the src/timezone/ code, to keep it
in sync with upstream (the IANA tzcode distribution). There are also a
few such calls in ecpg that could possibly do with more analysis.
AFAICT, none of these changes are more than cosmetic, except for the four
occurrences in fe-secure-openssl.c, which are in fact buggy: an overlength
source leads to a non-null-terminated destination buffer and ensuing
misbehavior. These don't seem like security issues, first because no stack
clobber is possible and second because if your values of sslcert etc are
coming from untrusted sources then you've got problems way worse than this.
Still, it's undesirable to have unpredictable behavior for overlength
inputs, so back-patch those four changes to all active branches.
M src/interfaces/libpq/fe-secure.c
In pg_regress, remove the temporary installation upon successful exit.
commit : 3de9f22ace195e9fc1b7208a64290ab5e3404358
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Jan 2015 23:44:22 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Jan 2015 23:44:22 -0500
This results in a very substantial reduction in disk space usage during
"make check-world", since that sequence involves creation of numerous
temporary installations. It should also help a bit in the buildfarm, even
though the buildfarm script doesn't create as many temp installations,
because the current script misses deleting some of them; and anyway it
seems better to do this once in one place rather than expecting that
script to get it right every time.
In 9.4 and HEAD, also undo the unwise choice in commit b1aebbb6a86e96d7
to report strerror(errno) after a rmtree() failure. rmtree has already
reported that, possibly for multiple failures with distinct errnos; and
what's more, by the time it returns there is no good reason to assume
that errno still reflects the last reportable error. So reporting errno
here is at best redundant and at worst badly misleading.
Back-patch to all supported branches, so that future revisions of the
buildfarm script can rely on this behavior.
M src/test/regress/pg_regress.c
Adjust "pgstat wait timeout" message to be a translatable LOG message.
commit : 3387cbbcb2d1a63ed6e1b1dd778b11dac64be32d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Jan 2015 23:01:36 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Jan 2015 23:01:36 -0500
Per discussion, change the log level of this message to be LOG not WARNING.
The main point of this change is to avoid causing buildfarm run failures
when the stats collector is exceptionally slow to respond, which it not
infrequently is on some of the smaller/slower buildfarm members.
This change does lose notice to an interactive user when his stats query
is looking at out-of-date stats, but the majority opinion (not necessarily
that of yours truly) is that WARNING messages would probably not get
noticed anyway on heavily loaded production systems. A LOG message at
least ensures that the problem is recorded somewhere where bulk auditing
for the issue is possible.
Also, instead of an untranslated "pgstat wait timeout" message, provide
a translatable and hopefully more understandable message "using stale
statistics instead of current ones because stats collector is not
responding". The original text was written hastily under the assumption
that it would never really happen in practice, which we now know to be
unduly optimistic.
Back-patch to all active branches, since we've seen the buildfarm issue
in all branches.
M src/backend/postmaster/pgstat.c
doc: Fix typos in make_timestamp{,tz} examples
commit : a2ac3b890dfcafcce78625c721bcda2a3ecef514
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 19 Jan 2015 12:43:58 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 19 Jan 2015 12:43:58 -0300
Pointed out by Alan Mogi (bug #12571)
M doc/src/sgml/func.sgml
Fix use of already freed memory when dumping a database's security label.
commit : 94bc1c58789440f248e65650c811abd4fd9a2886
author : Andres Freund <andres@anarazel.de>
date : Sun, 18 Jan 2015 15:57:55 +0100
committer: Andres Freund <andres@anarazel.de>
date : Sun, 18 Jan 2015 15:57:55 +0100
pg_dump.c:dumDatabase() called ArchiveEntry() with the results of a a
query that was PQclear()ed a couple lines earlier.
Backpatch to 9.2 where security labels for shared objects where
introduced.
M src/bin/pg_dump/pg_dump.c
Fix namespace handling in xpath function
commit : 6bbf75192801c0965cec28c8d93c4ed5f2e68b20
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 6 Jan 2015 23:06:13 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 6 Jan 2015 23:06:13 -0500
Previously, the xml value resulting from an xpath query would not have
namespace declarations if the namespace declarations were attached to
an ancestor element in the input xml value. That means the output value
was not correct XML. Fix that by running the result value through
xmlCopyNode(), which produces the correct namespace declarations.
Author: Ali Akbar <the.apaan@gmail.com>
M src/backend/utils/adt/xml.c
M src/test/regress/expected/xml.out
M src/test/regress/expected/xml_1.out
M src/test/regress/sql/xml.sql
Another attempt at fixing Windows Norwegian locale.
commit : 2049a7d82920e23c37f92ece0051835a5ba39eeb
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 16 Jan 2015 12:12:49 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 16 Jan 2015 12:12:49 +0200
Previous fix mapped "Norwegian (Bokmål)" locale, which contains a non-ASCII
character, to the pure ASCII alias "norwegian-bokmal". However, it turns
out that more recent versions of the CRT library, in particular MSVCR110
(Visual Studio 2012), changed the behaviour of setlocale() so that if
you pass "norwegian-bokmal" to setlocale, it returns "Norwegian_Norway".
That meant trouble, when setlocale(..., NULL) first returned
"Norwegian (Bokmål)_Norway", which we mapped to "norwegian-bokmal_Norway",
but another call to setlocale(..., "norwegian-bokmal_Norway") returned
"Norwegian_Norway". That caused PostgreSQL to think that they are different
locales, and therefore not compatible. That caused initdb to fail at
CREATE DATABASE.
Older CRT versions seem to accept "Norwegian_Norway" too, so change the
mapping to return "Norwegian_Norway" instead of "norwegian-bokmal".
Backpatch to 9.2 like the previous attempt. We haven't made a release that
includes the previous fix yet, so we don't need to worry about changing the
locale of existing clusters from "norwegian-bokmal" to "Norwegian_Norway".
(Doing any mapping like this at all requires changing the locale of
existing databases; the release notes need to include instructions for
that).
M src/port/win32setlocale.c
Update "pg_regress --no-locale" for Darwin and Windows.
commit : a10de352be874ae28ea87aca79be4a5a2f229bb6
author : Noah Misch <noah@leadboat.com>
date : Fri, 16 Jan 2015 01:27:31 -0500
committer: Noah Misch <noah@leadboat.com>
date : Fri, 16 Jan 2015 01:27:31 -0500
Commit 894459e59ffa5c7fee297b246c17e1f72564db1d revealed this option to
be broken for NLS builds on Darwin, but "make -C contrib/unaccent check"
and the buildfarm client rely on it. Fix that configuration by
redefining the option to imply LANG=C on Darwin. In passing, use LANG=C
instead of LANG=en on Windows; since only postmaster startup uses that
value, testers are unlikely to notice the change. Back-patch to 9.0,
like the predecessor commit.
M src/test/regress/pg_regress.c
Fix use-of-already-freed-memory problem in EvalPlanQual processing.
commit : b75d18bd4f7906e1a89174d6ec4aca8548fffd8d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Jan 2015 18:52:25 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Jan 2015 18:52:25 -0500
Up to now, the "child" executor state trees generated for EvalPlanQual
rechecks have simply shared the ResultRelInfo arrays used for the original
execution tree. However, this leads to dangling-pointer problems, because
ExecInitModifyTable() is all too willing to scribble on some fields of the
ResultRelInfo(s) even when it's being run in one of those child trees.
This trashes those fields from the perspective of the parent tree, because
even if the generated subtree is logically identical to what was in use in
the parent, it's in a memory context that will go away when we're done
with the child state tree.
We do however want to share information in the direction from the parent
down to the children; in particular, fields such as es_instrument *must*
be shared or we'll lose the stats arising from execution of the children.
So the simplest fix is to make a copy of the parent's ResultRelInfo array,
but not copy any fields back at end of child execution.
Per report from Manuel Kniep. The added isolation test is based on his
example. In an unpatched memory-clobber-enabled build it will reliably
fail with "ctid is NULL" errors in all branches back to 9.1, as a
consequence of junkfilter->jf_junkAttNo being overwritten with $7f7f.
This test cannot be run as-is before that for lack of WITH syntax; but
I have no doubt that some variant of this problem can arise in older
branches, so apply the code change all the way back.
M src/backend/executor/execMain.c
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/specs/eval-plan-qual.spec
Fix thinko in re-setting wal_log_hints flag from a parameter-change record.
commit : b337d9657b4dbb72cfbb1012c15a01c5c74ff533
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 15 Jan 2015 20:48:48 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 15 Jan 2015 20:48:48 +0200
The flag is supposed to be copied from the record. Same issue with
track_commit_timestamps, but that's master-only.
Report and fix by Petr Jalinek. Backpatch to 9.4, where wal_log_hints was
added.
M src/backend/access/transam/xlog.c
Improve performance of EXPLAIN with large range tables.
commit : d25192892d61419278fbb216e695cb070c332092
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Jan 2015 13:18:16 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Jan 2015 13:18:16 -0500
As of 9.3, ruleutils.c goes to some lengths to ensure that table and column
aliases used in its output are unique. Of course this takes more time than
was required before, which in itself isn't fatal. However, EXPLAIN was set
up so that recalculation of the unique aliases was repeated for each
subexpression printed in a plan. That results in O(N^2) time and memory
consumption for large plan trees, which did not happen in older branches.
Fortunately, the expensive work is the same across a whole plan tree,
so there is no need to repeat it; we can do most of the initialization
just once per query and re-use it for each subexpression. This buys
back most (not all) of the performance loss since 9.2.
We need an extra ExplainState field to hold the precalculated deparse
context. That's no problem in HEAD, but in the back branches, expanding
sizeof(ExplainState) seems risky because third-party extensions might
have local variables of that struct type. So, in 9.4 and 9.3, introduce
an auxiliary struct to keep sizeof(ExplainState) the same. We should
refactor the APIs to avoid such local variables in future, but that's
material for a separate HEAD-only commit.
Per gripe from Alexey Bashtanov. Back-patch to 9.3 where the issue
was introduced.
M src/backend/commands/explain.c
M src/backend/utils/adt/ruleutils.c
M src/include/commands/explain.h
M src/include/utils/builtins.h
pg_standby: Avoid writing one byte beyond the end of the buffer.
commit : 7b65f194e9ef098e519bb6d4f792af71a4ab5778
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 15 Jan 2015 09:26:03 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 15 Jan 2015 09:26:03 -0500
Previously, read() might have returned a length equal to the buffer
length, and then the subsequent store to buf[len] would write a
zero-byte one byte past the end. This doesn't seem likely to be
a security issue, but there's some chance it could result in
pg_standby misbehaving.
Spotted by Coverity; patch by Michael Paquier, reviewed by me.
M contrib/pg_standby/pg_standby.c
Allow CFLAGS from configure's environment to override automatic CFLAGS.
commit : adb355106891ff318ca284f0cae3a993eef96185
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 14 Jan 2015 11:08:17 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 14 Jan 2015 11:08:17 -0500
Previously, configure would add any switches that it chose of its own
accord to the end of the user-specified CFLAGS string. Since most
compilers process these left-to-right, this meant that configure's choices
would override the user-specified flags in case of conflicts. We'd rather
that worked the other way around, so adjust the logic to put the user's
string at the end not the beginning.
There does not seem to be a need for a similar behavior change for CPPFLAGS
or LDFLAGS: in those, the earlier switches tend to win (think -I or -L
behavior) so putting the user's string at the front is fine.
Backpatch to 9.4 but not earlier. I'm not planning to run buildfarm member
guar on older branches, and it seems a bit risky to change this behavior
in long-stable branches.
M configure
M configure.in
Make logging_collector=on work with non-windows EXEC_BACKEND again.
commit : 045c7d3ebd413c501904233664825df5c1d955d7
author : Andres Freund <andres@anarazel.de>
date : Tue, 13 Jan 2015 21:02:47 +0100
committer: Andres Freund <andres@anarazel.de>
date : Tue, 13 Jan 2015 21:02:47 +0100
Commit b94ce6e80 reordered postmaster's startup sequence so that the
tempfile directory is only cleaned up after all the necessary state
for pg_ctl is collected. Unfortunately the chosen location is after
the syslogger has been started; which normally is fine, except for
!WIN32 EXEC_BACKEND builds, which pass information to children via
files in the temp directory.
Move the call to RemovePgTempFiles() to just before the syslogger has
started. That's the first child we fork.
Luckily EXEC_BACKEND is pretty much only used by endusers on windows,
which has a separate method to pass information to children. That
means the real world impact of this bug is very small.
Discussion: 20150113182344.GF12272@alap3.anarazel.de
Backpatch to 9.1, just as the previous commit was.
M src/backend/postmaster/postmaster.c
Silence Coverity warnings about unused return values from pushJsonbValue()
commit : 4ebb3494e9e05308737d27ee422b2283631f43a2
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 13 Jan 2015 14:29:36 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 13 Jan 2015 14:29:36 +0200
Similar warnings from backend were silenced earlier by commit c8315930,
but there were a few more contrib/hstore.
Michael Paquier
M contrib/hstore/hstore_io.c
Fix some functions that were declared static then defined not-static.
commit : 450d9f2d6669e3c97544de9878611ee2964db29d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Jan 2015 16:08:46 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Jan 2015 16:08:46 -0500
Per testing with a compiler that whines about this.
M src/pl/plpython/plpy_main.c
M src/pl/plpython/plpy_plpymodule.c
Avoid unexpected slowdown in vacuum regression test.
commit : 4072d91f24681d8d9f0cbdfd58c50ce30f4f1331
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Jan 2015 15:13:31 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Jan 2015 15:13:31 -0500
I noticed the "vacuum" regression test taking really significantly longer
than it used to on a slow machine. Investigation pointed the finger at
commit e415b469b33ba328765e39fd62edcd28f30d9c3c, which added creation of
an index using an extremely expensive index function. That function was
evidently meant to be applied only twice ... but the test re-used an
existing test table, which up till a couple lines before that had had over
two thousand rows. Depending on timing of the concurrent regression tests,
the intervening VACUUMs might have been unable to remove those
recently-dead rows, and then the index build would need to create index
entries for them too, leading to the wrap_do_analyze() function being
executed 2000+ times not twice. Avoid this by using a different table
that is guaranteed to have only the intended two rows in it.
Back-patch to 9.0, like the commit that created the problem.
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql
Use correct text domain for errcontext() appearing within ereport().
commit : 8f2d99be8f273bfdb69d1b87a38e9c6a734850e0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Jan 2015 12:40:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Jan 2015 12:40:12 -0500
The mechanism added in commit dbdf9679d7d61b03a3bf73af9b095831b7010eb5
for associating the correct translation domain with errcontext strings
potentially fails in cases where errcontext() is used within an ereport()
macro. Such usage was not originally envisioned for errcontext(), but we
do have a few places that do it. In this situation, the intended comma
expression becomes just a couple of arguments to errfinish(), which the
compiler might choose to evaluate right-to-left.
Fortunately, in such cases the textdomain for the errcontext string must
be the same as for the surrounding ereport. So we can fix this by letting
errstart initialize context_domain along with domain; then it will have
the correct value no matter which order the calls occur in. (Note that
error stack callback functions are not invoked until errfinish, so normal
usage of errcontext won't affect what happens for errcontext calls within
the ereport macro.)
In passing, make sure that errcontext calls within the main backend set
context_domain to something non-NULL. This isn't a live bug because
NULL would select the current textdomain() setting which should be the
right thing anyway --- but it seems better to handle this completely
consistently with the regular domain field.
Per report from Dmitry Voronin. Backpatch to 9.3; before that, there
wasn't any attempt to ensure that errcontext strings were translated
in an appropriate domain.
M src/backend/utils/error/elog.c
Skip dead backends in MinimumActiveBackends
commit : ff58dcb51f26e10d847637c3a95afc63e1deefab
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 12 Jan 2015 10:13:18 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 12 Jan 2015 10:13:18 -0500
Back in ed0b409, PGPROC was split and moved to static variables in
procarray.c, with procs in ProcArrayStruct replaced by an array of
integers representing process numbers (pgprocnos), with -1 indicating a
dead process which has yet to be removed. Access to procArray is
generally done under ProcArrayLock and therefore most code does not have
to concern itself with -1 entries.
However, MinimumActiveBackends intentionally does not take
ProcArrayLock, which means it has to be extra careful when accessing
procArray. Prior to ed0b409, this was handled by checking for a NULL
in the pointer array, but that check was no longer valid after the
split. Coverity pointed out that the check could never happen and so
it was removed in 5592eba. That didn't make anything worse, but it
didn't fix the issue either.
The correct fix is to check for pgprocno == -1 and skip over that entry
if it is encountered.
Back-patch to 9.2, since there can be attempts to access the arrays
prior to their start otherwise. Note that the changes prior to 9.4 will
look a bit different due to the change in 5592eba.
Note that MinimumActiveBackends only returns a bool for heuristic
purposes and any pre-array accesses are strictly read-only and so there
is no security implication and the lack of fields complaints indicates
it's very unlikely to run into issues due to this.
Pointed out by Noah.
M src/backend/storage/ipc/procarray.c
Fix libpq's behavior when /etc/passwd isn't readable.
commit : 733728ff372059556caadb37ff1cc5a8c6975eec
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 Jan 2015 12:35:47 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 Jan 2015 12:35:47 -0500
Some users run their applications in chroot environments that lack an
/etc/passwd file. This means that the current UID's user name and home
directory are not obtainable. libpq used to be all right with that,
so long as the database role name to use was specified explicitly.
But commit a4c8f14364c27508233f8a31ac4b10a4c90235a9 broke such cases by
causing any failure of pg_fe_getauthname() to be treated as a hard error.
In any case it did little to advance its nominal goal of causing errors
in pg_fe_getauthname() to be reported better. So revert that and instead
put some real error-reporting code in place. This requires changes to the
APIs of pg_fe_getauthname() and pqGetpwuid(), since the latter had
departed from the POSIX-specified API of getpwuid_r() in a way that made
it impossible to distinguish actual lookup errors from "no such user".
To allow such failures to be reported, while not failing if the caller
supplies a role name, add a second call of pg_fe_getauthname() in
connectOptions2(). This is a tad ugly, and could perhaps be avoided with
some refactoring of PQsetdbLogin(), but I'll leave that idea for later.
(Note that the complained-of misbehavior only occurs in PQsetdbLogin,
not when using the PQconnect functions, because in the latter we will
never bother to call pg_fe_getauthname() if the user gives a role name.)
In passing also clean up the Windows-side usage of GetUserName(): the
recommended buffer size is 257 bytes, the passed buffer length should
be the buffer size not buffer size less 1, and any error is reported
by GetLastError() not errno.
Per report from Christoph Berg. Back-patch to 9.4 where the chroot
failure case was introduced. The generally poor reporting of errors
here is of very long standing, of course, but given the lack of field
complaints about it we won't risk changing these APIs further back
(even though they're theoretically internal to libpq).
M src/common/username.c
M src/include/port.h
M src/interfaces/libpq/fe-auth.c
M src/interfaces/libpq/fe-auth.h
M src/interfaces/libpq/fe-connect.c
M src/port/path.c
M src/port/thread.c
xlogreader.c: Fix report_invalid_record translatability flag
commit : 3819d4e77b2d7c8933a8610ae10dc6c01e8190f1
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 9 Jan 2015 12:34:25 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 9 Jan 2015 12:34:25 -0300
For some reason I overlooked in GETTEXT_TRIGGERS that the right argument
be read by gettext in 7fcbf6a405ffc12a4546a25b98592ee6733783fc. This
will drop the translation percentages for the backend all the way back
to 9.3 ...
Problem reported by Heikki.
M src/backend/nls.mk
Protect against XLogReaderAllocate() failing to allocate memory.
commit : ed5b0f79512aa37fc92d2097bc9a0b93a27eaee2
author : Andres Freund <andres@anarazel.de>
date : Thu, 8 Jan 2015 13:35:04 +0100
committer: Andres Freund <andres@anarazel.de>
date : Thu, 8 Jan 2015 13:35:04 +0100
logical.c's StartupDecodingContext() forgot to check whether
XLogReaderAllocate() returns NULL indicating a memory allocation
failure. This could lead, although quite unlikely, lead to a NULL
pointer dereference.
This only applies to 9.4 as earlier versions don't do logical
decoding, and later versions don't return NULL after allocation
failures in XLogReaderAllocate().
Michael Paquier, with minor changes by me.
M src/backend/replication/logical/logical.c
On Darwin, detect and report a multithreaded postmaster.
commit : 83fb1ca5cf393f3a12930bd9275a711cd858c823
author : Noah Misch <noah@leadboat.com>
date : Wed, 7 Jan 2015 22:35:44 -0500
committer: Noah Misch <noah@leadboat.com>
date : Wed, 7 Jan 2015 22:35:44 -0500
Darwin --enable-nls builds use a substitute setlocale() that may start a
thread. Buildfarm member orangutan experienced BackendList corruption
on account of different postmaster threads executing signal handlers
simultaneously. Furthermore, a multithreaded postmaster risks undefined
behavior from sigprocmask() and fork(). Emit LOG messages about the
problem and its workaround. Back-patch to 9.0 (all supported versions).
M configure
M configure.in
M src/backend/postmaster/postmaster.c
M src/common/exec.c
M src/include/pg_config.h.in
Always set the six locale category environment variables in main().
commit : e8f82b4163edc806ecefdcfa6dfed092678218c9
author : Noah Misch <noah@leadboat.com>
date : Wed, 7 Jan 2015 22:34:57 -0500
committer: Noah Misch <noah@leadboat.com>
date : Wed, 7 Jan 2015 22:34:57 -0500
Typical server invocations already achieved that. Invalid locale
settings in the initial postmaster environment interfered, as could
malloc() failure. Setting "LC_MESSAGES=pt_BR.utf8 LC_ALL=invalid" in
the postmaster environment will now choose C-locale messages, not
Brazilian Portuguese messages. Most localized programs, including all
PostgreSQL frontend executables, do likewise. Users are unlikely to
observe changes involving locale categories other than LC_MESSAGES.
CheckMyDatabase() ensures that we successfully set LC_COLLATE and
LC_CTYPE; main() sets the remaining three categories to locale "C",
which almost cannot fail. Back-patch to 9.0 (all supported versions).
M src/backend/main/main.c
Reject ANALYZE commands during VACUUM FULL or another ANALYZE.
commit : fa042abddfad054b6872a2e2451868b08a230a2a
author : Noah Misch <noah@leadboat.com>
date : Wed, 7 Jan 2015 22:33:58 -0500
committer: Noah Misch <noah@leadboat.com>
date : Wed, 7 Jan 2015 22:33:58 -0500
vacuum()'s static variable handling makes it non-reentrant; an ensuing
null pointer deference crashed the backend. Back-patch to 9.0 (all
supported versions).
M src/backend/commands/vacuum.c
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql
Correctly handle relcache invalidation corner case during logical decoding.
commit : 7da1021542411130b66812e875c944c5aebf91d0
author : Andres Freund <andres@anarazel.de>
date : Wed, 7 Jan 2015 00:10:19 +0100
committer: Andres Freund <andres@anarazel.de>
date : Wed, 7 Jan 2015 00:10:19 +0100
When using a historic snapshot for logical decoding it can validly
happen that a relation that's in the relcache isn't visible to that
historic snapshot. E.g. if a newly created relation is referenced in
the query that uses the SQL interface for logical decoding and a
sinval reset occurs.
The earlier commit that fixed the error handling for that corner case
already improves the situation as a ERROR is better than hitting an
assertion... But it's obviously not good enough. So additionally
allow that case without an error if a historic snapshot is set up -
that won't allow an invalid entry to stay in the cache because it's a)
already marked invalid and will thus be rebuilt during the next access
b) the syscaches will be reset at the end of decoding.
There might be prettier solutions to handle this case, but all that we
could think of so far end up being much more complex than this quite
simple fix.
This fixes the assertion failures reported by the buildfarm (markhor,
tick, leech) after the introduction of new regression tests in
89fd41b390a4. The failure there weren't actually directly caused by
CLOBBER_CACHE_ALWAYS but the extraordinary long runtimes due to it
lead to sinval resets triggering the behaviour.
Discussion: 22459.1418656530@sss.pgh.pa.us
Backpatch to 9.4 where logical decoding was introduced.
M src/backend/utils/cache/relcache.c
Improve relcache invalidation handling of currently invisible relations.
commit : 84911ff51dec1b66f712ee966a84c1c434e8f875
author : Andres Freund <andres@anarazel.de>
date : Wed, 7 Jan 2015 00:10:18 +0100
committer: Andres Freund <andres@anarazel.de>
date : Wed, 7 Jan 2015 00:10:18 +0100
The corner case where a relcache invalidation tried to rebuild the
entry for a referenced relation but couldn't find it in the catalog
wasn't correct.
The code tried to RelationCacheDelete/RelationDestroyRelation the
entry. That didn't work when assertions are enabled because the latter
contains an assertion ensuring the refcount is zero. It's also more
generally a bad idea, because by virtue of being referenced somebody
might actually look at the entry, which is possible if the error is
trapped and handled via a subtransaction abort.
Instead just error out, without deleting the entry. As the entry is
marked invalid, the worst that can happen is that the invalid (and at
some point unused) entry lingers in the relcache.
Discussion: 22459.1418656530@sss.pgh.pa.us
There should be no way to hit this case < 9.4 where logical decoding
introduced a bug that can hit this. But since the code for handling
the corner case is there it should do something halfway sane, so
backpatch all the the way back. The logical decoding bug will be
handled in a separate commit.
M src/backend/utils/cache/relcache.c
Fix thinko in plpython error message
commit : 0cc6cef5a6e9f3af98c793d70173ac9e048009be
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 6 Jan 2015 15:16:29 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 6 Jan 2015 15:16:29 -0300
M src/pl/plpython/plpy_exec.c
Update copyright for 2015
commit : 0e52f5b507f4e27540291efa8dc25476fec42bed
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 6 Jan 2015 11:43:46 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 6 Jan 2015 11:43:46 -0500
Backpatch certain files through 9.0
M COPYRIGHT
M doc/src/sgml/legal.sgml
Fix broken pg_dump code for dumping comments on event triggers.
commit : c99e41f686bae0e35eafe92a970e77cbdb1db17c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Jan 2015 19:27:06 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Jan 2015 19:27:06 -0500
This never worked, I think. Per report from Marc Munro.
In passing, fix funny spacing in the COMMENT ON command as a result of
excess space in the "label" string.
M src/bin/pg_dump/pg_dump.c
Fix thinko in lock mode enum
commit : 51742063be4fd8d58fb8571e559fe8ca0abbbb57
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 4 Jan 2015 15:48:29 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 4 Jan 2015 15:48:29 -0300
Commit 0e5680f4737a9c6aa94aa9e77543e5de60411322 contained a thinko
mixing LOCKMODE with LockTupleMode. This caused misbehavior in the case
where a tuple is marked with a multixact with at most a FOR SHARE lock,
and another transaction tries to acquire a FOR NO KEY EXCLUSIVE lock;
this case should block but doesn't.
Include a new isolation tester spec file to explicitely try all the
tuple lock combinations; without the fix it shows the problem:
starting permutation: s1_begin s1_lcksvpt s1_tuplock2 s2_tuplock3 s1_commit
step s1_begin: BEGIN;
step s1_lcksvpt: SELECT * FROM multixact_conflict FOR KEY SHARE; SAVEPOINT foo;
a
1
step s1_tuplock2: SELECT * FROM multixact_conflict FOR SHARE;
a
1
step s2_tuplock3: SELECT * FROM multixact_conflict FOR NO KEY UPDATE;
a
1
step s1_commit: COMMIT;
With the fixed code, step s2_tuplock3 blocks until session 1 commits,
which is the correct behavior.
All other cases behave correctly.
Backpatch to 9.3, like the commit that introduced the problem.
M src/backend/access/heap/heapam.c
A src/test/isolation/expected/tuplelock-conflict.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/tuplelock-conflict.spec
Correctly handle test durations of more than 2147s in pg_test_timing.
commit : 7ced1b6c52b0e933813af7389c6ff77cf699f564
author : Andres Freund <andres@anarazel.de>
date : Sun, 4 Jan 2015 15:44:49 +0100
committer: Andres Freund <andres@anarazel.de>
date : Sun, 4 Jan 2015 15:44:49 +0100
Previously the computation of the total test duration, measured in
microseconds, accidentally overflowed due to accidentally using signed
32bit arithmetic. As the only consequence is that pg_test_timing
invocations with such, overly large, durations never finished the
practical consequences of this bug are minor.
Pointed out by Coverity.
Backpatch to 9.2 where pg_test_timing was added.
M contrib/pg_test_timing/pg_test_timing.c
Fix off-by-one in pg_xlogdump's fuzzy_open_file().
commit : 835a48702e550b6c9958bb053aa6c458971536d0
author : Andres Freund <andres@anarazel.de>
date : Sun, 4 Jan 2015 15:35:46 +0100
committer: Andres Freund <andres@anarazel.de>
date : Sun, 4 Jan 2015 15:35:46 +0100
In the unlikely case of stdin (fd 0) being closed, the off-by-one
would lead to pg_xlogdump failing to open files.
Spotted by Coverity.
Backpatch to 9.3 where pg_xlogdump was introduced.
M contrib/pg_xlogdump/pg_xlogdump.c
Add missing va_end() call to a early exit in dmetaphone.c's StringAt().
commit : 2d8411a0a08d2c24607dc179cb35385e623327c7
author : Andres Freund <andres@anarazel.de>
date : Sun, 4 Jan 2015 15:35:46 +0100
committer: Andres Freund <andres@anarazel.de>
date : Sun, 4 Jan 2015 15:35:46 +0100
Pointed out by Coverity.
Backpatch to all supported branches, the code has been that way for a
long while.
M contrib/fuzzystrmatch/dmetaphone.c
Fix inconsequential fd leak in the new mark_file_as_archived() function.
commit : ff7d46b8572ce566230c53e3c937412b3d19d8cf
author : Andres Freund <andres@anarazel.de>
date : Sun, 4 Jan 2015 14:36:21 +0100
committer: Andres Freund <andres@anarazel.de>
date : Sun, 4 Jan 2015 14:36:21 +0100
As every error in mark_file_as_archived() will lead to a failure of
pg_basebackup the FD leak couldn't ever lead to a real problem. It
seems better to fix the leak anyway though, rather than silence
Coverity, as the usage of the function might get extended or copied at
some point in the future.
Pointed out by Coverity.
Backpatch to 9.2, like the relevant part of the previous patch.
M src/bin/pg_basebackup/receivelog.c
Prevent WAL files created by pg_basebackup -x/X from being archived again.
commit : 90e4a2bf9b131f45fd4d80815b2b3505bb98c0a6
author : Andres Freund <andres@anarazel.de>
date : Sat, 3 Jan 2015 20:51:52 +0100
committer: Andres Freund <andres@anarazel.de>
date : Sat, 3 Jan 2015 20:51:52 +0100
WAL (and timeline history) files created by pg_basebackup did not
maintain the new base backup's archive status. That's currently not a
problem if the new node is used as a standby - but if that node is
promoted all still existing files can get archived again. With a high
wal_keep_segment settings that can happen a significant time later -
which is quite confusing.
Change both the backend (for the -x/-X fetch case) and pg_basebackup
(for -X stream) itself to always mark WAL/timeline files included in
the base backup as .done. That's in line with walreceiver.c doing so.
The verbosity of the pg_basebackup changes show pretty clearly that it
needs some refactoring, but that'd result in not be backpatchable
changes.
Backpatch to 9.1 where pg_basebackup was introduced.
Discussion: 20141205002854.GE21964@awork2.anarazel.de
M src/backend/replication/basebackup.c
M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_basebackup/pg_receivexlog.c
M src/bin/pg_basebackup/receivelog.c
M src/bin/pg_basebackup/receivelog.h
Add pg_string_endswith as the start of a string helper library in src/common.
commit : 70e36adb0d4b7f4656a06a5396a4cf65fc863323
author : Andres Freund <andres@anarazel.de>
date : Sat, 3 Jan 2015 20:51:52 +0100
committer: Andres Freund <andres@anarazel.de>
date : Sat, 3 Jan 2015 20:51:52 +0100
Backpatch to 9.3 where src/common was introduce, because a bugfix that
needs to be backpatched, requires the function. Earlier branches will
have to duplicate the code.
M src/backend/replication/slot.c
M src/common/Makefile
A src/common/string.c
A src/include/common/string.h
M src/tools/msvc/Mkvcbuild.pm
Treat negative values of recovery_min_apply_delay as having no effect.
commit : e7c1188756c9a57068e6be0c4cf2c448addb8b0c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 3 Jan 2015 13:14:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 3 Jan 2015 13:14:03 -0500
At one point in the development of this feature, it was claimed that
allowing negative values would be useful to compensate for timezone
differences between master and slave servers. That was based on a mistaken
assumption that commit timestamps are recorded in local time; but of course
they're in UTC. Nor is a negative apply delay likely to be a sane way of
coping with server clock skew. However, the committed patch still treated
negative delays as doing something, and the timezone misapprehension
survived in the user documentation as well.
If recovery_min_apply_delay were a proper GUC we'd just set the minimum
allowed value to be zero; but for the moment it seems better to treat
negative settings as if they were zero.
In passing do some extra wordsmithing on the parameter's documentation,
including correcting a second misstatement that the parameter affects
processing of Restore Point records.
Issue noted by Michael Paquier, who also provided the code patch; doc
changes by me. Back-patch to 9.4 where the feature was introduced.
M doc/src/sgml/recovery-config.sgml
M src/backend/access/transam/xlog.c
Make path to pg_service.conf absolute in documentation
commit : 01a162ea762a565f28188b5ee3db79b9cc90d37e
author : Magnus Hagander <magnus@hagander.net>
date : Sat, 3 Jan 2015 13:18:54 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Sat, 3 Jan 2015 13:18:54 +0100
The system file is always in the absolute path /etc/, not relative.
David Fetter
M doc/src/sgml/libpq.sgml
Docs: improve descriptions of ISO week-numbering date features.
commit : a5f2f027951902074c465fc1bddc249d30e4c188
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Dec 2014 16:42:45 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Dec 2014 16:42:45 -0500
Use the phraseology "ISO 8601 week-numbering year" in place of just
"ISO year", and make related adjustments to other terminology.
The point of this change is that it seems some people see "ISO year"
and think "standard year", whereupon they're surprised when constructs
like to_char(..., "IYYY-MM-DD") produce nonsensical results. Perhaps
hanging a few more adjectives on it will discourage them from jumping
to false conclusions. I put in an explicit warning against that
specific usage, too, though the main point is to discourage people
who haven't read this far down the page.
In passing fix some nearby markup and terminology inconsistencies.
M doc/src/sgml/func.sgml
Fix trailing whitespace in PO file
commit : 5517cfd552c4090f4caff2b8294d56681786d258
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 31 Dec 2014 14:18:56 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 31 Dec 2014 14:18:56 -0500
M src/backend/po/pt_BR.po
Improve consistency of parsing of psql's magic variables.
commit : c35249939b3addf8dc2f57d9213e8aeadc7bccd1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Dec 2014 12:16:57 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Dec 2014 12:16:57 -0500
For simple boolean variables such as ON_ERROR_STOP, psql has for a long
time recognized variant spellings of "on" and "off" (such as "1"/"0"),
and it also made a point of warning you if you'd misspelled the setting.
But these conveniences did not exist for other keyword-valued variables.
In particular, though ECHO_HIDDEN and ON_ERROR_ROLLBACK include "on" and
"off" as possible values, none of the alternative spellings for those were
recognized; and to make matters worse the code would just silently assume
"on" was meant for any unrecognized spelling. Several people have reported
getting bitten by this, so let's fix it. In detail, this patch:
* Allows all spellings recognized by ParseVariableBool() for ECHO_HIDDEN
and ON_ERROR_ROLLBACK.
* Reports a warning for unrecognized values for COMP_KEYWORD_CASE, ECHO,
ECHO_HIDDEN, HISTCONTROL, ON_ERROR_ROLLBACK, and VERBOSITY.
* Recognizes all values for all these variables case-insensitively;
previously there was a mishmash of case-sensitive and case-insensitive
behaviors.
Back-patch to all supported branches. There is a small risk of breaking
existing scripts that were accidentally failing to malfunction; but the
consensus is that the chance of detecting real problems and preventing
future mistakes outweighs this.
M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/command.c
M src/bin/psql/settings.h
M src/bin/psql/startup.c
M src/bin/psql/tab-complete.c
M src/bin/psql/variables.c
M src/bin/psql/variables.h
Revert the GinMaxItemSize calculation so that we fit 3 tuples per page.
commit : 4e241f7cdf21c293701946cc7f060c8ea5fbcda1
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 30 Dec 2014 14:29:20 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 30 Dec 2014 14:29:20 +0200
Commit 36a35c55 changed the divisor from 3 to 6, for no apparent reason.
Reducing GinMaxItemSize like that created a dump/reload hazard: loading a
9.3 database to 9.4 might fail with "index row size XXX exceeds maximum 1352
for index ..." error. Revert the change.
While we're at it, make the calculation slightly more accurate. It used to
divide the available space on page by three, then subtract
sizeof(ItemIdData), and finally round down. That's not totally accurate; the
item pointers for the three items are packed tight right after the page
header, but there is alignment padding after the item pointers. Change the
calculation to reflect that, like BTMaxItemSize does. I tested this with
different block sizes on systems with 4- and 8-byte alignment, and the value
after the final MAXALIGN_DOWN was the same with both methods on all
configurations. So this does not make any difference currently, but let's be
tidy.
Also add a comment explaining what the macro does.
This fixes bug #12292 reported by Robert Thaler. Backpatch to 9.4, where the
bug was introduced.
M src/include/access/gin_private.h
Fix resource leak pointed out by Coverity.
commit : 458e8bc653ab7f25de432762c89272540abfeaeb
author : Tatsuo Ishii <ishii@postgresql.org>
date : Tue, 30 Dec 2014 20:19:50 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Tue, 30 Dec 2014 20:19:50 +0900
M contrib/pgbench/pgbench.c
Backpatch variable renaming in formatting.c
commit : 1f35d93843108680e51a35424591c28fc3fbe5fe
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 29 Dec 2014 21:25:23 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 29 Dec 2014 21:25:23 -0500
Backpatch a9c22d1480aa8e6d97a000292d05ef2b31bbde4e to make future
backpatching easier.
Backpatch through 9.0
M src/backend/utils/adt/formatting.c
Assorted minor fixes for psql metacommand docs.
commit : 964edb59c1ba2c55bab813aa40b96a52f1b8b653
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Dec 2014 14:20:56 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Dec 2014 14:20:56 -0500
Document the long forms of \H \i \ir \o \p \r \w ... apparently, we have
a long and dishonorable history of leaving out the unabbreviated names of
psql backslash commands.
Avoid saying "Unix shell"; we can just say "shell" with equal clarity,
and not leave Windows users wondering whether the feature works for them.
Improve consistency of documentation of \g \o \w metacommands. There's
no reason to use slightly different wording or markup for each one.
M doc/src/sgml/ref/psql-ref.sgml
Grab heavyweight tuple lock only before sleeping
commit : 0e3a1f71dfb31527c07a80ccba815b2928d70d8f
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 26 Dec 2014 13:52:27 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 26 Dec 2014 13:52:27 -0300
We were trying to acquire the lock even when we were subsequently
not sleeping in some other transaction, which opens us up unnecessarily
to deadlocks. In particular, this is troublesome if an update tries to
lock an updated version of a tuple and finds itself doing EvalPlanQual
update chain walking; more than two sessions doing this concurrently
will find themselves sleeping on each other because the HW tuple lock
acquisition in heap_lock_tuple called from EvalPlanQualFetch races with
the same tuple lock being acquired in heap_update -- one of these
sessions sleeps on the other one to finish while holding the tuple lock,
and the other one sleeps on the tuple lock.
Per trouble report from Andrew Sackville-West in
http://www.postgresql.org/message-id/20140731233051.GN17765@andrew-ThinkPad-X230
His scenario can be simplified down to a relatively simple
isolationtester spec file which I don't include in this commit; the
reason is that the current isolationtester is not able to deal with more
than one blocked session concurrently and it blocks instead of raising
the expected deadlock. In the future, if we improve isolationtester, it
would be good to include the spec file in the isolation schedule. I
posted it in
http://www.postgresql.org/message-id/20141212205254.GC1768@alvh.no-ip.org
Hat tip to Mark Kirkwood, who helped diagnose the trouble.
M src/backend/access/heap/heapam.c
Have config_sspi_auth() permit IPv6 localhost connections.
commit : a472b55f3bde0330f5dfe625040c688391484e70
author : Noah Misch <noah@leadboat.com>
date : Thu, 25 Dec 2014 13:52:03 -0500
committer: Noah Misch <noah@leadboat.com>
date : Thu, 25 Dec 2014 13:52:03 -0500
Windows versions later than Windows Server 2003 map "localhost" to ::1.
Account for that in the generated pg_hba.conf, fixing another oversight
in commit f6dc6dd5ba54d52c0733aaafc50da2fbaeabb8b0. Back-patch to 9.0,
like that commit.
David Rowley and Noah Misch
M src/test/regress/pg_regress.c
M src/tools/msvc/Mkvcbuild.pm
Remove duplicate include of slot.h.
commit : 6ac1c52e472a1734d0f6bdc41b4ab871e21f7b92
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 25 Dec 2014 22:47:53 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 25 Dec 2014 22:47:53 +0900
Back-patch to 9.4, where this problem was added.
M src/backend/replication/walsender.c
Add CST (China Standard Time) to our lists of timezone abbreviations.
commit : 0680247192ebd7bed0e00053ed907618ca969d00
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Dec 2014 16:35:23 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Dec 2014 16:35:23 -0500
For some reason this seems to have been missed when the lists in
src/timezone/tznames/ were first constructed. We can't put it in Default
because of the conflict with US CST, but we should certainly list it among
the alternative entries in Asia.txt. (I checked for other oversights, but
all the other abbreviations that are in current use according to the IANA
files seem to be accounted for.) Noted while responding to bug #12326.
M src/timezone/tznames/America.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Australia.txt
M src/timezone/tznames/Default
Fix installcheck case for tap tests
commit : 233ce6e413eba8a74c6400041dcd4c10856ba435
author : Andrew Dunstan <andrew@dunslane.net>
date : Wed, 24 Dec 2014 10:31:36 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Wed, 24 Dec 2014 10:31:36 -0500
M src/Makefile.global.in
Further tidy up on json aggregate documentation
commit : 2a4ee7bbcf8461a12a8477596e8b08349fe2e742
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 22 Dec 2014 18:31:25 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 22 Dec 2014 18:31:25 -0500
M doc/src/sgml/func.sgml
Fix documentation of argument type of json_agg and jsonb_agg
commit : 302bed04b2e2c6074cccc3b63aa1962c5a4461dd
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 22 Dec 2014 14:20:19 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 22 Dec 2014 14:20:19 -0500
json_agg was originally designed to aggregate records. However, it soon
became clear that it is useful for aggregating all kinds of values and
that's what we have on 9.3 and 9.4, and in head for it and jsonb_agg.
The documentation suggested otherwise, so this fixes it.
M doc/src/sgml/func.sgml
Docs: clarify treatment of variadic functions with zero variadic arguments.
commit : 7ac0aff2b83e88edf5e7dcd4c4b425319d9537d6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 21 Dec 2014 15:30:39 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 21 Dec 2014 15:30:39 -0500
Explain that you have to use "VARIADIC ARRAY[]" to pass an empty array
to a variadic parameter position. This was already implicit in the text
but it seems better to spell it out.
Per a suggestion from David Johnston, though I didn't use his proposed
wording. Back-patch to all supported branches.
M doc/src/sgml/xfunc.sgml
Fix timestamp in end-of-recovery WAL records.
commit : 306b9918b2dd2fb93ea5a0fb62904a05c73fd87a
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 19 Dec 2014 17:00:21 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 19 Dec 2014 17:00:21 +0200
We used time(null) to set a TimestampTz field, which gave bogus results.
Noticed while looking at pg_xlogdump output.
Backpatch to 9.3 and above, where the fast promotion was introduced.
M src/backend/access/transam/xlog.c
Prevent potentially hazardous compiler/cpu reordering during lwlock release.
commit : 4c853646ae063d6290fc535e3aa80bc0ac69f012
author : Andres Freund <andres@anarazel.de>
date : Fri, 19 Dec 2014 14:29:52 +0100
committer: Andres Freund <andres@anarazel.de>
date : Fri, 19 Dec 2014 14:29:52 +0100
In LWLockRelease() (and in 9.4+ LWLockUpdateVar()) we release enqueued
waiters using PGSemaphoreUnlock(). As there are other sources of such
unlocks backends only wake up if MyProc->lwWaiting is set to false;
which is only done in the aforementioned functions.
Before this commit there were dangers because the store to lwWaitLink
could become visible before the store to lwWaitLink. This could both
happen due to compiler reordering (on most compilers) and on some
platforms due to the CPU reordering stores.
The possible consequence of this is that a backend stops waiting
before lwWaitLink is set to NULL. If that backend then tries to
acquire another lock and has to wait there the list could become
corrupted once the lwWaitLink store is finally performed.
Add a write memory barrier to prevent that issue.
Unfortunately the barrier support has been only added in 9.2. Given
that the issue has not knowingly been observed in praxis it seems
sufficient to prohibit compiler reordering using volatile for 9.0 and
9.1. Actual problems due to compiler reordering are more likely
anyway.
Discussion: 20140210134625.GA15246@awork2.anarazel.de
M src/backend/storage/lmgr/lwlock.c
Improve documentation about CASE and constant subexpressions.
commit : 2b8f74d79722ecf7c27445f088d0e50bcb81ed06
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 18 Dec 2014 16:38:55 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 18 Dec 2014 16:38:55 -0500
The possibility that constant subexpressions of a CASE might be evaluated
at planning time was touched on in 9.17.1 (CASE expressions), but it really
ought to be explained in 4.2.14 (Expression Evaluation Rules) which is the
primary discussion of such topics. Add text and an example there, and
revise the <note> under CASE to link there.
Back-patch to all supported branches, since it's acted like this for a
long time (though 9.2+ is probably worse because of its more aggressive
use of constant-folding via replanning of nominally-prepared statements).
Pre-9.4, also back-patch text added in commit 0ce627d4 about CASE versus
aggregate functions.
Tom Lane and David Johnston, per discussion of bug #12273.
M doc/src/sgml/func.sgml
M doc/src/sgml/syntax.sgml
Recognize Makefile line continuations in fetchRegressOpts().
commit : 4a48b4cb390656471ddf52f469ecb56d4e399df1
author : Noah Misch <noah@leadboat.com>
date : Thu, 18 Dec 2014 03:55:17 -0500
committer: Noah Misch <noah@leadboat.com>
date : Thu, 18 Dec 2014 03:55:17 -0500
Back-patch to 9.0 (all supported versions). This is mere
future-proofing in the context of the master branch, but commit
f6dc6dd5ba54d52c0733aaafc50da2fbaeabb8b0 requires it of older branches.
M src/tools/msvc/vcregress.pl
Fix (re-)starting from a basebackup taken off a standby after a failure.
commit : ce083254919d08043fc5c8b060f322f6bc84d1c0
author : Andres Freund <andres@anarazel.de>
date : Thu, 18 Dec 2014 08:35:27 +0100
committer: Andres Freund <andres@anarazel.de>
date : Thu, 18 Dec 2014 08:35:27 +0100
When starting up from a basebackup taken off a standby extra logic has
to be applied to compute the point where the data directory is
consistent. Normal base backups use a WAL record for that purpose, but
that isn't possible on a standby.
That logic had a error check ensuring that the cluster's control file
indicates being in recovery. Unfortunately that check was too strict,
disregarding the fact that the control file could also indicate that
the cluster was shut down while in recovery.
That's possible when the a cluster starting from a basebackup is shut
down before the backup label has been removed. When everything goes
well that's a short window, but when either restore_command or
primary_conninfo isn't configured correctly the window can get much
wider. That's because inbetween reading and unlinking the label we
restore the last checkpoint from WAL which can need additional WAL.
To fix simply also allow starting when the control file indicates
"shutdown in recovery". There's nicer fixes imaginable, but they'd be
more invasive.
Backpatch to 9.2 where support for taking basebackups from standbys
was added.
M src/backend/access/transam/xlog.c
Fix previous commit for TAP test suites in VPATH builds.
commit : e35e76a8f486aa397cd27f7e5104e7f0eedda877
author : Noah Misch <noah@leadboat.com>
date : Thu, 18 Dec 2014 01:24:57 -0500
committer: Noah Misch <noah@leadboat.com>
date : Thu, 18 Dec 2014 01:24:57 -0500
Per buildfarm member crake. Back-patch to 9.4, where the TAP suites
were introduced.
M src/Makefile.global.in
M src/bin/pg_ctl/t/001_start_stop.pl
M src/test/perl/TestLib.pm
Lock down regression testing temporary clusters on Windows.
commit : 6b87d423dc6188a0fed4331bc5c8e4c9c88263d1
author : Noah Misch <noah@leadboat.com>
date : Wed, 17 Dec 2014 22:48:40 -0500
committer: Noah Misch <noah@leadboat.com>
date : Wed, 17 Dec 2014 22:48:40 -0500
Use SSPI authentication to allow connections exclusively from the OS
user that launched the test suite. This closes on Windows the
vulnerability that commit be76a6d39e2832d4b88c0e1cc381aa44a7f86881
closed on other platforms. Users of "make installcheck" or custom test
harnesses can run "pg_regress --config-auth=DATADIR" to activate the
same authentication configuration that "make check" would use.
Back-patch to 9.0 (all supported versions).
Security: CVE-2014-0067
M contrib/dblink/Makefile
M contrib/dblink/expected/dblink.out
M contrib/dblink/sql/dblink.sql
M contrib/pg_upgrade/test.sh
M doc/src/sgml/regress.sgml
M src/Makefile.global.in
M src/bin/pg_ctl/t/001_start_stop.pl
M src/bin/pg_ctl/t/002_status.pl
M src/test/perl/TestLib.pm
M src/test/regress/pg_regress.c
M src/tools/msvc/vcregress.pl
Fix another poorly worded error message.
commit : 3f63b38fb252c54a2c40910dee47c2dc46cc7097
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Dec 2014 13:22:07 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Dec 2014 13:22:07 -0500
Spotted by Álvaro Herrera.
M src/bin/initdb/initdb.c
Fix poorly worded error message.
commit : 022d954925d73490f9771cdded16af3e94f27ec0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Dec 2014 13:14:57 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Dec 2014 13:14:57 -0500
Adam Brightwell, per report from Martín Marqués.
M src/backend/libpq/auth.c
Update .gitignore for pg_upgrade
commit : bf1c1f70c8904f87f791da9efa87643c16f2d159
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 17 Dec 2014 11:55:22 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Wed, 17 Dec 2014 11:55:22 +0100
Add Windows versions of generated scripts, and make sure we only
ignore the scripts int he root directory.
Michael Paquier
M contrib/pg_upgrade/.gitignore
Add missing documentation for some vcregress modes
commit : ba220850bd3be2ea6f9aee35666d5a124b8a7c38
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 17 Dec 2014 11:14:34 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Wed, 17 Dec 2014 11:14:34 +0100
Michael Paquier
M doc/src/sgml/install-windows.sgml
M src/tools/msvc/vcregress.pl
Remove redundant sentence
commit : 9bc93a89b0ff0a95018a84deed088e68f3cc75fb
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 17 Dec 2014 09:59:21 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Wed, 17 Dec 2014 09:59:21 +0100
Spotted by David Johnston
M doc/src/sgml/protocol.sgml
Fix off-by-one loop count in MapArrayTypeName, and get rid of static array.
commit : 383d224a02a4c481b20c20a0d36e390011d835b7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Dec 2014 15:35:36 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Dec 2014 15:35:36 -0500
MapArrayTypeName would copy up to NAMEDATALEN-1 bytes of the base type
name, which of course is wrong: after prepending '_' there is only room for
NAMEDATALEN-2 bytes. Aside from being the wrong result, this case would
lead to overrunning the statically allocated work buffer. This would be a
security bug if the function were ever used outside bootstrap mode, but it
isn't, at least not in any currently supported branches.
Aside from fixing the off-by-one loop logic, this patch gets rid of the
static work buffer by having MapArrayTypeName pstrdup its result; the sole
caller was already doing that, so this just requires moving the pstrdup
call. This saves a few bytes but mainly it makes the API a lot cleaner.
Back-patch on the off chance that there is some third-party code using
MapArrayTypeName with less-secure input. Pushing pstrdup into the function
should not cause any serious problems for such hypothetical code; at worst
there might be a short term memory leak.
Per Coverity scanning.
M src/backend/bootstrap/bootscanner.l
M src/backend/bootstrap/bootstrap.c
M src/include/bootstrap/bootstrap.h
Suppress bogus statistics when pgbench failed to complete any transactions.
commit : f2a3cdb6dbe4984c7b5461ed4ece789eab2faf4a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Dec 2014 14:53:58 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Dec 2014 14:53:58 -0500
Code added in 9.4 would attempt to divide by zero in such cases.
Noted while testing fix for missing-pclose problem.
M contrib/pgbench/pgbench.c
Fix file descriptor leak after failure of a \setshell command in pgbench.
commit : 6c75384eed8770b11f01378b37dc4bd07a5710f1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Dec 2014 13:31:42 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Dec 2014 13:31:42 -0500
If the called command fails to return data, runShellCommand forgot to
pclose() the pipe before returning. This is fairly harmless in the current
code, because pgbench would then abandon further processing of that client
thread; so no more than nclients descriptors could be leaked this way. But
it's not hard to imagine future improvements whereby that wouldn't be true.
In any case, it's sloppy coding, so patch all branches. Found by Coverity.
M contrib/pgbench/pgbench.c
Misc comment typo fixes.
commit : ce864d3276a29fc39155348e6e5ca282d1e51d2d
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 16 Dec 2014 16:34:56 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 16 Dec 2014 16:34:56 +0200
Backpatch the applicable parts, just to make backpatching future patches
easier.
M src/backend/lib/binaryheap.c
M src/backend/replication/walsender.c