Stamp 9.0.19.
commit : 8c15a7163c8d7dfa5df2f56639693122dd0800ec
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Feb 2015 15:46:01 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Feb 2015 15:46:01 -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 : 69ba47d6f9866d1dad93c4d613d8c635f32c1c07
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Feb 2015 11:24:14 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Feb 2015 11:24:14 -0500
Add entries for security issues.
Security: CVE-2015-0241 through CVE-2015-0244
M doc/src/sgml/release-9.0.sgml
Be more careful to not lose sync in the FE/BE protocol.
commit : 47ba0fbd796bb71652d1c73d38a0b4ca8de4a253
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 2 Feb 2015 17:09:17 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 2 Feb 2015 17:09:17 +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
Cherry-pick security-relevant fixes from upstream imath library.
commit : 0a3ee8a5f845d0b7ad0ad9efa0ff08f221404c4d
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 : ce6f261cd2df5f166ee21d54c4ad13f535193035
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 : 9e05c5063eb01ce52618f29fe975696dc4495e6f
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 : 56b970f2e98853bee7205022df4c5d38bafacdf5
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 : 611e110aabdf4b5edfed178b34ba662b1549674a
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
Translation updates
commit : 5828f7c6682652f43f5365cf0cd5091f3d63d4d5
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 1 Feb 2015 22:56:09 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 1 Feb 2015 22:56:09 -0500
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 8c8adccc355fb67d2a8690e4c830f8336b4f19a4
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/it.po
M src/backend/po/ja.po
M src/backend/po/pt_BR.po
M src/backend/po/ru.po
M src/bin/initdb/po/de.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/it.po
M src/bin/initdb/po/pt_BR.po
M src/bin/initdb/po/ru.po
M src/bin/pg_config/po/ja.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_ctl/po/it.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/it.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetxlog/po/it.po
M src/bin/pg_resetxlog/po/ru.po
M src/bin/psql/po/de.po
M src/bin/psql/po/it.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/ru.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ru.po
M src/pl/plpython/po/de.po
M src/pl/plpython/po/it.po
M src/pl/plpython/po/ru.po
doc: Improve claim about location of pg_service.conf
commit : b09ca88346096a16faaeda0de0ee1ea167dbc6c1
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 : 0e932ab7d1ddf074d9d4db1ee52e0b59eab450ba
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 1 Feb 2015 16:53:27 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 1 Feb 2015 16:53:27 -0500
M doc/src/sgml/release-9.0.sgml
Fix documentation of psql's ECHO all mode.
commit : 72387033b6d6dcfe1d1c25a6488c1d0290008b55
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 31 Jan 2015 18:35:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 31 Jan 2015 18:35:34 -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 : 3553d9c6ee3d97939be039c9f3022936d0fa339f
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 Coverity warning about contrib/pgcrypto's mdc_finish().
commit : 7c41a32b3ffcabfa0082e21e51ebefe9badb1d27
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 Jan 2015 13:05:09 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 Jan 2015 13:05:09 -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 BuildIndexValueDescription for expressions
commit : da8954b76b8eb288cca8b2707a65b1d4efa0b700
author : Stephen Frost <sfrost@snowman.net>
date : Thu, 29 Jan 2015 22:00:08 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Thu, 29 Jan 2015 22:00:08 -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 : dc9a506e68f7d2e5a3c23fadb6143c03f99ecee1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 29 Jan 2015 20:18:46 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 29 Jan 2015 20:18:46 -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 : 059f30c1b1afe861aa9541feb970494db05a1d2e
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 column-privilege leak in error-message paths
commit : 3a20633694c1a1b1a260eed2aa4fa7ece46e07ca
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 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.
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/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 volatile-safety issue in pltcl_SPI_execute_plan().
commit : 8c418fbd9ba0227f9089b17d437d97d293772c76
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 : 93d7706cbf2ce58e63ab8bbc9d16453b2c792ed4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 26 Jan 2015 11:57:47 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 26 Jan 2015 11:57:47 -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
Replace a bunch more uses of strncpy() with safer coding.
commit : 3a3ee655c3e1ce8fce26698bfd9601d85947da06
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jan 2015 13:05:58 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jan 2015 13:05:58 -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
Improve documentation of random() function.
commit : a113a66a7a7dc28d176663067b5edc9065de2c71
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 20 Jan 2015 21:21:47 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 20 Jan 2015 21:21:47 -0500
Move random() and setseed() to a separate table, to have them grouped
together. Also add a notice that random() is not cryptographically secure.
Back-patch of commit 75fdcec14543b60cc0c67483d8cc47d5c7adf1a8 into
all supported versions, per discussion of the need to document that
random() is just a wrapper around random(3).
M doc/src/sgml/func.sgml
In pg_regress, remove the temporary installation upon successful exit.
commit : 338ff75fc46c29936d70972ed25573f7bbc15b83
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Jan 2015 23:44:33 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Jan 2015 23:44:33 -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 : a1a8d0249a6c37e8f5c01835b94472e969eb88c3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Jan 2015 23:01:46 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Jan 2015 23:01:46 -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
Fix namespace handling in xpath function
commit : cebb3f032079fccb2c3224ba6d3eb39e987d4da9
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
Update "pg_regress --no-locale" for Darwin and Windows.
commit : 082764a0c901e34abe2f68b3f2f368f41b858da4
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 : 5308e085b649d946f441b349253b897e7b44067f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Jan 2015 18:52:38 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Jan 2015 18:52:38 -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
pg_standby: Avoid writing one byte beyond the end of the buffer.
commit : 0a67c00182be0a0c69eab365bfa4830f15be06d1
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
Avoid unexpected slowdown in vacuum regression test.
commit : 5b1e4c1c61db0e021fcf624decba6bc906d294bd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Jan 2015 15:13:45 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Jan 2015 15:13:45 -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
On Darwin, detect and report a multithreaded postmaster.
commit : 2e4946169d2f4890606305bef8bad7883d2e5281
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/include/pg_config.h.in
M src/port/exec.c
Always set the six locale category environment variables in main().
commit : 3580397fb142624d5602388c8149107511547573
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 : aae12e41669b75cdf112d0759a2f96b3ea1b4a45
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
Improve relcache invalidation handling of currently invisible relations.
commit : cbb2d9da6064092205ec483876e87b160ae8224e
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 : 9dcfb2bca5fdad3ddc4539efe5636de8db4fe9c4
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/plpython.c
Update copyright for 2015
commit : 1d74e16dd59a4dee4f753c0bab6cb6d2c3b89d35
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
Add missing va_end() call to a early exit in dmetaphone.c's StringAt().
commit : 17797e18dd449a354fd506f170526219cd4b7986
author : Andres Freund <andres@anarazel.de>
date : Sun, 4 Jan 2015 15:35:48 +0100
committer: Andres Freund <andres@anarazel.de>
date : Sun, 4 Jan 2015 15:35:48 +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
Make path to pg_service.conf absolute in documentation
commit : 07bec318b4f19ffe08cbcb7aaeed0e4949fd0cef
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 : 5f8fe02a56ec689c9811c67c3e548c754b577c63
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Dec 2014 16:42:58 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Dec 2014 16:42:58 -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
Improve consistency of parsing of psql's magic variables.
commit : 2600e44364cbbf418bcff39ce1d45025e9844386
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Dec 2014 12:17:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Dec 2014 12:17:12 -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/startup.c
M src/bin/psql/variables.c
M src/bin/psql/variables.h
Fix resource leak pointed out by Coverity.
commit : 9b74f35744b68f6f1b3338f2053aa6b8d641f9dd
author : Tatsuo Ishii <ishii@postgresql.org>
date : Tue, 30 Dec 2014 19:37:55 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Tue, 30 Dec 2014 19:37:55 +0900
M contrib/pgbench/pgbench.c
Backpatch variable renaming in formatting.c
commit : 312efcf43e9b70dd50c1bb2a349b4fd3b76be45f
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 : a3e3ddef9850908eba3ed0dde78dc230b44bbd65
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Dec 2014 14:21:10 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Dec 2014 14:21:10 -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
Have config_sspi_auth() permit IPv6 localhost connections.
commit : a99ec2b925785311bcb879c10adba906353004a0
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
Add CST (China Standard Time) to our lists of timezone abbreviations.
commit : 8b70023af7ffb8c25efa4f612ae71d5c804d79bc
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
Docs: clarify treatment of variadic functions with zero variadic arguments.
commit : b27679a466592ae27690f6ed0a6ff3a09812dfd7
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
Prevent potentially hazardous compiler/cpu reordering during lwlock release.
commit : fce3a719839e5e283c819a552ef81d3f684672e4
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 : 0c54cb0e3a61af18ec8d528eb802dd8fc9f7d4eb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 18 Dec 2014 16:39:08 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 18 Dec 2014 16:39:08 -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 : d168d0e6a74e9c5936b0fff37a27d75014e1b32e
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
Lock down regression testing temporary clusters on Windows.
commit : 6d45ee572d0f698c91495e458b52be35c2b3cae5
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 doc/src/sgml/regress.sgml
M src/test/regress/pg_regress.c
Fix off-by-one loop count in MapArrayTypeName, and get rid of static array.
commit : a2969bd72cdd6ecadf32ba6980bc52360c879955
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Dec 2014 15:35:49 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Dec 2014 15:35:49 -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
Fix file descriptor leak after failure of a \setshell command in pgbench.
commit : 961df18531b9e13be31b024329053a9d9e1556af
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
Fix planning of SELECT FOR UPDATE on child table with partial index.
commit : 662eebdc63376c2118197081c2e51bb531b6b1db
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Dec 2014 21:02:41 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Dec 2014 21:02:41 -0500
Ordinarily we can omit checking of a WHERE condition that matches a partial
index's condition, when we are using an indexscan on that partial index.
However, in SELECT FOR UPDATE we must include the "redundant" filter
condition in the plan so that it gets checked properly in an EvalPlanQual
recheck. The planner got this mostly right, but improperly omitted the
filter condition if the index in question was on an inheritance child
table. In READ COMMITTED mode, this could result in incorrectly returning
just-updated rows that no longer satisfy the filter condition.
The cause of the error is using get_parse_rowmark() when get_plan_rowmark()
is what should be used during planning. In 9.3 and up, also fix the same
mistake in contrib/postgres_fdw. It's currently harmless there (for lack
of inheritance support) but wrong is wrong, and the incorrect code might
get copied to someplace where it's more significant.
Report and fix by Kyotaro Horiguchi. Back-patch to all supported branches.
M src/backend/optimizer/plan/createplan.c
Fix corner case where SELECT FOR UPDATE could return a row twice.
commit : f5e4e92fbe2fd655d8b1ec30b523cfb134e66bf0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Dec 2014 19:37:17 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Dec 2014 19:37:17 -0500
In READ COMMITTED mode, if a SELECT FOR UPDATE discovers it has to redo
WHERE-clause checking on rows that have been updated since the SELECT's
snapshot, it invokes EvalPlanQual processing to do that. If this first
occurs within a non-first child table of an inheritance tree, the previous
coding could accidentally re-return a matching row from an earlier,
already-scanned child table. (And, to add insult to injury, I think this
could make it miss returning a row that should have been returned, if the
updated row that this happens on should still have passed the WHERE qual.)
Per report from Kyotaro Horiguchi; the added isolation test is based on his
test case.
This has been broken for quite awhile, so back-patch to all supported
branches.
M src/backend/executor/nodeLockRows.c
Give a proper error message if initdb password file is empty.
commit : d67be559ed8a43248c11f165d70b9dfd6439bb61
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 5 Dec 2014 14:27:56 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 5 Dec 2014 14:27:56 +0200
Used to say just "could not read password from file "...": Success", which
isn't very informative.
Mats Erik Andersson. Backpatch to all supported versions.
M src/bin/initdb/initdb.c
Guard against bad "dscale" values in numeric_recv().
commit : e6550626ca8e66b2fba175760156d8742217f474
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Dec 2014 15:25:18 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Dec 2014 15:25:18 -0500
We were not checking to see if the supplied dscale was valid for the given
digit array when receiving binary-format numeric values. While dscale can
validly be more than the number of nonzero fractional digits, it shouldn't
be less; that case causes fractional digits to be hidden on display even
though they're there and participate in arithmetic.
Bug #12053 from Tommaso Sala indicates that there's at least one broken
client library out there that sometimes supplies an incorrect dscale value,
leading to strange behavior. This suggests that simply throwing an error
might not be the best response; it would lead to failures in applications
that might seem to be working fine today. What seems the least risky fix
is to truncate away any digits that would be hidden by dscale. This
preserves the existing behavior in terms of what will be printed for the
transmitted value, while preventing subsequent arithmetic from producing
results inconsistent with that.
In passing, throw a specific error for the case of dscale being outside
the range that will fit into a numeric's header. Before you got "value
overflows numeric format", which is a bit misleading.
Back-patch to all supported branches.
M src/backend/utils/adt/numeric.c
Fix minor bugs in commit 30bf4689a96cd283af33edcdd6b7210df3f20cd8 et al.
commit : 85a6ad3cdf320ceef5671381bd4caafe984d8e6b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Nov 2014 12:21:01 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Nov 2014 12:21:01 -0500
Coverity complained that the "else" added to fillPGconn() was unreachable,
which it was. Remove the dead code. In passing, rearrange the tests so as
not to bother trying to fetch values for options that can't be assigned.
Pre-9.3 did not have that issue, but it did have a "return" that should be
"goto oom_error" to ensure that a suitable error message gets filled in.
M src/interfaces/libpq/fe-connect.c
Free libxml2/libxslt resources in a safer order.
commit : 6a694bbab20395603d751c9575746a753678aa5c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Nov 2014 11:13:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Nov 2014 11:13:03 -0500
Mark Simonetti reported that libxslt sometimes crashes for him, and that
swapping xslt_process's object-freeing calls around to do them in reverse
order of creation seemed to fix it. I've not reproduced the crash, but
valgrind clearly shows a reference to already-freed memory, which is
consistent with the idea that shutdown of the xsltTransformContext is
trying to reference the already-freed stylesheet or input document.
With this patch, valgrind is no longer unhappy.
I have an inquiry in to see if this is a libxslt bug or if we're just
abusing the library; but even if it's a library bug, we'd want to adjust
our code so it doesn't fail with unpatched libraries.
Back-patch to all supported branches, because we've been doing this in
the wrong(?) order for a long time.
M contrib/xml2/xslt_proc.c
Allow "dbname" from connection string to be overridden in PQconnectDBParams
commit : 9880fea4fd0003087302be22cd7bbf63c4548c0c
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 25 Nov 2014 17:12:07 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 25 Nov 2014 17:12:07 +0200
If the "dbname" attribute in PQconnectDBParams contained a connection string
or URI (and expand_dbname = TRUE), the database name from the connection
string could not be overridden by a subsequent "dbname" keyword in the
array. That was not intentional; all other options can be overridden.
Furthermore, any subsequent "dbname" caused the connection string from the
first dbname value to be processed again, overriding any values for the same
options that were given between the connection string and the second dbname
option.
In the passing, clarify in the docs that only the first dbname option in the
array is parsed as a connection string.
Alex Shulgin. Backpatch to all supported versions.
M src/interfaces/libpq/fe-connect.c
Check return value of strdup() in libpq connection option parsing.
commit : 1f35170395b79224cda272ba97572b515d57f0d8
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 25 Nov 2014 12:55:00 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 25 Nov 2014 12:55:00 +0200
An out-of-memory in most of these would lead to strange behavior, like
connecting to a different database than intended, but some would lead to
an outright segfault.
Alex Shulgin and me. Backpatch to all supported versions.
M src/interfaces/libpq/fe-connect.c
Improve documentation's description of JOIN clauses.
commit : d2e00c33bb63af9f66ca23eb1b866ca8697b6718
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 19 Nov 2014 16:00:40 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 19 Nov 2014 16:00:40 -0500
In bug #12000, Andreas Kunert complained that the documentation was
misleading in saying "FROM T1 CROSS JOIN T2 is equivalent to FROM T1, T2".
That's correct as far as it goes, but the equivalence doesn't hold when
you consider three or more tables, since JOIN binds more tightly than
comma. I added a <note> to explain this, and ended up rearranging some
of the existing text so that the note would make sense in context.
In passing, rewrite the description of JOIN USING, which was unnecessarily
vague, and hadn't been helped any by somebody's reliance on markup as a
substitute for clear writing. (Mostly this involved reintroducing a
concrete example that was unaccountably removed by commit 032f3b7e166cfa28.)
Back-patch to all supported branches.
M doc/src/sgml/queries.sgml
Don't require bleeding-edge timezone data in timestamptz regression test.
commit : e1f91066fd4d718161eb9cb9bacaa706273a4ba1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Nov 2014 21:36:59 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Nov 2014 21:36:59 -0500
The regression test cases added in commits b2cbced9e et al depended in part
on the Russian timezone offset changes of Oct 2014. While this is of no
particular concern for a default Postgres build, it was possible for a
build using --with-system-tzdata to fail the tests if the system tzdata
database wasn't au courant. Bjorn Munch and Christoph Berg both complained
about this while packaging 9.4rc1, so we probably shouldn't insist on the
system tzdata being up-to-date. Instead, make an equivalent test using a
zone change that occurred in Venezuela in 2007. With this patch, the
regression tests should pass using any tzdata set from 2012 or later.
(I can't muster much sympathy for somebody using --with-system-tzdata
on a machine whose system tzdata is more than three years out-of-date.)
M src/test/regress/expected/timestamptz.out
M src/test/regress/sql/timestamptz.sql
Update time zone data files to tzdata release 2014j.
commit : 92979576e82d2af423997377c2144b253c2a9e8a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Nov 2014 12:08:02 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Nov 2014 12:08:02 -0500
DST law changes in the Turks & Caicos Islands (America/Grand_Turk) and
in Fiji. New zone Pacific/Bougainville for portions of Papua New Guinea.
Historical changes for Korea and Vietnam.
M src/timezone/data/africa
M src/timezone/data/asia
M src/timezone/data/australasia
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/Default
M src/timezone/tznames/Europe.txt
M src/timezone/tznames/Pacific.txt
Fix race condition between hot standby and restoring a full-page image.
commit : 681dbe7d4599b4b13f9039ac961be14988120c1d
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 13 Nov 2014 19:47:44 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 13 Nov 2014 19:47:44 +0200
There was a window in RestoreBackupBlock where a page would be zeroed out,
but not yet locked. If a backend pinned and locked the page in that window,
it saw the zeroed page instead of the old page or new page contents, which
could lead to missing rows in a result set, or errors.
To fix, replace RBM_ZERO with RBM_ZERO_AND_LOCK, which atomically pins,
zeroes, and locks the page, if it's not in the buffer cache already.
In stable branches, the old RBM_ZERO constant is renamed to RBM_DO_NOT_USE,
to avoid breaking any 3rd party extensions that might use RBM_ZERO. More
importantly, this avoids renumbering the other enum values, which would
cause even bigger confusion in extensions that use ReadBufferExtended, but
haven't been recompiled.
Backpatch to all supported versions; this has been racy since hot standby
was introduced.
M src/backend/access/hash/hashpage.c
M src/backend/access/heap/heapam.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogutils.c
M src/backend/storage/buffer/bufmgr.c
M src/include/storage/bufmgr.h
Loop when necessary in contrib/pgcrypto's pktreader_pull().
commit : ef5a3b957c1d9eb405aef109df8152ec9ee96b6f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 11 Nov 2014 17:22:15 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 11 Nov 2014 17:22:15 -0500
This fixes a scenario in which pgp_sym_decrypt() failed with "Wrong key
or corrupt data" on messages whose length is 6 less than a power of 2.
Per bug #11905 from Connor Penhale. Fix by Marko Tiikkaja, regression
test case from Jeff Janes.
M contrib/pgcrypto/expected/pgp-decrypt.out
M contrib/pgcrypto/pgp-decrypt.c
M contrib/pgcrypto/sql/pgp-decrypt.sql
Cope with more than 64K phrases in a thesaurus dictionary.
commit : 39493e4d9252e70b1a396d35820b0970bd859601
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Nov 2014 20:52:40 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Nov 2014 20:52:40 -0500
dict_thesaurus stored phrase IDs in uint16 fields, so it would get confused
and even crash if there were more than 64K entries in the configuration
file. It turns out to be basically free to widen the phrase IDs to uint32,
so let's just do so.
This was complained of some time ago by David Boutin (in bug #7793);
he later submitted an informal patch but it was never acted on.
We now have another complaint (bug #11901 from Luc Ouellette) so it's
time to make something happen.
This is basically Boutin's patch, but for future-proofing I also added a
defense against too many words per phrase. Note that we don't need any
explicit defense against overflow of the uint32 counters, since before that
happens we'd hit array allocation sizes that repalloc rejects.
Back-patch to all supported branches because of the crash risk.
M src/backend/tsearch/dict_thesaurus.c
Prevent the unnecessary creation of .ready file for the timeline history file.
commit : 83c7bfb9aba947647dd2746281fceb60dd584271
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 6 Nov 2014 21:25:45 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 6 Nov 2014 21:25:45 +0900
Previously .ready file was created for the timeline history file at the end
of an archive recovery even when WAL archiving was not enabled.
This creation is unnecessary and causes .ready file to remain infinitely.
This commit changes an archive recovery so that it creates .ready file for
the timeline history file only when WAL archiving is enabled.
Backpatch to all supported versions.
M src/backend/access/transam/xlog.c
Drop no-longer-needed buffers during ALTER DATABASE SET TABLESPACE.
commit : 45a607d5c7e78f43c1339ce3553090c76703ee44
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Nov 2014 13:24:26 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Nov 2014 13:24:26 -0500
The previous coding assumed that we could just let buffers for the
database's old tablespace age out of the buffer arena naturally.
The folly of that is exposed by bug #11867 from Marc Munro: the user could
later move the database back to its original tablespace, after which any
still-surviving buffers would match lookups again and appear to contain
valid data. But they'd be missing any changes applied while the database
was in the new tablespace.
This has been broken since ALTER SET TABLESPACE was introduced, so
back-patch to all supported branches.
M src/backend/commands/dbcommands.c
Docs: fix incorrect spelling of contrib/pgcrypto option.
commit : 12a9d64993f911d5eeb9936135567d3019bc6cd6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Nov 2014 11:11:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Nov 2014 11:11:34 -0500
pgp_sym_encrypt's option is spelled "sess-key", not "enable-session-key".
Spotted by Jeff Janes.
In passing, improve a comment in pgp-pgsql.c to make it clearer that
the debugging options are intentionally undocumented.
M contrib/pgcrypto/pgp-pgsql.c
M doc/src/sgml/pgcrypto.sgml
Test IsInTransactionChain, not IsTransactionBlock, in vac_update_relstats.
commit : 73f950fc88eee13192ee538863b76603b030f1c0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 30 Oct 2014 13:03:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 30 Oct 2014 13:03:39 -0400
As noted by Noah Misch, my initial cut at fixing bug #11638 didn't cover
all cases where ANALYZE might be invoked in an unsafe context. We need to
test the result of IsInTransactionChain not IsTransactionBlock; which is
notationally a pain because IsInTransactionChain requires an isTopLevel
flag, which would have to be passed down through several levels of callers.
I chose to pass in_outer_xact (ie, the result of IsInTransactionChain)
rather than isTopLevel per se, as that seemed marginally more apropos
for the intermediate functions to know about.
M src/backend/commands/analyze.c
M src/backend/commands/vacuum.c
M src/backend/commands/vacuumlazy.c
M src/include/commands/vacuum.h
Avoid corrupting tables when ANALYZE inside a transaction is rolled back.
commit : 9d06da58e53c032ae5d4e1fdb1da533c49d3e117
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 29 Oct 2014 18:12:20 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 29 Oct 2014 18:12:20 -0400
VACUUM and ANALYZE update the target table's pg_class row in-place, that is
nontransactionally. This is OK, more or less, for the statistical columns,
which are mostly nontransactional anyhow. It's not so OK for the DDL hint
flags (relhasindex etc), which might get changed in response to
transactional changes that could still be rolled back. This isn't a
problem for VACUUM, since it can't be run inside a transaction block nor
in parallel with DDL on the table. However, we allow ANALYZE inside a
transaction block, so if the transaction had earlier removed the last
index, rule, or trigger from the table, and then we roll back the
transaction after ANALYZE, the table would be left in a corrupted state
with the hint flags not set though they should be.
To fix, suppress the hint-flag updates if we are InTransactionBlock().
This is safe enough because it's always OK to postpone hint maintenance
some more; the worst-case consequence is a few extra searches of pg_index
et al. There was discussion of instead using a transactional update,
but that would change the behavior in ways that are not all desirable:
in most scenarios we're better off keeping ANALYZE's statistical values
even if the ANALYZE itself rolls back. In any case we probably don't want
to change this behavior in back branches.
Per bug #11638 from Casey Shobe. This has been broken for a good long
time, so back-patch to all supported branches.
Tom Lane and Michael Paquier, initial diagnosis by Andres Freund
M src/backend/commands/vacuum.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Reset error message at PQreset()
commit : 49ef4eba20b606f0b30084492e45ed25ece928e4
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 29 Oct 2014 14:32:01 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 29 Oct 2014 14:32:01 +0200
If you call PQreset() repeatedly, and the connection cannot be
re-established, the error messages from the failed connection attempts
kept accumulating in the error string.
Fixes bug #11455 reported by Caleb Epstein. Backpatch to all supported
versions.
M src/interfaces/libpq/fe-connect.c
Fix two bugs in tsquery @> operator.
commit : 10059c2da7ee2a355e261ed5e56dcec4657e01aa
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 27 Oct 2014 10:50:41 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 27 Oct 2014 10:50:41 +0200
1. The comparison for matching terms used only the CRC to decide if there's
a match. Two different terms with the same CRC gave a match.
2. It assumed that if the second operand has more terms than the first, it's
never a match. That assumption is bogus, because there can be duplicate
terms in either operand.
Rewrite the implementation in a way that doesn't have those bugs.
Backpatch to all supported versions.
M src/backend/utils/adt/tsquery_op.c
Improve ispell dictionary's defenses against bad affix files.
commit : 21fa26b6594dc064310bee1cf725c68591ab8032
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 23 Oct 2014 13:11:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 23 Oct 2014 13:11:45 -0400
Don't crash if an ispell dictionary definition contains flags but not
any compound affixes. (This isn't a security issue since only superusers
can install affix files, but still it's a bad thing.)
Also, be more careful about detecting whether an affix-file FLAG command
is old-format (ispell) or new-format (myspell/hunspell). And change the
error message about mixed old-format and new-format commands into something
intelligible.
Per bug #11770 from Emre Hasegeli. Back-patch to all supported branches.
M src/backend/tsearch/spell.c
Ensure libpq reports a suitable error message on unexpected socket EOF.
commit : ac6e8753707337d338e3a5fdb99d4f593ebc2df5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 Oct 2014 18:42:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 Oct 2014 18:42:01 -0400
The EOF-detection logic in pqReadData was a bit confused about who should
set up the error message in case the kernel gives us read-ready-but-no-data
rather than ECONNRESET or some other explicit error condition. Since the
whole point of this situation is that the lower-level functions don't know
there's anything wrong, pqReadData itself must set up the message. But
keep the assumption that if an errno was reported, a message was set up at
lower levels.
Per bug #11712 from Marko Tiikkaja. It's been like this for a very long
time, so back-patch to all supported branches.
M src/interfaces/libpq/fe-misc.c
Declare mkdtemp() only if we're providing it.
commit : 98170fa4650752f670f055c74190e924ed8b655e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Oct 2014 22:55:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Oct 2014 22:55:36 -0400
Follow our usual style of providing an "extern" for a standard library
function only when we're also providing the implementation. This avoids
issues when the system headers declare the function slightly differently
than we do, as noted by Caleb Welton.
We might have to go to the extent of probing to see if the system headers
declare the function, but let's not do that until it's demonstrated to be
necessary.
Oversight in commit 9e6b1bf258170e62dac555fc82ff0536dfe01d29. Back-patch
to all supported branches, as that was.
M src/include/port.h
Fix core dump in pg_dump --binary-upgrade on zero-column composite type.
commit : 31021e7ba3d9dbbf991e91e868512f9cc4122eab
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Oct 2014 12:49:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Oct 2014 12:49:15 -0400
This reverts nearly all of commit 28f6cab61ab8958b1a7dfb019724687d92722538
in favor of just using the typrelid we already have in pg_dump's TypeInfo
struct for the composite type. As coded, it'd crash if the composite type
had no attributes, since then the query would return no rows.
Back-patch to all supported versions. It seems to not really be a problem
in 9.0 because that version rejects the syntax "create type t as ()", but
we might as well keep the logic similar in all affected branches.
Report and fix by Rushabh Lathia.
M src/bin/pg_dump/pg_dump.c
Support timezone abbreviations that sometimes change.
commit : 870a980aaf47b299cd0b3729362426ba4ed13999
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 Oct 2014 15:22:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 Oct 2014 15:22:26 -0400
Up to now, PG has assumed that any given timezone abbreviation (such as
"EDT") represents a constant GMT offset in the usage of any particular
region; we had a way to configure what that offset was, but not for it
to be changeable over time. But, as with most things horological, this
view of the world is too simplistic: there are numerous regions that have
at one time or another switched to a different GMT offset but kept using
the same timezone abbreviation. Almost the entire Russian Federation did
that a few years ago, and later this month they're going to do it again.
And there are similar examples all over the world.
To cope with this, invent the notion of a "dynamic timezone abbreviation",
which is one that is referenced to a particular underlying timezone
(as defined in the IANA timezone database) and means whatever it currently
means in that zone. For zones that use or have used daylight-savings time,
the standard and DST abbreviations continue to have the property that you
can specify standard or DST time and get that time offset whether or not
DST was theoretically in effect at the time. However, the abbreviations
mean what they meant at the time in question (or most recently before that
time) rather than being absolutely fixed.
The standard abbreviation-list files have been changed to use this behavior
for abbreviations that have actually varied in meaning since 1970. The
old simple-numeric definitions are kept for abbreviations that have not
changed, since they are a bit faster to resolve.
While this is clearly a new feature, it seems necessary to back-patch it
into all active branches, because otherwise use of Russian zone
abbreviations is going to become even more problematic than it already was.
This change supersedes the changes in commit 513d06ded et al to modify the
fixed meanings of the Russian abbreviations; since we've not shipped that
yet, this will avoid an undesirably incompatible (not to mention incorrect)
change in behavior for timestamps between 2011 and 2014.
This patch makes some cosmetic changes in ecpglib to keep its usage of
datetime lookup tables as similar as possible to the backend code, but
doesn't do anything about the increasingly obsolete set of timezone
abbreviation definitions that are hard-wired into ecpglib. Whatever we
do about that will likely not be appropriate material for back-patching.
Also, a potential free() of a garbage pointer after an out-of-memory
failure in ecpglib has been fixed.
This patch also fixes pre-existing bugs in DetermineTimeZoneOffset() that
caused it to produce unexpected results near a timezone transition, if
both the "before" and "after" states are marked as standard time. We'd
only ever thought about or tested transitions between standard and DST
time, but that's not what's happening when a zone simply redefines their
base GMT offset.
In passing, update the SGML documentation to refer to the Olson/zoneinfo/
zic timezone database as the "IANA" database, since it's now being
maintained under the auspices of IANA.
M contrib/btree_gist/btree_ts.c
M doc/src/sgml/config.sgml
M doc/src/sgml/datatype.sgml
M doc/src/sgml/datetime.sgml
M doc/src/sgml/installation.sgml
M src/backend/utils/adt/date.c
M src/backend/utils/adt/datetime.c
M src/backend/utils/adt/timestamp.c
M src/backend/utils/misc/tzparser.c
M src/include/pgtime.h
M src/include/utils/datetime.h
M src/include/utils/tzparser.h
M src/interfaces/ecpg/pgtypeslib/dt.h
M src/interfaces/ecpg/pgtypeslib/dt_common.c
M src/test/regress/expected/timestamptz.out
M src/test/regress/sql/timestamptz.sql
M src/timezone/known_abbrevs.txt
M src/timezone/localtime.c
M src/timezone/tznames/America.txt
M src/timezone/tznames/Antarctica.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Atlantic.txt
M src/timezone/tznames/Australia.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Europe.txt
M src/timezone/tznames/Indian.txt
M src/timezone/tznames/Pacific.txt
M src/timezone/tznames/README
Suppress dead, unportable src/port/crypt.c code.
commit : 4487b8598f4b2e1c87d032978639e235cf98945e
author : Noah Misch <noah@leadboat.com>
date : Sun, 12 Oct 2014 23:27:06 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sun, 12 Oct 2014 23:27:06 -0400
This file used __int64, which is specific to native Windows, rather than
int64. Suppress the long-unused union field of this type. Noticed on
Cygwin x86_64 with -lcrypt not installed. Back-patch to 9.0 (all
supported versions).
M src/port/crypt.c
Fix broken example in PL/pgSQL document.
commit : 0fbb1728b5e5218cfa80facff092e225096ae315
author : Fujii Masao <fujii@postgresql.org>
date : Fri, 10 Oct 2014 03:18:01 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Fri, 10 Oct 2014 03:18:01 +0900
Back-patch to all supported branches.
Marti Raudsepp, per a report from Marko Tiikkaja
M doc/src/sgml/plpgsql.sgml
Fix array overrun in ecpg's version of ParseDateTime().
commit : d9a1e9de54747354073fdc3e9bfb45258533da4c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Oct 2014 21:23:20 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Oct 2014 21:23:20 -0400
The code wrote a value into the caller's field[] array before checking
to see if there was room, which of course is backwards. Per report from
Michael Paquier.
I fixed the equivalent bug in the backend's version of this code way back
in 630684d3a130bb93, but failed to think about ecpg's copy. Fortunately
this doesn't look like it would be exploitable for anything worse than a
core dump: an external attacker would have no control over the single word
that gets written.
M src/interfaces/ecpg/pgtypeslib/dt_common.c
Cannot rely on %z printf length modifier.
commit : 64a628576700f9a0afc67f062e8fedf1fe6c3a57
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 5 Oct 2014 09:21:45 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 5 Oct 2014 09:21:45 +0300
Before version 9.4, we didn't require sprintf to support the %z length
modifier. Use %lu instead.
Reported by Peter Eisentraut. Apply to 9.3 and earlier.
M src/backend/access/gist/gist.c
Update time zone data files to tzdata release 2014h.
commit : b6391f587f46f09d5b0eaac8805f08db1a730a68
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 4 Oct 2014 14:18:43 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 4 Oct 2014 14:18:43 -0400
Most zones in the Russian Federation are subtracting one or two hours
as of 2014-10-26. Update the meanings of the abbreviations IRKT, KRAT,
MAGT, MSK, NOVT, OMST, SAKT, VLAT, YAKT, YEKT to match.
The IANA timezone database has adopted abbreviations of the form AxST/AxDT
for all Australian time zones, reflecting what they believe to be current
majority practice Down Under. These names do not conflict with usage
elsewhere (other than ACST for Acre Summer Time, which has been in disuse
since 1994). Accordingly, adopt these names into our "Default" timezone
abbreviation set. The "Australia" abbreviation set now contains only
CST,EAST,EST,SAST,SAT,WST, all of which are thought to be mostly historical
usage. Note that SAST has also been changed to be South Africa Standard
Time in the "Default" abbreviation set.
Add zone abbreviations SRET (Asia/Srednekolymsk) and XJT (Asia/Urumqi),
and use WSST/WSDT for western Samoa.
Also a DST law change in the Turks & Caicos Islands (America/Grand_Turk),
and numerous corrections for historical time zone data.
M src/backend/utils/misc/postgresql.conf.sample
M src/timezone/data/africa
M src/timezone/data/antarctica
M src/timezone/data/asia
M src/timezone/data/australasia
M src/timezone/data/backward
A src/timezone/data/backzone
M src/timezone/data/etcetera
M src/timezone/data/europe
M src/timezone/data/factory
M src/timezone/data/iso3166.tab
M src/timezone/data/leapseconds
M src/timezone/data/northamerica
M src/timezone/data/pacificnew
M src/timezone/data/southamerica
M src/timezone/data/systemv
M src/timezone/data/yearistype.sh
M src/timezone/data/zone.tab
A src/timezone/data/zone1970.tab
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/Africa.txt
M src/timezone/tznames/America.txt
M src/timezone/tznames/Antarctica.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Australia
M src/timezone/tznames/Australia.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Etc.txt
M src/timezone/tznames/Europe.txt
M src/timezone/tznames/Pacific.txt
Update time zone abbreviations lists.
commit : cc7bad30cdb39397fe4e5aeb5c1e6aaa77ca49ee
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Oct 2014 17:44:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Oct 2014 17:44:38 -0400
This updates known_abbrevs.txt to be what it should have been already,
were my -P patch not broken; and updates some tznames/ entries that
missed getting any love in previous timezone data updates because zic
failed to flag the change of abbreviation.
The non-cosmetic updates:
* Remove references to "ADT" as "Arabia Daylight Time", an abbreviation
that's been out of use since 2007; therefore, claiming there is a conflict
with "Atlantic Daylight Time" doesn't seem especially helpful. (We have
left obsolete entries in the files when they didn't conflict with anything,
but that seems like a different situation.)
* Fix entirely incorrect GMT offsets for CKT (Cook Islands), FJT, FJST
(Fiji); we didn't even have them on the proper side of the date line.
(Seems to have been aboriginal errors in our tznames data; there's no
evidence anything actually changed recently.)
* FKST (Falkland Islands Summer Time) is now used all year round, so
don't mark it as a DST abbreviation.
* Update SAKT (Sakhalin) to mean GMT+11 not GMT+10.
In cosmetic changes, I fixed a bunch of wrong (or at least obsolete)
claims about abbreviations not being present in the zic files, and
tried to be consistent about how obsolete abbreviations are labeled.
Note the underlying timezone/data files are still at release 2014e;
this is just trying to get us in sync with what those files actually
say before we go to the next update.
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/America.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Atlantic.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Europe.txt
M src/timezone/tznames/Pacific.txt
Don't balance vacuum cost delay when per-table settings are in effect
commit : 50a7576986681bf852ba0bbb0b4f55198b636ba0
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 3 Oct 2014 13:01:27 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 3 Oct 2014 13:01:27 -0300
When there are cost-delay-related storage options set for a table,
trying to make that table participate in the autovacuum cost-limit
balancing algorithm produces undesirable results: instead of using the
configured values, the global values are always used,
as illustrated by Mark Kirkwood in
http://www.postgresql.org/message-id/52FACF15.8020507@catalyst.net.nz
Since the mechanism is already complicated, just disable it for those
cases rather than trying to make it cope. There are undesirable
side-effects from this too, namely that the total I/O impact on the
system will be higher whenever such tables are vacuumed. However, this
is seen as less harmful than slowing down vacuum, because that would
cause bloat to accumulate. Anyway, in the new system it is possible to
tweak options to get the precise behavior one wants, whereas with the
previous system one was simply hosed.
This has been broken forever, so backpatch to all supported branches.
This might affect systems where cost_limit and cost_delay have been set
for individual tables.
M doc/src/sgml/maintenance.sgml
M src/backend/postmaster/autovacuum.c
Check for GiST index tuples that don't fit on a page.
commit : f04b112d573be996099300c83054aa5564d2b520
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 3 Oct 2014 12:07:10 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 3 Oct 2014 12:07:10 +0300
The page splitting code would go into infinite recursion if you try to
insert an index tuple that doesn't fit even on an empty page.
Per analysis and suggested fix by Andrew Gierth. Fixes bug #11555, reported
by Bryan Seitz (analysis happened over IRC). Backpatch to all supported
versions.
M src/backend/access/gist/gist.c
Fix typo in error message.
commit : 98a68b47858b43a37bb9752c311412a31c091fe7
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 2 Oct 2014 15:51:31 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 2 Oct 2014 15:51:31 +0300
M contrib/pgbench/pgbench.c
Fix some more problems with nested append relations.
commit : 288f15b7c8e06e56001d54726fa9d106280eee63
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Oct 2014 19:30:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Oct 2014 19:30:41 -0400
As of commit a87c72915 (which later got backpatched as far as 9.1),
we're explicitly supporting the notion that append relations can be
nested; this can occur when UNION ALL constructs are nested, or when
a UNION ALL contains a table with inheritance children.
Bug #11457 from Nelson Page, as well as an earlier report from Elvis
Pranskevichus, showed that there were still nasty bugs associated with such
cases: in particular the EquivalenceClass mechanism could try to generate
"join" clauses connecting an appendrel child to some grandparent appendrel,
which would result in assertion failures or bogus plans.
Upon investigation I concluded that all current callers of
find_childrel_appendrelinfo() need to be fixed to explicitly consider
multiple levels of parent appendrels. The most complex fix was in
processing of "broken" EquivalenceClasses, which are ECs for which we have
been unable to generate all the derived equality clauses we would like to
because of missing cross-type equality operators in the underlying btree
operator family. That code path is more or less entirely untested by
the regression tests to date, because no standard opfamilies have such
holes in them. So I wrote a new regression test script to try to exercise
it a bit, which turned out to be quite a worthwhile activity as it exposed
existing bugs in all supported branches.
The present patch is essentially the same as far back as 9.2, which is
where parameterized paths were introduced. In 9.0 and 9.1, we only need
to back-patch a small fragment of commit 5b7b5518d, which fixes failure to
propagate out the original WHERE clauses when a broken EC contains constant
members. (The regression test case results show that these older branches
are noticeably stupider than 9.2+ in terms of the quality of the plans
generated; but we don't really care about plan quality in such cases,
only that the plan not be outright wrong. A more invasive fix in the
older branches would not be a good idea anyway from a plan-stability
standpoint.)
M src/backend/optimizer/path/equivclass.c
A src/test/regress/expected/equivclass.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
A src/test/regress/sql/equivclass.sql
Fix identify_locking_dependencies for schema-only dumps.
commit : bbe3c069a24850430a65ab2821f1e762428c79fb
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 26 Sep 2014 11:21:35 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 26 Sep 2014 11:21:35 -0400
Without this fix, parallel restore of a schema-only dump can deadlock,
because when the dump is schema-only, the dependency will still be
pointing at the TABLE item rather than the TABLE DATA item.
Robert Haas and Tom Lane
M src/bin/pg_dump/pg_backup_archiver.c
doc: Fix documentation of local_preload_libraries
commit : fc4314a237d71a5a02e7907037e0e1b9c5b02157
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 14 Sep 2014 10:50:04 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 14 Sep 2014 10:50:04 -0400
The documentation used to suggest setting this parameter with ALTER ROLE
SET, but that never worked, so replace it with a working suggestion.
Reported-by: Kyotaro Horiguchi <horiguchi.kyotaro@lab.ntt.co.jp>
M doc/src/sgml/config.sgml
Handle border = 3 in expanded mode
commit : 1f89fc21874791d410f8a554e2b613a451e1ec16
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 12 Sep 2014 11:24:09 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 12 Sep 2014 11:24:09 -0400
In psql, expanded mode was not being displayed correctly when using
the normal ascii or unicode linestyles and border set to '3'. Now,
per the documentation, border '3' is really only sensible for HTML
and LaTeX formats, however, that's no excuse for ascii/unicode to
break in that case, and provisions had been made for psql to cleanly
handle this case (and it did, in non-expanded mode).
This was broken when ascii/unicode was initially added a good five
years ago because print_aligned_vertical_line wasn't passed in the
border setting being used by print_aligned_vertical but instead was
given the whole printTableContent. There really isn't a good reason
for vertical_line to have the entire printTableContent structure, so
just pass in the printTextFormat and border setting (similar to how
this is handled in horizontal_line).
Pointed out by Pavel Stehule, fix by me.
Back-patch to all currently-supported versions.
M src/bin/psql/print.c
Fix power_var_int() for large integer exponents.
commit : 26f8a4691e2ab459e856ba513aa559e7043d08fa
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Sep 2014 23:31:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Sep 2014 23:31:06 -0400
The code for raising a NUMERIC value to an integer power wasn't very
careful about large powers. It got an outright wrong answer for an
exponent of INT_MIN, due to failure to consider overflow of the Abs(exp)
operation; which is fixable by using an unsigned rather than signed
exponent value after that point. Also, even though the number of
iterations of the power-computation loop is pretty limited, it's easy for
the repeated squarings to result in ridiculously enormous intermediate
values, which can take unreasonable amounts of time/memory to process,
or even overflow the internal "weight" field and so produce a wrong answer.
We can forestall misbehaviors of that sort by bailing out as soon as the
weight value exceeds what will fit in int16, since then the final answer
must overflow (if exp > 0) or underflow (if exp < 0) the packed numeric
format.
Per off-list report from Pavel Stehule. Back-patch to all supported
branches.
M src/backend/utils/adt/numeric.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql
Fix typo in solaris spinlock fix.
commit : 030fd8afc882127c93ac10ce8d187fe46f5d72e2
author : Andres Freund <andres@anarazel.de>
date : Tue, 9 Sep 2014 13:57:38 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 9 Sep 2014 13:57:38 +0200
07968dbfaad03 missed part of the S_UNLOCK define when building for
sparcv8+.
M src/include/storage/s_lock.h
Fix spinlock implementation for some !solaris sparc platforms.
commit : f25e896016f5360df48fe7bfdb41c62494dc1277
author : Andres Freund <andres@anarazel.de>
date : Tue, 9 Sep 2014 00:47:32 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 9 Sep 2014 00:47:32 +0200
Some Sparc CPUs can be run in various coherence models, ranging from
RMO (relaxed) over PSO (partial) to TSO (total). Solaris has always
run CPUs in TSO mode while in userland, but linux didn't use to and
the various *BSDs still don't. Unfortunately the sparc TAS/S_UNLOCK
were only correct under TSO. Fix that by adding the necessary memory
barrier instructions. On sparcv8+, which should be all relevant CPUs,
these are treated as NOPs if the current consistency model doesn't
require the barriers.
Discussion: 20140630222854.GW26930@awork2.anarazel.de
Will be backpatched to all released branches once a few buildfarm
cycles haven't shown up problems. As I've no access to sparc, this is
blindly written.
M src/backend/port/tas/sunstudio_sparc.s
M src/include/storage/s_lock.h
Fix psql \s to work with recent libedit, and add pager support.
commit : 44c5183287f346be80effc2e04b3e45a0f9bf560
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Sep 2014 16:10:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Sep 2014 16:10:05 -0400
psql's \s (print command history) doesn't work at all with recent libedit
versions when printing to the terminal, because libedit tries to do an
fchmod() on the target file which will fail if the target is /dev/tty.
(We'd already noted this in the context of the target being /dev/null.)
Even before that, it didn't work pleasantly, because libedit likes to
encode the command history file (to ensure successful reloading), which
renders it nigh unreadable, not to mention significantly different-looking
depending on exactly which libedit version you have. So let's forget using
write_history() for this purpose, and instead print the data ourselves,
using logic similar to that used to iterate over the history for newline
encoding/decoding purposes.
While we're at it, insert the ability to use the pager when \s is printing
to the terminal. This has been an acknowledged shortcoming of \s for many
years, so while you could argue it's not exactly a back-patchable bug fix
it still seems like a good improvement. Anyone who's seriously annoyed
at this can use "\s /dev/tty" or local equivalent to get the old behavior.
Experimentation with this showed that the history iteration logic was
actually rather broken when used with libedit. It turns out that with
libedit you have to use previous_history() not next_history() to advance
to more recent history entries. The easiest and most robust fix for this
seems to be to make a run-time test to verify which function to call.
We had not noticed this because libedit doesn't really need the newline
encoding logic: its own encoding ensures that command entries containing
newlines are reloaded correctly (unlike libreadline). So the effective
behavior with recent libedits was that only the oldest history entry got
newline-encoded or newline-decoded. However, because of yet other bugs in
history_set_pos(), some old versions of libedit allowed the existing loop
logic to reach entries besides the oldest, which means there may be libedit
~/.psql_history files out there containing encoded newlines in more than
just the oldest entry. To ensure we can reload such files, it seems
appropriate to back-patch this fix, even though that will result in some
incompatibility with older psql versions (ie, multiline history entries
written by a psql with this fix will look corrupted to a psql without it,
if its libedit is reasonably up to date).
Stepan Rutz and Tom Lane
M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/command.c
M src/bin/psql/input.c
M src/bin/psql/input.h
Documentation fix: sum(float4) returns float4, not float8.
commit : dd5b3f808c0973974669f29a64e77d07a6488369
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 Sep 2014 22:40:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 Sep 2014 22:40:41 -0400
The old claim is from my commit d06ebdb8d3425185d7e641d15e45908658a0177d of
2000-07-17, but it seems to have been a plain old thinko; sum(float4) has
been distinct from sum(float8) since Berkeley days. Noted by KaiGai Kohei.
While at it, mention the existence of sum(money), which is also of
embarrassingly ancient vintage.
M doc/src/sgml/func.sgml
Fix segmentation fault that an empty prepared statement could cause.
commit : 857a5d6b59e0104ff0200723e617e5e9743d5532
author : Fujii Masao <fujii@postgresql.org>
date : Fri, 5 Sep 2014 02:17:57 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Fri, 5 Sep 2014 02:17:57 +0900
Back-patch to all supported branches.
Per bug #11335 from Haruka Takatsuka
M src/backend/tcop/utility.c
doc: Various typo/grammar fixes
commit : c1bbabee91d4a2811aca11415e3762d4e3722e01
author : Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 30 Aug 2014 11:05:57 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 30 Aug 2014 11:05:57 -0500
Errors detected using Topy (https://github.com/intgr/topy), all
changes verified by hand and some manual tweaks added.
Marti Raudsepp
Individual changes backpatched, where applicable, as far as 9.0.
M doc/src/sgml/datatype.sgml
M doc/src/sgml/pgbench.sgml
M doc/src/sgml/pgcrypto.sgml
M doc/src/sgml/pltcl.sgml
M doc/src/sgml/ref/alter_tsdictionary.sgml
M doc/src/sgml/ref/comment.sgml
M doc/src/sgml/release-7.4.sgml
M doc/src/sgml/release-8.2.sgml
M doc/src/sgml/release-old.sgml
M doc/src/sgml/stylesheet.dsl
M doc/src/sgml/textsearch.sgml
M doc/src/sgml/xml2.sgml
M doc/src/sgml/xoper.sgml
Install libpq DLL with $(INSTALL_SHLIB).
commit : e6841c4d653e0ba5ec916ab5b2520ac5f8935e9e
author : Noah Misch <noah@leadboat.com>
date : Mon, 18 Aug 2014 23:00:38 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 18 Aug 2014 23:00:38 -0400
Programs need execute permission on a DLL file to load it. MSYS
"install" ignores the mode argument, and our Cygwin build statically
links libpq into programs. That explains the lack of buildfarm trouble.
Back-patch to 9.0 (all supported versions).
M src/interfaces/libpq/Makefile
Fix obsolete mention of non-int64 support in CREATE SEQUENCE documentation.
commit : 823be6b7fd7898de0d7d17b9f371c4505e998cd2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 Aug 2014 01:17:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 Aug 2014 01:17:49 -0400
The old text explained what happened if we didn't have working int64
arithmetic. Since that case has been explicitly rejected by configure
since 8.4.3, documenting it in the 9.x branches can only produce confusion.
M doc/src/sgml/ref/create_sequence.sgml
Update SysV parameter configuration documentation for FreeBSD.
commit : c53127ba568479d6a839d60a0796eff202144204
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Aug 2014 16:06:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Aug 2014 16:06:01 -0400
FreeBSD hasn't made any use of kern.ipc.semmap since 1.1, and newer
releases reject attempts to set it altogether; so stop recommending
that it be adjusted. Per bug #11161.
Back-patch to all supported branches. Before 9.3, also incorporate
commit 7a42dff47, which touches the same text and for some reason
was not back-patched at the time.
M doc/src/sgml/runtime.sgml
Clarify type resolution behavior for domain types.
commit : f8ab54b7ecc73d05dec3a6a620adc924b5e5ca3f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 10 Aug 2014 16:13:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 10 Aug 2014 16:13:29 -0400
The user documentation was vague and not entirely accurate about how
we treat domain inputs for ambiguous operators/functions. Clarify
that, and add an example and some commentary. Per a recent question
from Adam Mackler.
It's acted like this ever since we added domains, so back-patch
to all supported branches.
M doc/src/sgml/typeconv.sgml
Reject duplicate column names in foreign key referenced-columns lists.
commit : 4ff49746eab2096090be8cd4434c9a5745ae32a4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 9 Aug 2014 13:46:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 9 Aug 2014 13:46:52 -0400
Such cases are disallowed by the SQL spec, and even if we wanted to allow
them, the semantics seem ambiguous: how should the FK columns be matched up
with the columns of a unique index? (The matching could be significant in
the presence of opclasses with different notions of equality, so this issue
isn't just academic.) However, our code did not previously reject such
cases, but instead would either fail to match to any unique index, or
generate a bizarre opclass-lookup error because of sloppy thinking in the
index-matching code.
David Rowley
M src/backend/commands/tablecmds.c
Fix typo in user manual
commit : f63be26196eaaa93afaaf1ce390a7c71ddc2211c
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 1 Aug 2014 21:13:17 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 1 Aug 2014 21:13:17 +0300
M doc/src/sgml/libpq.sgml
Avoid wholesale autovacuuming when autovacuum is nominally off.
commit : 91b4a881c465d7139c63149de705d5c282e6bea0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Jul 2014 14:41:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Jul 2014 14:41:35 -0400
When autovacuum is nominally off, we will still launch autovac workers
to vacuum tables that are at risk of XID wraparound. But after we'd done
that, an autovac worker would proceed to autovacuum every table in the
targeted database, if they meet the usual thresholds for autovacuuming.
This is at best pretty unexpected; at worst it delays response to the
wraparound threat. Fix it so that if autovacuum is nominally off, we
*only* do forced vacuums and not any other work.
Per gripe from Andrey Zhidenkov. This has been like this all along,
so back-patch to all supported branches.
M src/backend/postmaster/autovacuum.c
Treat 2PC commit/abort the same as regular xacts in recovery.
commit : 80498396139c21e95e6912d33d54c15e789b0ec4
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 29 Jul 2014 10:33:15 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 29 Jul 2014 10:33:15 +0300
There were several oversights in recovery code where COMMIT/ABORT PREPARED
records were ignored:
* pg_last_xact_replay_timestamp() (wasn't updated for 2PC commits)
* recovery_min_apply_delay (2PC commits were applied immediately)
* recovery_target_xid (recovery would not stop if the XID used 2PC)
The first of those was reported by Sergiy Zuban in bug #11032, analyzed by
Tom Lane and Andres Freund. The bug was always there, but was masked before
commit d19bd29f07aef9e508ff047d128a4046cc8bc1e2, because COMMIT PREPARED
always created an extra regular transaction that was WAL-logged.
Backpatch to all supported versions (older versions didn't have all the
features and therefore didn't have all of the above bugs).
M src/backend/access/transam/xlog.c
M src/include/access/xact.h
Fix typo in doc.
commit : ccf2b008650db4aca0c97a11e7ae76b8c76bb200
author : Fujii Masao <fujii@postgresql.org>
date : Mon, 28 Jul 2014 21:44:29 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Mon, 28 Jul 2014 21:44:29 +0900
unix_socket_directories was introduced in 9.3, but the document
in older versions wrongly have mentioned it. This commit replaces
it with the correct older name unix_socket_directory.
This is applied to only 9.2 and older supported versions.
Guillaume Lelarge
M doc/src/sgml/config.sgml
Rearrange documentation paragraph describing pg_relation_size().
commit : 561ac1b8cd4ccc10f7c05e83b28ec87f5b38b20f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Jul 2014 15:20:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Jul 2014 15:20:49 -0400
Break the list of available options into an <itemizedlist> instead of
inline sentences. This is mostly motivated by wanting to ensure that the
cross-references to the FSM and VM docs don't cross page boundaries in PDF
format; but it seems to me to read more easily this way anyway. I took the
liberty of editorializing a bit further while at it.
Per complaint from Magnus about 9.0.18 docs not building in A4 format.
Patch all active branches so we don't get blind-sided by this particular
issue again in future.
M doc/src/sgml/func.sgml
Revert "Reformat commit 6b2a1445ec8a631060c4cbff3f172bf31d3379b9"
commit : f38ad11b2a53c00d2cfa16ee41a81545d6c1759f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Jul 2014 14:29:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Jul 2014 14:29:14 -0400
This reverts commit 6ba56f0805b549b001e3149d6a7fba04e970d2dc.
We should instead patch up the following paragraph (the one about
pg_relation_size) so that it doesn't have cross-references that
break across lines in PDF output.)
M doc/src/sgml/func.sgml
Reformat commit 6b2a1445ec8a631060c4cbff3f172bf31d3379b9
commit : 6ba56f0805b549b001e3149d6a7fba04e970d2dc
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 23 Jul 2014 15:51:31 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Wed, 23 Jul 2014 15:51:31 +0200
This commit broke PDF builds on the 9.0 branch. Split the paragraph
up in two separate ones to make the PDFs happy again. Only doing this
in the 9.0 branch since that's the only place it's causing problems
at this point, and it's fairly unlikely that we're going to be
backpatching more docs changes to exactly this paragraph.
M doc/src/sgml/func.sgml
Report success when Windows kill() emulation signals an exiting process.
commit : 62f84f1de2d048bacbfadc77d7064d17057aeed5
author : Noah Misch <noah@leadboat.com>
date : Wed, 23 Jul 2014 00:35:13 -0400
committer: Noah Misch <noah@leadboat.com>
date : Wed, 23 Jul 2014 00:35:13 -0400
This is consistent with the POSIX verdict that kill() shall not report
ESRCH for a zombie process. Back-patch to 9.0 (all supported versions).
Test code from commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 depends
on it, and log messages about kill() reporting "Invalid argument" will
cease to appear for this not-unexpected condition.
M src/port/kill.c
MSVC: Substitute $(top_builddir) in REGRESS_OPTS.
commit : d5e70c73bfd050a21e80fc4c40823a7b75cc4f3b
author : Noah Misch <noah@leadboat.com>
date : Wed, 23 Jul 2014 00:35:07 -0400
committer: Noah Misch <noah@leadboat.com>
date : Wed, 23 Jul 2014 00:35:07 -0400
Commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 introduced a usage
thereof. Back-patch to 9.0, like that commit.
M src/tools/msvc/vcregress.pl
Check block number against the correct fork in get_raw_page().
commit : 9dc2a3fd0aff7d261732607b69f313906ad188df
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Jul 2014 11:46:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Jul 2014 11:46:04 -0400
get_raw_page tried to validate the supplied block number against
RelationGetNumberOfBlocks(), which of course is only right when
accessing the main fork. In most cases, the main fork is longer
than the others, so that the check was too weak (allowing a
lower-level error to be reported, but no real harm to be done).
However, very small tables could have an FSM larger than their heap,
in which case the mistake prevented access to some FSM pages.
Per report from Torsten Foertsch.
In passing, make the bad-block-number error into an ereport not elog
(since it's certainly not an internal error); and fix sloppily
maintained comment for RelationGetNumberOfBlocksInFork.
This has been wrong since we invented relation forks, so back-patch
to all supported branches.
M contrib/pageinspect/rawpage.c
Diagnose incompatible OpenLDAP versions during build and test.
commit : 4c6d0abde9e6c6c0f5b7b0eec780253baacea7bc
author : Noah Misch <noah@leadboat.com>
date : Tue, 22 Jul 2014 11:01:03 -0400
committer: Noah Misch <noah@leadboat.com>
date : Tue, 22 Jul 2014 11:01:03 -0400
With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL
backends can crash at exit. Raise a warning during "configure" based on
the compile-time OpenLDAP version number, and test the crash scenario in
the dblink test suite. Back-patch to 9.0 (all supported versions).
M configure
M configure.in
M contrib/dblink/Makefile
A contrib/dblink/expected/.gitignore
M contrib/dblink/expected/dblink.out
A contrib/dblink/input/paths.source
A contrib/dblink/output/paths.source
A contrib/dblink/pg_service.conf
A contrib/dblink/sql/.gitignore
M contrib/dblink/sql/dblink.sql
M src/test/regress/regress.c
Reject out-of-range numeric timezone specifications.
commit : 6e5a39c9e6e17c55570e246373c55f3896f52e5e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Jul 2014 22:41:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Jul 2014 22:41:36 -0400
In commit 631dc390f49909a5c8ebd6002cfb2bcee5415a9d, we started to handle
simple numeric timezone offsets via the zic library instead of the old
CTimeZone/HasCTZSet kluge. However, we overlooked the fact that the zic
code will reject UTC offsets exceeding a week (which seems a bit arbitrary,
but not because it's too tight ...). This led to possibly setting
session_timezone to NULL, which results in crashes in most timezone-related
operations as of 9.4, and crashes in a small number of places even before
that. So check for NULL return from pg_tzset_offset() and report an
appropriate error message. Per bug #11014 from Duncan Gillis.
Back-patch to all supported branches, like the previous patch.
(Unfortunately, as of today that no longer includes 8.4.)
M src/backend/commands/variable.c
M src/timezone/pgtz.c