Stamp 9.0.23.
commit : 9a42e8514f7e42737992bb09bd93540dd9630a9a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 15:19:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 15:19:44 -0400
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc
doc: Update URLs of external projects
commit : bfbaeae48a9c927dca41c4ac73a8a7ca7ae7c6d5
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 2 Oct 2015 21:50:59 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 2 Oct 2015 21:50:59 -0400
M doc/src/sgml/external-projects.sgml
Translation updates
commit : f2bcd7a7ea57fba191b1f484b642481cc5cc824e
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 5 Oct 2015 10:42:12 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 5 Oct 2015 10:42:12 -0400
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: e0981ce6d26309e48891d9192c69fcccd40fe7cd
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/it.po
M src/backend/po/ru.po
M src/bin/initdb/po/es.po
M src/bin/initdb/po/it.po
M src/bin/initdb/po/ru.po
M src/bin/pg_config/po/es.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/it.po
M src/bin/pg_dump/po/pt_BR.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetxlog/po/de.po
M src/bin/pg_resetxlog/po/es.po
M src/bin/pg_resetxlog/po/it.po
M src/bin/pg_resetxlog/po/ru.po
M src/bin/psql/po/es.po
M src/bin/psql/po/it.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/es.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/it.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/es.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/it.po
M src/pl/plpython/po/ru.po
M src/pl/tcl/po/es.po
Last-minute updates for release notes.
commit : 47b06ecad45ee6f44045fe35c4cfc15dafedc0a0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 10:57:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 10:57:15 -0400
Add entries for security and not-quite-security issues.
Security: CVE-2015-5288, CVE-2015-5289
M doc/src/sgml/release-9.0.sgml
Remove outdated comment about relation level autovacuum freeze limits.
commit : c415a7c8982b37818b9db50e2cb3f349f76550a7
author : Andres Freund <andres@anarazel.de>
date : Mon, 5 Oct 2015 16:09:13 +0200
committer: Andres Freund <andres@anarazel.de>
date : Mon, 5 Oct 2015 16:09:13 +0200
The documentation for the autovacuum_multixact_freeze_max_age and
autovacuum_freeze_max_age relation level parameters contained:
"Note that while you can set autovacuum_multixact_freeze_max_age very
small, or even zero, this is usually unwise since it will force frequent
vacuuming."
which hasn't been true since these options were made relation options,
instead of residing in the pg_autovacuum table (834a6da4f7).
Remove the outdated sentence. Even the lowered limits from 2596d70 are
high enough that this doesn't warrant calling out the risk in the CREATE
TABLE docs.
Per discussion with Tom Lane and Alvaro Herrera
Discussion: 26377.1443105453@sss.pgh.pa.us
Backpatch: 9.0- (in parts)
M doc/src/sgml/ref/create_table.sgml
Prevent stack overflow in query-type functions.
commit : 682a25d41c8a0e8425bf27453f49add24a047c09
author : Noah Misch <noah@leadboat.com>
date : Mon, 5 Oct 2015 10:06:30 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 5 Oct 2015 10:06:30 -0400
The tsquery, ltxtquery and query_int data types have a common ancestor.
Having acquired check_stack_depth() calls independently, each was
missing at least one call. Back-patch to 9.0 (all supported versions).
M contrib/intarray/_int_bool.c
M contrib/ltree/ltxtquery_io.c
M contrib/ltree/ltxtquery_op.c
M src/backend/utils/adt/tsquery_cleanup.c
Prevent stack overflow in container-type functions.
commit : 0398e071adf5437bafaab7701dc46df55dceca76
author : Noah Misch <noah@leadboat.com>
date : Mon, 5 Oct 2015 10:06:29 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 5 Oct 2015 10:06:29 -0400
A range type can name another range type as its subtype, and a record
type can bear a column of another record type. Consequently, functions
like range_cmp() and record_recv() are recursive. Functions at risk
include operator family members and referents of pg_type regproc
columns. Treat as recursive any such function that looks up and calls
the same-purpose function for a record column type or the range subtype.
Back-patch to 9.0 (all supported versions).
An array type's element type is never itself an array type, so array
functions are unaffected. Recursion depth proportional to array
dimensionality, found in array_dim_to_jsonb(), is fine thanks to MAXDIM.
M src/backend/utils/adt/rowtypes.c
pgcrypto: Detect and report too-short crypt() salts.
commit : 188e081ef891d8590d2675b44331b8c450f616c4
author : Noah Misch <noah@leadboat.com>
date : Mon, 5 Oct 2015 10:06:29 -0400
committer: Noah Misch <noah@leadboat.com>
date : Mon, 5 Oct 2015 10:06:29 -0400
Certain short salts crashed the backend or disclosed a few bytes of
backend memory. For existing salt-induced error conditions, emit a
message saying as much. Back-patch to 9.0 (all supported versions).
Josh Kupershmidt
Security: CVE-2015-5288
M contrib/pgcrypto/crypt-blowfish.c
M contrib/pgcrypto/crypt-des.c
M contrib/pgcrypto/expected/crypt-blowfish.out
M contrib/pgcrypto/expected/crypt-des.out
M contrib/pgcrypto/expected/crypt-xdes.out
M contrib/pgcrypto/px-crypt.c
M contrib/pgcrypto/sql/crypt-blowfish.sql
M contrib/pgcrypto/sql/crypt-des.sql
M contrib/pgcrypto/sql/crypt-xdes.sql
Re-Align *_freeze_max_age reloption limits with corresponding GUC limits.
commit : eeb0b7830290a2f95a0ff934c0322a286e226476
author : Andres Freund <andres@anarazel.de>
date : Mon, 5 Oct 2015 11:53:43 +0200
committer: Andres Freund <andres@anarazel.de>
date : Mon, 5 Oct 2015 11:53:43 +0200
In 020235a5754 I lowered the autovacuum_*freeze_max_age minimums to
allow for easier testing of wraparounds. I did not touch the
corresponding per-table limits. While those don't matter for the purpose
of wraparound, it seems more consistent to lower them as well.
It's noteworthy that the previous reloption lower limit for
autovacuum_multixact_freeze_max_age was too high by one magnitude, even
before 020235a5754.
Discussion: 26377.1443105453@sss.pgh.pa.us
Backpatch: back to 9.0 (in parts), like the prior patch
M src/backend/access/common/reloptions.c
Release notes for 9.5beta1, 9.4.5, 9.3.10, 9.2.14, 9.1.19, 9.0.23.
commit : 3d8987fc211b4a271da032d3351e87cd8d122912
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 19:38:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 19:38:01 -0400
M doc/src/sgml/release-9.0.sgml
Further twiddling of nodeHash.c hashtable sizing calculation.
commit : d637a899ca2bfc966614dfa8498b9023f4088b31
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 15:55:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 15:55:07 -0400
On reflection, the submitted patch didn't really work to prevent the
request size from exceeding MaxAllocSize, because of the fact that we'd
happily round nbuckets up to the next power of 2 after we'd limited it to
max_pointers. The simplest way to enforce the limit correctly is to
round max_pointers down to a power of 2 when it isn't one already.
(Note that the constraint to INT_MAX / 2, if it were doing anything useful
at all, is properly applied after that.)
M src/backend/executor/nodeHash.c
Fix possible "invalid memory alloc request size" failure in nodeHash.c.
commit : 2647b245d2360a5545f078a2943933eb50d57e66
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 14:16:59 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 14:16:59 -0400
Limit the size of the hashtable pointer array to not more than
MaxAllocSize. We've seen reports of failures due to this in HEAD/9.5,
and it seems possible in older branches as well. The change in
NTUP_PER_BUCKET in 9.5 may have made the problem more likely, but
surely it didn't introduce it.
Tomas Vondra, slightly modified by me
M src/backend/executor/nodeHash.c
Update time zone data files to tzdata release 2015g.
commit : 47ac95f378773a492b26ef2efe0115ac9a166e5a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 19:15:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 19:15:39 -0400
DST law changes in Cayman Islands, Fiji, Moldova, Morocco, Norfolk Island,
North Korea, Turkey, Uruguay. New zone America/Fort_Nelson for Canadian
Northern Rockies.
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/iso3166.tab
M src/timezone/data/leapseconds
M src/timezone/data/northamerica
M src/timezone/data/southamerica
M src/timezone/data/zone.tab
M src/timezone/data/zone1970.tab
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/America.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Pacific.txt
Add recursion depth protection to LIKE matching.
commit : b875ca09f3626e4002b5e70e00f99e4bc29c4d32
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 15:00:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 15:00:52 -0400
Since MatchText() recurses, it could in principle be driven to stack
overflow, although quite a long pattern would be needed.
M src/backend/utils/adt/like.c
M src/backend/utils/adt/like_match.c
Add recursion depth protections to regular expression matching.
commit : 54b116d83f828f5cff2e867d8a067c204d0978ab
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 14:51:59 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 14:51:59 -0400
Some of the functions in regex compilation and execution recurse, and
therefore could in principle be driven to stack overflow. The Tcl crew
has seen this happen in practice in duptraverse(), though their fix was
to put in a hard-wired limit on the number of recursive levels, which is
not too appetizing --- fortunately, we have enough infrastructure to check
the actually available stack. Greg Stark has also seen it in other places
while fuzz testing on a machine with limited stack space. Let's put guards
in to prevent crashes in all these places.
Since the regex code would leak memory if we simply threw elog(ERROR),
we have to introduce an API that checks for stack depth without throwing
such an error. Fortunately that's not difficult.
M src/backend/regex/regc_nfa.c
M src/backend/regex/regcomp.c
M src/backend/regex/rege_dfa.c
M src/backend/regex/regexec.c
M src/backend/tcop/postgres.c
M src/include/miscadmin.h
M src/include/regex/regguts.h
Fix potential infinite loop in regular expression execution.
commit : 2a887828964e5347916ffb621574641648b9dd5b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 14:26:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 14:26:36 -0400
In cfindloop(), if the initial call to shortest() reports that a
zero-length match is possible at the current search start point, but then
it is unable to construct any actual match to that, it'll just loop around
with the same start point, and thus make no progress. We need to force the
start point to be advanced. This is safe because the loop over "begin"
points has already tried and failed to match starting at "close", so there
is surely no need to try that again.
This bug was introduced in commit e2bd904955e2221eddf01110b1f25002de2aaa83,
wherein we allowed continued searching after we'd run out of match
possibilities, but evidently failed to think hard enough about exactly
where we needed to search next.
Because of the way this code works, such a match failure is only possible
in the presence of backrefs --- otherwise, shortest()'s judgment that a
match is possible should always be correct. That probably explains how
come the bug has escaped detection for several years.
The actual fix is a one-liner, but I took the trouble to add/improve some
comments related to the loop logic.
After fixing that, the submitted test case "()*\1" didn't loop anymore.
But it reported failure, though it seems like it ought to match a
zero-length string; both Tcl and Perl think it does. That seems to be from
overenthusiastic optimization on my part when I rewrote the iteration match
logic in commit 173e29aa5deefd9e71c183583ba37805c8102a72: we can't just
"declare victory" for a zero-length match without bothering to set match
data for capturing parens inside the iterator node.
Per fuzz testing by Greg Stark. The first part of this is a bug in all
supported branches, and the second part is a bug since 9.2 where the
iteration rewrite happened.
M src/backend/regex/regexec.c
Add some more query-cancel checks to regular expression matching.
commit : d4f6488ec0ea39dc8737dd14469dcaacef3800fa
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 13:45:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 13:45:39 -0400
Commit 9662143f0c35d64d7042fbeaf879df8f0b54be32 added infrastructure to
allow regular-expression operations to be terminated early in the event
of SIGINT etc. However, fuzz testing by Greg Stark disclosed that there
are still cases where regex compilation could run for a long time without
noticing a cancel request. Specifically, the fixempties() phase never
adds new states, only new arcs, so it doesn't hit the cancel check I'd put
in newstate(). Add one to newarc() as well to cover that.
Some experimentation of my own found that regex execution could also run
for a long time despite a pending cancel. We'd put a high-level cancel
check into cdissect(), but there was none inside the core text-matching
routines longest() and shortest(). Ordinarily those inner loops are very
very fast ... but in the presence of lookahead constraints, not so much.
As a compromise, stick a cancel check into the stateset cache-miss
function, which is enough to guarantee a cancel check at least once per
lookahead constraint test.
Making this work required more attention to error handling throughout the
regex executor. Henry Spencer had apparently originally intended longest()
and shortest() to be incapable of incurring errors while running, so
neither they nor their subroutines had well-defined error reporting
behaviors. However, that was already broken by the lookahead constraint
feature, since lacon() can surely suffer an out-of-memory failure ---
which, in the code as it stood, might never be reported to the user at all,
but just silently be treated as a non-match of the lookahead constraint.
Normalize all that by inserting explicit error tests as needed. I took the
opportunity to add some more comments to the code, too.
Back-patch to all supported branches, like the previous patch.
M src/backend/regex/regc_nfa.c
M src/backend/regex/rege_dfa.c
M src/backend/regex/regexec.c
Docs: add disclaimer about hazards of using regexps from untrusted sources.
commit : 3fe8a6c2d05affadce029af293e5e386cb055c22
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 13:30:43 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 13:30:43 -0400
It's not terribly hard to devise regular expressions that take large
amounts of time and/or memory to process. Recent testing by Greg Stark has
also shown that machines with small stack limits can be driven to stack
overflow by suitably crafted regexps. While we intend to fix these things
as much as possible, it's probably impossible to eliminate slow-execution
cases altogether. In any case we don't want to treat such things as
security issues. The history of that code should already discourage
prudent DBAs from allowing execution of regexp patterns coming from
possibly-hostile sources, but it seems like a good idea to warn about the
hazard explicitly.
Currently, similar_escape() allows access to enough of the underlying
regexp behavior that the warning has to apply to SIMILAR TO as well.
We might be able to make it safer if we tightened things up to allow only
SQL-mandated capabilities in SIMILAR TO; but that would be a subtly
non-backwards-compatible change, so it requires discussion and probably
could not be back-patched.
Per discussion among pgsql-security list.
M doc/src/sgml/func.sgml
Fix documentation error in commit 8703059c6b55c427100e00a09f66534b6ccbfaa1.
commit : a1c4afaafbc8fac540357e6c193ab1a971d2129a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Oct 2015 10:31:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Oct 2015 10:31:22 -0400
Etsuro Fujita spotted a thinko in the README commentary.
M src/backend/optimizer/README
Improve LISTEN startup time when there are many unread notifications.
commit : 2d4336cf85c13354b3da7acef44444df06b74275
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Sep 2015 23:32:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Sep 2015 23:32:23 -0400
If some existing listener is far behind, incoming new listener sessions
would start from that session's read pointer and then need to advance over
many already-committed notification messages, which they have no interest
in. This was expensive in itself and also thrashed the pg_notify SLRU
buffers a lot more than necessary. We can improve matters considerably
in typical scenarios, without much added cost, by starting from the
furthest-ahead read pointer, not the furthest-behind one. We do have to
consider only sessions in our own database when doing this, which requires
an extra field in the data structure, but that's a pretty small cost.
Back-patch to 9.0 where the current LISTEN/NOTIFY logic was introduced.
Matt Newell, slightly adjusted by me
M src/backend/commands/async.c
Fix compiler warning about unused function in non-readline case.
commit : 47ae6bc5a9fead2c6b52ed861ad84f605b43a858
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 28 Sep 2015 18:29:20 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 28 Sep 2015 18:29:20 -0400
Backpatch to all live branches to keep the code in sync.
M src/bin/psql/input.c
Further fix for psql's code for locale-aware formatting of numeric output.
commit : 98d8c75f9f15a3718214c2fbfda9919f3dcfd274
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Sep 2015 12:20:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Sep 2015 12:20:46 -0400
(Third time's the charm, I hope.)
Additional testing disclosed that this code could mangle already-localized
output from the "money" datatype. We can't very easily skip applying it
to "money" values, because the logic is tied to column right-justification
and people expect "money" output to be right-justified. Short of
decoupling that, we can fix it in what should be a safe enough way by
testing to make sure the string doesn't contain any characters that would
not be expected in plain numeric output.
M src/bin/psql/print.c
Further fix for psql's code for locale-aware formatting of numeric output.
commit : 71763ecff64cecc78384ef44c720f6e95db05f31
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Sep 2015 00:00:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Sep 2015 00:00:33 -0400
On closer inspection, those seemingly redundant atoi() calls were not so
much inefficient as just plain wrong: the author of this code either had
not read, or had not understood, the POSIX specification for localeconv().
The grouping field is *not* a textual digit string but separate integers
encoded as chars.
We'll follow the existing code as well as the backend's cash.c in only
honoring the first group width, but let's at least honor it correctly.
This doesn't actually result in any behavioral change in any of the
locales I have installed on my Linux box, which may explain why nobody's
complained; grouping width 3 is close enough to universal that it's barely
worth considering other cases. Still, wrong is wrong, so back-patch.
M src/bin/psql/print.c
Fix psql's code for locale-aware formatting of numeric output.
commit : c2d6ef14eba72468458517249d8b0c0df5507918
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Sep 2015 23:01:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Sep 2015 23:01:04 -0400
This code did the wrong thing entirely for numbers with an exponent
but no decimal point (e.g., '1e6'), as reported by Jeff Janes in
bug #13636. More generally, it made lots of unverified assumptions
about what the input string could possibly look like. Rearrange so
that it only fools with leading digits that it's directly verified
are there, and an immediately adjacent decimal point. While at it,
get rid of some useless inefficiencies, like converting the grouping
count string to integer over and over (and over).
This has been broken for a long time, so back-patch to all supported
branches.
M src/bin/psql/print.c
Lower *_freeze_max_age minimum values.
commit : 078d471a909a07bc7dc93def37b6811e236f8a84
author : Andres Freund <andres@anarazel.de>
date : Thu, 24 Sep 2015 14:53:33 +0200
committer: Andres Freund <andres@anarazel.de>
date : Thu, 24 Sep 2015 14:53:33 +0200
The old minimum values are rather large, making it time consuming to
test related behaviour. Additionally the current limits, especially for
multixacts, can be problematic in space-constrained systems. 10000000
multixacts can contain a lot of members.
Since there's no good reason for the current limits, lower them a good
bit. Setting them to 0 would be a bad idea, triggering endless vacuums,
so still retain a limit.
While at it fix autovacuum_multixact_freeze_max_age to refer to
multixact.c instead of varsup.c.
Reviewed-By: Robert Haas
Discussion: CA+TgmoYmQPHcrc3GSs7vwvrbTkbcGD9Gik=OztbDGGrovkkEzQ@mail.gmail.com
Backpatch: 9.0 (in parts)
M src/backend/utils/misc/guc.c
Skip recently-added umask() call on Windows.
commit : c69e7d5c78af946b22d46afc60823d20197ca3e3
author : Noah Misch <noah@leadboat.com>
date : Tue, 22 Sep 2015 23:37:26 -0400
committer: Noah Misch <noah@leadboat.com>
date : Tue, 22 Sep 2015 23:37:26 -0400
Symbols S_IRWXG and S_IRWXO became available to Windows builds in commit
1319002e2ee166c06b38cdbc5e8508c7205fa115, so PostgreSQL 9.0 cannot use
them in platform-independent code. Rewrite commit
24aed2124a5273e4cb543b06d4b7bb2c2ad5bf3c to not change Windows builds.
The new umask() call had no effect on Windows, anyway. Per buildfarm.
M src/bin/pg_dump/pg_backup_tar.c
Docs: fix typo in to_char() example.
commit : 68e83c12088aa2272ccdd632a37d647ea67548a0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Sep 2015 10:40:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Sep 2015 10:40:25 -0400
Per bug #13631 from KOIZUMI Satoru.
M doc/src/sgml/func.sgml
Fix possible internal overflow in numeric multiplication.
commit : a89781e34725286b675d41f8dfdfa25ade2a277f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Sep 2015 12:11:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Sep 2015 12:11:32 -0400
mul_var() postpones propagating carries until it risks overflow in its
internal digit array. However, the logic failed to account for the
possibility of overflow in the carry propagation step, allowing wrong
results to be generated in corner cases. We must slightly reduce the
when-to-propagate-carries threshold to avoid that.
Discovered and fixed by Dean Rasheed, with small adjustments by me.
This has been wrong since commit d72f6c75038d8d37e64a29a04b911f728044d83b,
so 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
Restrict file mode creation mask during tmpfile().
commit : 24aed2124a5273e4cb543b06d4b7bb2c2ad5bf3c
author : Noah Misch <noah@leadboat.com>
date : Sun, 20 Sep 2015 20:42:27 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sun, 20 Sep 2015 20:42:27 -0400
Per Coverity. Back-patch to 9.0 (all supported versions).
Michael Paquier, reviewed (in earlier versions) by Heikki Linnakangas.
M src/bin/pg_dump/pg_backup_tar.c
Be more wary about partially-valid LOCALLOCK data in RemoveLocalLock().
commit : eed5bbc48026976444dc020086559acc8e6f26ca
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 20 Sep 2015 16:48:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 20 Sep 2015 16:48:44 -0400
RemoveLocalLock() must consider the possibility that LockAcquireExtended()
failed to palloc the initial space for a locallock's lockOwners array.
I had evidently meant to cope with this hazard when the code was originally
written (commit 1785acebf2ed14fd66955e2d9a55d77a025f418d), but missed that
the pfree needed to be protected with an if-test. Just to make sure things
are left in a clean state, reset numLockOwners as well.
Per low-memory testing by Andreas Seltenreich. Back-patch to all supported
branches.
M src/backend/storage/lmgr/lock.c
Let compiler handle size calculation of bool types.
commit : 44297a058ea05cd78b33612ce303f3caec11e3ab
author : Michael Meskes <meskes@postgresql.org>
date : Thu, 17 Sep 2015 15:41:04 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Thu, 17 Sep 2015 15:41:04 +0200
Back in the day this did not work, but modern compilers should handle it themselves.
M src/interfaces/ecpg/ecpglib/data.c
M src/interfaces/ecpg/ecpglib/execute.c
Fix low-probability memory leak in regex execution.
commit : ba9eb293fa6466e5dd8dbcf1e51f8126d9d02bb0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 18 Sep 2015 13:55:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 18 Sep 2015 13:55:17 -0400
After an internal failure in shortest() or longest() while pinning down the
exact location of a match, find() forgot to free the DFA structure before
returning. This is pretty unlikely to occur, since we just successfully
ran the "search" variant of the DFA; but it could happen, and it would
result in a session-lifespan memory leak since this code uses malloc()
directly. Problem seems to have been aboriginal in Spencer's library,
so back-patch all the way.
In passing, correct a thinko in a comment I added awhile back about the
meaning of the "ntree" field.
I happened across these issues while comparing our code to Tcl's version
of the library.
M src/backend/regex/regexec.c
Fix documentation of regular expression character-entry escapes.
commit : f7eeb324e7b9fa948dfd55b55e9b20fa919e7f79
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Sep 2015 14:50:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 16 Sep 2015 14:50:12 -0400
The docs claimed that \uhhhh would be interpreted as a Unicode value
regardless of the database encoding, but it's never been implemented
that way: \uhhhh and \xhhhh actually mean exactly the same thing, namely
the character that pg_mb2wchar translates to 0xhhhh. Moreover we were
falsely dismissive of the usefulness of Unicode code points above FFFF.
Fix that.
It's been like this for ages, so back-patch to all supported branches.
M doc/src/sgml/func.sgml
Remove set-but-not-used variable.
commit : 698c7a3bc0d8b2d9677f47943cf20aaf864dabe5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Sep 2015 11:11:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Sep 2015 11:11:08 -0400
In branches before 9.3, commit 8703059c6 caused join_is_legal()'s
unique_ified variable to become unused, since its only remaining
use is for LATERAL-related tests which don't exist pre-9.3.
My compiler didn't complain about that, but Peter's does.
M src/backend/optimizer/path/joinrels.c
pg_dump, pg_upgrade: allow postgres/template1 tablespace moves
commit : 52b07779ddd07d5cbe4b833c91061bb8ca9379aa
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 11 Sep 2015 15:51:10 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 11 Sep 2015 15:51:10 -0400
Modify pg_dump to restore postgres/template1 databases to non-default
tablespaces by switching out of the database to be moved, then switching
back.
Also, to fix potentially cases where the old/new tablespaces might not
match, fix pg_upgrade to process new/old tablespaces separately in all
cases.
Report by Marti Raudsepp
Patch by Marti Raudsepp, me
Backpatch through 9.0
M contrib/pg_upgrade/info.c
M src/bin/pg_dump/pg_dumpall.c
Revert "Fix typo in setrefs.c"
commit : 6d36d7b63f298a335f495c579cdcde903b4e0645
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Sep 2015 10:26:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Sep 2015 10:26:58 -0400
This reverts commit 0473e047877ab9e51d5130bc14276b2308ed77a8.
M src/backend/optimizer/plan/setrefs.c
Fix typo in setrefs.c
commit : 0473e047877ab9e51d5130bc14276b2308ed77a8
author : Stephen Frost <sfrost@snowman.net>
date : Thu, 10 Sep 2015 09:22:44 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Thu, 10 Sep 2015 09:22:44 -0400
We're adding OIDs, not TIDs, to invalItems.
Pointed out by Etsuro Fujita.
Back-patch to all supported branches.
M src/backend/optimizer/plan/setrefs.c
Fix minor bug in regexp makesearch() function.
commit : 669856714222cc27d6ce08b80ed774e854830673
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 9 Sep 2015 20:14:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 9 Sep 2015 20:14:58 -0400
The list-wrangling here was done wrong, allowing the same state to get
put into the list twice. The following loop then would clone it twice.
The second clone would wind up with no inarcs, so that there was no
observable misbehavior AFAICT, but a useless state in the finished NFA
isn't an especially good thing.
M src/backend/regex/regcomp.c
Add gin_fuzzy_search_limit to postgresql.conf.sample.
commit : cc28f77c27fb23a071f79272333622d293f33729
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 9 Sep 2015 02:25:50 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 9 Sep 2015 02:25:50 +0900
This was forgotten in 8a3631f (commit that originally added the parameter)
and 0ca9907 (commit that added the documentation later that year).
Back-patch to all supported versions.
M src/backend/utils/misc/postgresql.conf.sample
Fix error message wording in previous sslinfo commit
commit : 625f488711f85b35b54f56dce3f8923e29df7df2
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 8 Sep 2015 11:10:20 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 8 Sep 2015 11:10:20 -0300
M contrib/sslinfo/sslinfo.c
Add more sanity checks in contrib/sslinfo
commit : 7febdf36adf254051773d5481a8d5e133ca82563
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 7 Sep 2015 19:18:29 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 7 Sep 2015 19:18:29 -0300
We were missing a few return checks on OpenSSL calls. Should be pretty
harmless, since we haven't seen any user reports about problems, and
this is not a high-traffic module anyway; still, a bug is a bug, so
backpatch this all the way back to 9.0.
Author: Michael Paquier, while reviewing another sslinfo patch
M contrib/sslinfo/sslinfo.c
Change type of DOW/DOY to UNITS
commit : 92d956f51d5ef093652598aee0da63624d6eceec
author : Greg Stark <stark@mit.edu>
date : Mon, 7 Sep 2015 13:35:09 +0100
committer: Greg Stark <stark@mit.edu>
date : Mon, 7 Sep 2015 13:35:09 +0100
M src/interfaces/ecpg/pgtypeslib/dt_common.c
Make GIN's cleanup pending list process interruptable
commit : a7496aee617314d77b52ee22c8f1f677888902ae
author : Teodor Sigaev <teodor@sigaev.ru>
date : Mon, 7 Sep 2015 17:20:44 +0300
committer: Teodor Sigaev <teodor@sigaev.ru>
date : Mon, 7 Sep 2015 17:20:44 +0300
Cleanup process could be called by ordinary insert/update and could take a lot
of time. Add vacuum_delay_point() to make this process interruptable. Under
vacuum this call will also throttle a vacuum process to decrease system load,
called from insert/update it will not throttle, and that reduces a latency.
Backpatch for all supported branches.
Jeff Janes <jeff.janes@gmail.com>
M src/backend/access/gin/ginfast.c
Update site address of Snowball project
commit : fad42aae97bfce325770f433948c13e1c26ed0a3
author : Teodor Sigaev <teodor@sigaev.ru>
date : Mon, 7 Sep 2015 15:22:29 +0300
committer: Teodor Sigaev <teodor@sigaev.ru>
date : Mon, 7 Sep 2015 15:22:29 +0300
M doc/src/sgml/textsearch.sgml
Move DTK_ISODOW DTK_DOW and DTK_DOY to be type UNITS rather than RESERV. RESERV is meant for tokens like "now" and having them in that category throws errors like these when used as an input date:
commit : 530d0c504fe636b0ed4a3817b1e9806dd55a52b6
author : Greg Stark <stark@mit.edu>
date : Sun, 6 Sep 2015 04:02:57 +0100
committer: Greg Stark <stark@mit.edu>
date : Sun, 6 Sep 2015 04:02:57 +0100
stark=# SELECT 'doy'::timestamptz;
ERROR: unexpected dtype 33 while parsing timestamptz "doy"
LINE 1: SELECT 'doy'::timestamptz;
^
stark=# SELECT 'dow'::timestamptz;
ERROR: unexpected dtype 32 while parsing timestamptz "dow"
LINE 1: SELECT 'dow'::timestamptz;
^
Found by LLVM's Libfuzzer
M src/backend/utils/adt/datetime.c
M src/backend/utils/adt/timestamp.c
Fix misc typos.
commit : 567acf259b25961e473d48e288ec3c98d7008763
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sat, 5 Sep 2015 11:35:49 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sat, 5 Sep 2015 11:35:49 +0300
Oskari Saarenmaa. Backpatch to stable branches where applicable.
M contrib/btree_gist/btree_ts.c
M contrib/btree_gist/btree_utils_var.c
M src/backend/access/common/heaptuple.c
M src/backend/access/gin/ginfast.c
M src/backend/optimizer/path/costsize.c
Fix subtransaction cleanup after an outer-subtransaction portal fails.
commit : 81ee435c42a857dedafd80e043ae05fe3ba25039
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Sep 2015 13:36:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Sep 2015 13:36:50 -0400
Formerly, we treated only portals created in the current subtransaction as
having failed during subtransaction abort. However, if the error occurred
while running a portal created in an outer subtransaction (ie, a cursor
declared before the last savepoint), that has to be considered broken too.
To allow reliable detection of which ones those are, add a bookkeeping
field to struct Portal that tracks the innermost subtransaction in which
each portal has actually been executed. (Without this, we'd end up
failing portals containing functions that had called the subtransaction,
thereby breaking plpgsql exception blocks completely.)
In addition, when we fail an outer-subtransaction Portal, transfer its
resources into the subtransaction's resource owner, so that they're
released early in cleanup of the subxact. This fixes a problem reported by
Jim Nasby in which a function executed in an outer-subtransaction cursor
could cause an Assert failure or crash by referencing a relation created
within the inner subtransaction.
The proximate cause of the Assert failure is that AtEOSubXact_RelationCache
assumed it could blow away a relcache entry without first checking that the
entry had zero refcount. That was a bad idea on its own terms, so add such
a check there, and to the similar coding in AtEOXact_RelationCache. This
provides an independent safety measure in case there are still ways to
provoke the situation despite the Portal-level changes.
This has been broken since subtransactions were invented, so back-patch
to all supported branches.
Tom Lane and Michael Paquier
M src/backend/access/transam/xact.c
M src/backend/commands/portalcmds.c
M src/backend/tcop/pquery.c
M src/backend/utils/cache/relcache.c
M src/backend/utils/mmgr/portalmem.c
M src/include/utils/portal.h
M src/test/regress/expected/transactions.out
M src/test/regress/sql/transactions.sql
Fix s_lock.h PPC assembly code to be compatible with native AIX assembler.
commit : b5a22d8bbda6f53740c8c1813ceb78f13d9da779
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Aug 2015 16:09:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Aug 2015 16:09:25 -0400
On recent AIX it's necessary to configure gcc to use the native assembler
(because the GNU assembler hasn't been updated to handle AIX 6+). This
caused PG builds to fail with assembler syntax errors, because we'd try
to compile s_lock.h's gcc asm fragment for PPC, and that assembly code
relied on GNU-style local labels. We can't substitute normal labels
because it would fail in any file containing more than one inlined use of
tas(). Fortunately, that code is stable enough, and the PPC ISA is simple
enough, that it doesn't seem like too much of a maintenance burden to just
hand-code the branch offsets, removing the need for any labels.
Note that the AIX assembler only accepts "$" for the location counter
pseudo-symbol. The usual GNU convention is "."; but it appears that all
versions of gas for PPC also accept "$", so in theory this patch will not
break any other PPC platforms.
This has been reported by a few people, but Steve Underwood gets the credit
for being the first to pursue the problem far enough to understand why it
was failing. Thanks also to Noah Misch for additional testing.
M src/include/storage/s_lock.h
dblink docs: fix typo to use "connname" (3 n's), not "conname"
commit : bbe6d231a0819915081e4693eaa02a31ac2fef6c
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 27 Aug 2015 13:43:10 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 27 Aug 2015 13:43:10 -0400
This makes the parameter names match the documented prototype names.
Report by Erwin Brandstetter
Backpatch through 9.0
M doc/src/sgml/dblink.sgml
Docs: be explicit about datatype matching for lead/lag functions.
commit : 23ddcd77b72bdbec4f8e5fb618febefa1fea4d2d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Aug 2015 19:12:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Aug 2015 19:12:57 -0400
The default argument, if given, has to be of exactly the same datatype
as the first argument; but this was not stated in so many words, and
the error message you get about it might not lead your thought in the
right direction. Per bug #13587 from Robert McGehee.
A quick scan says that these are the only two built-in functions with two
anyelement arguments and no other polymorphic arguments. There are plenty
of cases of, eg, anyarray and anyelement, but those seem less likely to
confuse. For instance this doesn't seem terribly hard to figure out:
"function array_remove(integer[], numeric) does not exist". So I've
contented myself with fixing these two cases.
M doc/src/sgml/func.sgml
Avoid O(N^2) behavior when enlarging SPI tuple table in spi_printtup().
commit : 7c57449fc5855361d3a69374192c58fb68ce3e67
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Aug 2015 20:32:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Aug 2015 20:32:11 -0400
For no obvious reason, spi_printtup() was coded to enlarge the tuple
pointer table by just 256 slots at a time, rather than doubling the size at
each reallocation, as is our usual habit. For very large SPI results, this
makes for O(N^2) time spent in repalloc(), which of course soon comes to
dominate the runtime. Use the standard doubling approach instead.
This is a longstanding performance bug, so back-patch to all active
branches.
Neil Conway
M src/backend/executor/spi.c
Fix a few bogus statement type names in plpgsql error messages.
commit : e41718fa1eb67210808c9b5a084fc1aaffde5b35
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Aug 2015 19:22:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Aug 2015 19:22:38 -0400
plpgsql's error location context messages ("PL/pgSQL function fn-name line
line-no at stmt-type") would misreport a CONTINUE statement as being an
EXIT, and misreport a MOVE statement as being a FETCH. These are clear
bugs that have been there a long time, so back-patch to all supported
branches.
In addition, in 9.5 and HEAD, change the description of EXECUTE from
"EXECUTE statement" to just plain EXECUTE; there seems no good reason why
this statement type should be described differently from others that have
a well-defined head keyword. And distinguish GET STACKED DIAGNOSTICS from
plain GET DIAGNOSTICS. These are a bit more of a judgment call, and also
affect existing regression-test outputs, so I did not back-patch into
stable branches.
Pavel Stehule and Tom Lane
M src/pl/plpgsql/src/pl_funcs.c
Improve documentation about MVCC-unsafe utility commands.
commit : ec2bc39e8910d05e27794e5095b7b8daed981406
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Aug 2015 13:30:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Aug 2015 13:30:16 -0400
The table-rewriting forms of ALTER TABLE are MVCC-unsafe, in much the same
way as TRUNCATE, because they replace all rows of the table with newly-made
rows with a new xmin. (Ideally, concurrent transactions with old snapshots
would continue to see the old table contents, but the data is not there
anymore --- and if it were there, it would be inconsistent with the table's
updated rowtype, so there would be serious implementation problems to fix.)
This was nowhere documented though, and the problem was only documented for
TRUNCATE in a note in the TRUNCATE reference page. Create a new "Caveats"
section in the MVCC chapter that can be home to this and other limitations
on serializable consistency.
In passing, fix a mistaken statement that VACUUM and CLUSTER would reclaim
space occupied by a dropped column. They don't reconstruct existing tuples
so they couldn't do that.
Back-patch to all supported branches.
M doc/src/sgml/mvcc.sgml
M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/ref/truncate.sgml
Use fuzzy path cost tiebreaking rule in our oldest supported branches.
commit : 9d6af7367e7b079c021c285f03128bad531b667e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Aug 2015 11:02:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Aug 2015 11:02:17 -0400
We've been doing it that way since 9.2, cf commit 33e99153e93b9acc,
but some recently-added regression test cases are making a few buildfarm
members fail (ie choose the "wrong" plan) in 9.0 and 9.1 due to
platform-specific roundoff differences in cost calculations. To fix,
back-port the patch that made add_path treat cost difference ratios of
less than 1e-10 as equal.
M src/backend/optimizer/util/pathnode.c
Don't use 'bool' as a struct member name in help_config.c.
commit : 24906bbc22650b5bfefd1594de557dc83a71cee5
author : Andres Freund <andres@anarazel.de>
date : Wed, 12 Aug 2015 16:02:20 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 12 Aug 2015 16:02:20 +0200
Doing so doesn't work if bool is a macro rather than a typedef.
Although c.h spends some effort to support configurations where bool is
a preexisting macro, help_config.c has existed this way since
2003 (b700a6), and there have not been any reports of
problems. Backpatch anyway since this is as riskless as it gets.
Discussion: 20150812084351.GD8470@awork2.anarazel.de
Backpatch: 9.0-master
M src/backend/utils/misc/help_config.c
Fix declaration of isarray variable.
commit : 41a6633601cb1cb1ef6a2185415fb0057c744971
author : Michael Meskes <meskes@postgresql.org>
date : Thu, 13 Aug 2015 13:22:29 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Thu, 13 Aug 2015 13:22:29 +0200
Found and fixed by Andres Freund.
M src/interfaces/ecpg/ecpglib/execute.c
M src/interfaces/ecpg/ecpglib/extern.h
Undo mistaken tightening in join_is_legal().
commit : 7b4b57fc484ab8edb4c921cd4b18f2b5b379ef44
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Aug 2015 21:18:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Aug 2015 21:18:45 -0400
One of the changes I made in commit 8703059c6b55c427 turns out not to have
been such a good idea: we still need the exception in join_is_legal() that
allows a join if both inputs already overlap the RHS of the special join
we're checking. Otherwise we can miss valid plans, and might indeed fail
to find a plan at all, as in recent report from Andreas Seltenreich.
That code was added way back in commit c17117649b9ae23d, but I failed to
include a regression test case then; my bad. Put it back with a better
explanation, and a test this time. The logic does end up a bit different
than before though: I now believe it's appropriate to make this check
first, thereby allowing such a case whether or not we'd consider the
previous SJ(s) to commute with this one. (Presumably, we already decided
they did; but it was confusing to have this consideration in the middle
of the code that was handling the other case.)
Back-patch to all active branches, like the previous patch.
M src/backend/optimizer/path/joinrels.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
This routine was calling ecpg_alloc to allocate to memory but did not actually check the returned pointer allocated, potentially NULL which could be the result of a malloc call.
commit : d4215954747e5463ea5c161aa776040ec45c40e4
author : Michael Meskes <meskes@postgresql.org>
date : Thu, 5 Feb 2015 15:12:34 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Thu, 5 Feb 2015 15:12:34 +0100
Issue noted by Coverity, fixed by Michael Paquier <michael@otacoo.com>
M src/interfaces/ecpg/ecpglib/descriptor.c
M src/interfaces/ecpg/ecpglib/execute.c
M src/interfaces/ecpg/ecpglib/extern.h
M src/interfaces/ecpg/ecpglib/memory.c
Fix some possible low-memory failures in regexp compilation.
commit : 7e23b63bd8e0776f90c915d72fced4215eefadb0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Aug 2015 00:48:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Aug 2015 00:48:11 -0400
newnfa() failed to set the regex error state when malloc() fails.
Several places in regcomp.c failed to check for an error after calling
subre(). Each of these mistakes could lead to null-pointer-dereference
crashes in memory-starved backends.
Report and patch by Andreas Seltenreich. Back-patch to all branches.
M src/backend/regex/regc_nfa.c
M src/backend/regex/regcomp.c
Fix privilege dumping from servers too old to have that type of privilege.
commit : 298d1f80805ee9aed728fc2240b70476370c8100
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Aug 2015 20:10:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Aug 2015 20:10:16 -0400
pg_dump produced fairly silly GRANT/REVOKE commands when dumping types from
pre-9.2 servers, and when dumping functions or procedural languages from
pre-7.3 servers. Those server versions lack the typacl, proacl, and/or
lanacl columns respectively, and pg_dump substituted default values that
were in fact incorrect. We ended up revoking all the owner's own
privileges for the object while granting all privileges to PUBLIC.
Of course the owner would then have those privileges again via PUBLIC, so
long as she did not try to revoke PUBLIC's privileges; which may explain
the lack of field reports. Nonetheless this is pretty silly behavior.
The stakes were raised by my recent patch to make pg_dump dump shell types,
because 9.2 and up pg_dump would proceed to emit bogus GRANT/REVOKE
commands for a shell type if dumping from a pre-9.2 server; and the server
will not accept GRANT/REVOKE commands for a shell type. (Perhaps it
should, but that's a topic for another day.) So the resulting dump script
wouldn't load without errors.
The right thing to do is to act as though these objects have default
privileges (null ACL entries), which causes pg_dump to print no
GRANT/REVOKE commands at all for them. That fixes the silly results
and also dodges the problem with shell types.
In passing, modify getProcLangs() to be less creatively different about
how to handle missing columns when dumping from older server versions.
Every other data-acquisition function in pg_dump does that by substituting
appropriate default values in the version-specific SQL commands, and I see
no reason why this one should march to its own drummer. Its use of
"SELECT *" was likewise not conformant with anyplace else, not to mention
it's not considered good SQL style for production queries.
Back-patch to all supported versions. Although 9.0 and 9.1 pg_dump don't
have the issue with typacl, they are more likely than newer versions to be
used to dump from ancient servers, so we ought to fix the proacl/lanacl
issues all the way back.
M src/bin/pg_dump/pg_dump.c
Accept alternate spellings of __sparcv7 and __sparcv8.
commit : a6b279cb31f1a22f43cd65acf05dc24c5ba9eaf9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Aug 2015 17:34:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Aug 2015 17:34:51 -0400
Apparently some versions of gcc prefer __sparc_v7__ and __sparc_v8__.
Per report from Waldemar Brodkorb.
M src/include/storage/s_lock.h
Further fixes for degenerate outer join clauses.
commit : d860ba43ffe08c53d9e096fd21eb500b69126d70
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Aug 2015 15:35:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Aug 2015 15:35:28 -0400
Further testing revealed that commit f69b4b9495269cc4 was still a few
bricks shy of a load: minor tweaking of the previous test cases resulted
in the same wrong-outer-join-order problem coming back. After study
I concluded that my previous changes in make_outerjoininfo() were just
accidentally masking the problem, and should be reverted in favor of
forcing syntactic join order whenever an upper outer join's predicate
doesn't mention a lower outer join's LHS. This still allows the
chained-outer-joins style that is the normally optimizable case.
I also tightened things up some more in join_is_legal(). It seems to me
on review that what's really happening in the exception case where we
ignore a mismatched special join is that we're allowing the proposed join
to associate into the RHS of the outer join we're comparing it to. As
such, we should *always* insist that the proposed join be a left join,
which eliminates a bunch of rather dubious argumentation. The case where
we weren't enforcing that was the one that was already known buggy anyway
(it had a violatable Assert before the aforesaid commit) so it hardly
deserves a lot of deference.
Back-patch to all active branches, like the previous patch. The added
regression test case failed in all branches back to 9.1, and I think it's
only an unrelated change in costing calculations that kept 9.0 from
choosing a broken plan.
M src/backend/optimizer/README
M src/backend/optimizer/path/joinrels.c
M src/backend/optimizer/plan/initsplan.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Make real sure we don't reassociate joins into or out of SEMI/ANTI joins.
commit : c084f613e20165012974db44106e4c5174c2ba5f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 5 Aug 2015 14:39:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 5 Aug 2015 14:39:07 -0400
Per the discussion in optimizer/README, it's unsafe to reassociate anything
into or out of the RHS of a SEMI or ANTI join. An example from Piotr
Stefaniak showed that join_is_legal() wasn't sufficiently enforcing this
rule, so lock it down a little harder.
I couldn't find a reasonably simple example of the optimizer trying to
do this, so no new regression test. (Piotr's example involved the random
search in GEQO accidentally trying an invalid case and triggering a sanity
check way downstream in clause selectivity estimation, which did not seem
like a sequence of events that would be useful to memorialize in a
regression test as-is.)
Back-patch to all active branches.
M src/backend/optimizer/path/joinrels.c
Docs: add an explicit example about controlling overall greediness of REs.
commit : f9ab07be9fbaa95735ae4c3a6592ad058e2c1819
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 21:09:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 21:09:12 -0400
Per discussion of bug #13538.
M doc/src/sgml/func.sgml
Fix pg_dump to dump shell types.
commit : 5d175be17b46374f7aaf15b2fc6b0ac5d75a3467
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 19:34:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 19:34:12 -0400
Per discussion, it really ought to do this. The original choice to
exclude shell types was probably made in the dark ages before we made
it harder to accidentally create shell types; but that was in 7.3.
Also, cause the standard regression tests to leave a shell type behind,
for convenience in testing the case in pg_dump and pg_upgrade.
Back-patch to all supported branches.
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/test/regress/expected/create_type.out
M src/test/regress/sql/create_type.sql
Fix bogus "out of memory" reports in tuplestore.c.
commit : bd327627f6c0a8acb2674aea8ccb2ecb776345f4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 18:18:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 18:18:47 -0400
The tuplesort/tuplestore memory management logic assumed that the chunk
allocation overhead for its memtuples array could not increase when
increasing the array size. This is and always was true for tuplesort,
but we (I, I think) blindly copied that logic into tuplestore.c without
noticing that the assumption failed to hold for the much smaller array
elements used by tuplestore. Given rather small work_mem, this could
result in an improper complaint about "unexpected out-of-memory situation",
as reported by Brent DeSpain in bug #13530.
The easiest way to fix this is just to increase tuplestore's initial
array size so that the assumption holds. Rather than relying on magic
constants, though, let's export a #define from aset.c that represents
the safe allocation threshold, and make tuplestore's calculation depend
on that.
Do the same in tuplesort.c to keep the logic looking parallel, even though
tuplesort.c isn't actually at risk at present. This will keep us from
breaking it if we ever muck with the allocation parameters in aset.c.
Back-patch to all supported versions. The error message doesn't occur
pre-9.3, not so much because the problem can't happen as because the
pre-9.3 tuplestore code neglected to check for it. (The chance of
trouble is a great deal larger as of 9.3, though, due to changes in the
array-size-increasing strategy.) However, allowing LACKMEM() to become
true unexpectedly could still result in less-than-desirable behavior,
so let's patch it all the way back.
M src/backend/utils/mmgr/aset.c
M src/backend/utils/sort/tuplesort.c
M src/backend/utils/sort/tuplestore.c
M src/include/utils/memutils.h
Cap wal_buffers to avoid a server crash when it's set very large.
commit : b09446ed7eecc7cee6f7cc1dcc954c75c6c7570b
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 4 Aug 2015 12:58:54 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 4 Aug 2015 12:58:54 -0400
It must be possible to multiply wal_buffers by XLOG_BLCKSZ without
overflowing int, or calculations in StartupXLOG will go badly wrong
and crash the server. Avoid that by imposing a maximum value on
wal_buffers. This will be just under 2GB, assuming the usual value
for XLOG_BLCKSZ.
Josh Berkus, per an analysis by Andrew Gierth.
M src/backend/utils/misc/guc.c
Fix incorrect order of lock file removal and failure to close() sockets.
commit : 8b53c087d2685e187b8a8e2ea8b924d597396f2b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Aug 2015 14:54:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Aug 2015 14:54:44 -0400
Commit c9b0cbe98bd783e24a8c4d8d8ac472a494b81292 accidentally broke the
order of operations during postmaster shutdown: it resulted in removing
the per-socket lockfiles after, not before, postmaster.pid. This creates
a race-condition hazard for a new postmaster that's started immediately
after observing that postmaster.pid has disappeared; if it sees the
socket lockfile still present, it will quite properly refuse to start.
This error appears to be the explanation for at least some of the
intermittent buildfarm failures we've seen in the pg_upgrade test.
Another problem, which has been there all along, is that the postmaster
has never bothered to close() its listen sockets, but has just allowed them
to close at process death. This creates a different race condition for an
incoming postmaster: it might be unable to bind to the desired listen
address because the old postmaster is still incumbent. This might explain
some odd failures we've seen in the past, too. (Note: this is not related
to the fact that individual backends don't close their client communication
sockets. That behavior is intentional and is not changed by this patch.)
Fix by adding an on_proc_exit function that closes the postmaster's ports
explicitly, and (in 9.3 and up) reshuffling the responsibility for where
to unlink the Unix socket files. Lock file unlinking can stay where it
is, but teach it to unlink the lock files in reverse order of creation.
M src/backend/postmaster/postmaster.c
Fix some planner issues with degenerate outer join clauses.
commit : 44679965f0bdf42275a567751fdddfe759795ee4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 1 Aug 2015 20:57:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 1 Aug 2015 20:57:41 -0400
An outer join clause that didn't actually reference the RHS (perhaps only
after constant-folding) could confuse the join order enforcement logic,
leading to wrong query results. Also, nested occurrences of such things
could trigger an Assertion that on reflection seems incorrect.
Per fuzz testing by Andreas Seltenreich. The practical use of such cases
seems thin enough that it's not too surprising we've not heard field
reports about it.
This has been broken for a long time, so back-patch to all active branches.
M src/backend/optimizer/path/joinrels.c
M src/backend/optimizer/plan/initsplan.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Avoid some zero-divide hazards in the planner.
commit : 54833c5e772ee0e8461269e1b40ab6b9fae4b1cd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 30 Jul 2015 12:11:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 30 Jul 2015 12:11:23 -0400
Although I think on all modern machines floating division by zero
results in Infinity not SIGFPE, we still don't want infinities
running around in the planner's costing estimates; too much risk
of that leading to insane behavior.
grouping_planner() failed to consider the possibility that final_rel
might be known dummy and hence have zero rowcount. (I wonder if it
would be better to set a rows estimate of 1 for dummy relations?
But at least in the back branches, changing this convention seems
like a bad idea, so I'll leave that for another day.)
Make certain that get_variable_numdistinct() produces a nonzero result.
The case that can be shown to be broken is with stadistinct < 0.0 and
small ntuples; we did not prevent the result from rounding to zero.
For good luck I applied clamp_row_est() to all the nonconstant return
values.
In ExecChooseHashTableSize(), Assert that we compute positive nbuckets
and nbatch. I know of no reason to think this isn't the case, but it
seems like a good safety check.
Per reports from Piotr Stefaniak. Back-patch to all active branches.
M src/backend/executor/nodeHash.c
M src/backend/optimizer/plan/planmain.c
M src/backend/optimizer/plan/planner.c
M src/backend/utils/adt/selfuncs.c
Blacklist xlc 32-bit inlining.
commit : 2d8c136e745168cb8d20f3e2728a602f9ba02921
author : Noah Misch <noah@leadboat.com>
date : Wed, 29 Jul 2015 22:49:48 -0400
committer: Noah Misch <noah@leadboat.com>
date : Wed, 29 Jul 2015 22:49:48 -0400
Per a suggestion from Tom Lane. Back-patch to 9.0 (all supported
versions). While only 9.4 and up have code known to elicit this
compiler bug, we were disabling inlining by accident until commit
43d89a23d59c487bc9258fad7a6187864cb8c0c0.
M config/test_quiet_include.h
Update our documentation concerning where to create data directories.
commit : 208e41d9133b26f2de04619c66fc7b31a0777c9e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 28 Jul 2015 18:42:59 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 28 Jul 2015 18:42:59 -0400
Although initdb has long discouraged use of a filesystem mount-point
directory as a PG data directory, this point was covered nowhere in the
user-facing documentation. Also, with the popularity of pg_upgrade,
we really need to recommend that the PG user own not only the data
directory but its parent directory too. (Without a writable parent
directory, operations such as "mv data data.old" fail immediately.
pg_upgrade itself doesn't do that, but wrapper scripts for it often do.)
Hence, adjust the "Creating a Database Cluster" section to address
these points. I also took the liberty of wordsmithing the discussion
of NFS a bit.
These considerations aren't by any means new, so back-patch to all
supported branches.
M doc/src/sgml/runtime.sgml
Reduce chatter from signaling of autovacuum workers.
commit : f527c0a2a7c8507163bc22107c9d6a10b5f17174
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 28 Jul 2015 17:34:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 28 Jul 2015 17:34:00 -0400
Don't print a WARNING if we get ESRCH from a kill() that's attempting
to cancel an autovacuum worker. It's possible (and has been seen in the
buildfarm) that the worker is already gone by the time we are able to
execute the kill, in which case the failure is harmless. About the only
plausible reason for reporting such cases would be to help debug corrupted
lock table contents, but this is hardly likely to be the most important
symptom if that happens. Moreover issuing a WARNING might scare users
more than is warranted.
Also, since sending a signal to an autovacuum worker is now entirely a
routine thing, and the worker will log the query cancel on its end anyway,
reduce the message saying we're doing that from LOG to DEBUG1 level.
Very minor cosmetic cleanup as well.
Since the main practical reason for doing this is to avoid unnecessary
buildfarm failures, back-patch to all active branches.
M src/backend/storage/lmgr/proc.c
Disable ssl renegotiation by default.
commit : 444b2ebee97fdbabbb32ec7b4ebd1b6f40638ec5
author : Andres Freund <andres@anarazel.de>
date : Tue, 28 Jul 2015 21:39:40 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 28 Jul 2015 21:39:40 +0200
While postgres' use of SSL renegotiation is a good idea in theory, it
turned out to not work well in practice. The specification and openssl's
implementation of it have lead to several security issues. Postgres' use
of renegotiation also had its share of bugs.
Additionally OpenSSL has a bunch of bugs around renegotiation, reported
and open for years, that regularly lead to connections breaking with
obscure error messages. We tried increasingly complex workarounds to get
around these bugs, but we didn't find anything complete.
Since these connection breakages often lead to hard to debug problems,
e.g. spuriously failing base backups and significant latency spikes when
synchronous replication is used, we have decided to change the default
setting for ssl renegotiation to 0 (disabled) in the released
backbranches and remove it entirely in 9.5 and master..
Author: Michael Paquier, with changes by me
Discussion: 20150624144148.GQ4797@alap3.anarazel.de
Backpatch: 9.0-9.4; 9.5 and master get a different patch
M doc/src/sgml/config.sgml
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample
Reuse all-zero pages in GIN.
commit : f87bf848067490fac09489b9be389539b340d1c5
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 27 Jul 2015 12:30:26 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 27 Jul 2015 12:30:26 +0300
In GIN, an all-zeros page would be leaked forever, and never reused. Just
add them to the FSM in vacuum, and they will be reinitialized when grabbed
from the FSM. On master and 9.5, attempting to access the page's opaque
struct also caused an assertion failure, although that was otherwise
harmless.
Reported by Jeff Janes. Backpatch to all supported versions.
M src/backend/access/gin/ginvacuum.c
Fix off-by-one error in calculating subtrans/multixact truncation point.
commit : 40ad7822019a2cf8b9e0d5bd770490af7b56e652
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 23 Jul 2015 01:30:19 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 23 Jul 2015 01:30:19 +0300
If there were no subtransactions (or multixacts) active, we would calculate
the oldestxid == next xid. That's correct, but if next XID happens to be
on the next pg_subtrans (pg_multixact) page, the page does not exist yet,
and SimpleLruTruncate will produce an "apparent wraparound" warning. The
warning is harmless in this case, but looks very alarming to users.
Backpatch to all supported versions. Patch and analysis by Thomas Munro.
M src/backend/access/transam/multixact.c
M src/backend/access/transam/subtrans.c
M src/include/access/multixact.h
Fix (some of) pltcl memory usage
commit : 4c11967e7348b79a27738a6f714d61325c660c5b
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 20 Jul 2015 14:18:08 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 20 Jul 2015 14:18:08 +0200
As reported by Bill Parker, PL/Tcl did not validate some malloc() calls
against NULL return. Fix by using palloc() in a new long-lived memory
context instead. This allows us to simplify error handling too, by
simply deleting the memory context instead of doing retail frees.
There's still a lot that could be done to improve PL/Tcl's memory
handling ...
This is pretty ancient, so backpatch all the way back.
Author: Michael Paquier and Álvaro Herrera
Discussion: https://www.postgresql.org/message-id/CAFrbyQwyLDYXfBOhPfoBGqnvuZO_Y90YgqFM11T2jvnxjLFmqw@mail.gmail.com
M src/pl/tcl/pltcl.c
AIX: Test the -qlonglong option before use.
commit : cdf596b1ceb6193ab6c1e24c57531423243fce4b
author : Noah Misch <noah@leadboat.com>
date : Fri, 17 Jul 2015 03:01:14 -0400
committer: Noah Misch <noah@leadboat.com>
date : Fri, 17 Jul 2015 03:01:14 -0400
xlc provides "long long" unconditionally at C99-compatible language
levels, and this option provokes a warning. The warning interferes with
"configure" tests that fail in response to any warning. Notably, before
commit 85a2a8903f7e9151793308d0638621003aded5ae, it interfered with the
test for -qnoansialias. Back-patch to 9.0 (all supported versions).
M configure
M configure.in
M src/template/aix
Fix a low-probability crash in our qsort implementation.
commit : 36522d6276bf6b073f5fdf83dcc226d547363083
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 Jul 2015 22:57:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 Jul 2015 22:57:46 -0400
It's standard for quicksort implementations, after having partitioned the
input into two subgroups, to recurse to process the smaller partition and
then handle the larger partition by iterating. This method guarantees
that no more than log2(N) levels of recursion can be needed. However,
Bentley and McIlroy argued that checking to see which partition is smaller
isn't worth the cycles, and so their code doesn't do that but just always
recurses on the left partition. In most cases that's fine; but with
worst-case input we might need O(N) levels of recursion, and that means
that qsort could be driven to stack overflow. Such an overflow seems to
be the only explanation for today's report from Yiqing Jin of a SIGSEGV
in med3_tuple while creating an index of a couple billion entries with a
very large maintenance_work_mem setting. Therefore, let's spend the few
additional cycles and lines of code needed to choose the smaller partition
for recursion.
Also, fix up the qsort code so that it properly uses size_t not int for
some intermediate values representing numbers of items. This would only
be a live risk when sorting more than INT_MAX bytes (in qsort/qsort_arg)
or tuples (in qsort_tuple), which I believe would never happen with any
caller in the current core code --- but perhaps it could happen with
call sites in third-party modules? In any case, this is trouble waiting
to happen, and the corrected code is probably if anything shorter and
faster than before, since it removes sign-extension steps that had to
happen when converting between int and size_t.
In passing, move a couple of CHECK_FOR_INTERRUPTS() calls so that it's
not necessary to preserve the value of "r" across them, and prettify
the output of gen_qsort_tuple.pl a little.
Back-patch to all supported branches. The odds of hitting this issue
are probably higher in 9.4 and up than before, due to the new ability
to allocate sort workspaces exceeding 1GB, but there's no good reason
to believe that it's impossible to crash older branches this way.
M src/port/qsort.c
M src/port/qsort_arg.c
AIX: Link the postgres executable with -Wl,-brtllib.
commit : 7803d5720f9bceb2a12b5ec1fbbad03d4088203b
author : Noah Misch <noah@leadboat.com>
date : Wed, 15 Jul 2015 21:00:26 -0400
committer: Noah Misch <noah@leadboat.com>
date : Wed, 15 Jul 2015 21:00:26 -0400
This allows PostgreSQL modules and their dependencies to have undefined
symbols, resolved at runtime. Perl module shared objects rely on that
in Perl 5.8.0 and later. This fixes the crash when PL/PerlU loads such
modules, as the hstore_plperl test suite does. Module authors can link
using -Wl,-G to permit undefined symbols; by default, linking will fail
as it has. Back-patch to 9.0 (all supported versions).
M src/backend/Makefile
Fix postmaster's handling of a startup-process crash.
commit : 6718f07a0b31219487f7e8094d35959d328c9b56
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 Jul 2015 13:22:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 Jul 2015 13:22:23 -0400
Ordinarily, a failure (unexpected exit status) of the startup subprocess
should be considered fatal, so the postmaster should just close up shop
and quit. However, if we sent the startup process a SIGQUIT or SIGKILL
signal, the failure is hardly "unexpected", and we should attempt restart;
this is necessary for recovery from ordinary backend crashes in hot-standby
scenarios. I attempted to implement the latter rule with a two-line patch
in commit 442231d7f71764b8c628044e7ce2225f9aa43b67, but it now emerges that
that patch was a few bricks shy of a load: it failed to distinguish the
case of a signaled startup process from the case where the new startup
process crashes before reaching database consistency. That resulted in
infinitely respawning a new startup process only to have it crash again.
To handle this properly, we really must track whether we have sent the
*current* startup process a kill signal. Rather than add yet another
ad-hoc boolean to the postmaster's state, I chose to unify this with the
existing RecoveryError flag into an enum tracking the startup process's
state. That seems more consistent with the postmaster's general state
machine design.
Back-patch to 9.0, like the previous patch.
M src/backend/postmaster/postmaster.c
Fix another broken link in documentation.
commit : 338639902119db8014b9353c0715e7139f3e9a7a
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 9 Jul 2015 16:00:14 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 9 Jul 2015 16:00:14 +0300
Tom fixed another one of these in commit 7f32dbcd, but there was another
almost identical one in libpq docs. Per his comment:
HP's web server has apparently become case-sensitive sometime recently.
Per bug #13479 from Daniel Abraham. Corrected link identified by Alvaro.
M doc/src/sgml/libpq.sgml
Fix null pointer dereference in "\c" psql command.
commit : 6087bf1a198e42b811637101580af51a55fac505
author : Noah Misch <noah@leadboat.com>
date : Wed, 8 Jul 2015 20:44:21 -0400
committer: Noah Misch <noah@leadboat.com>
date : Wed, 8 Jul 2015 20:44:21 -0400
The psql crash happened when no current connection existed. (The second
new check is optional given today's undocumented NULL argument handling
in PQhost() etc.) Back-patch to 9.0 (all supported versions).
M src/bin/psql/command.c
Oops, PQExpBufferDataBroken doesn't exist before 9.2.
commit : 7a858f7bf47d88faf9a7b52194c939bb1477049e
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 7 Jul 2015 18:54:08 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 7 Jul 2015 18:54:08 +0300
My previous back-patching went wrong.
M src/interfaces/libpq/fe-protocol2.c
M src/interfaces/libpq/fe-protocol3.c
Improve handling of out-of-memory in libpq.
commit : 2b189c7ec1ffd1e626484621c515285bf5d0d5e3
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 7 Jul 2015 18:37:45 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 7 Jul 2015 18:37:45 +0300
If an allocation fails in the main message handling loop, pqParseInput3
or pqParseInput2, it should not be treated as "not enough data available
yet". Otherwise libpq will wait indefinitely for more data to arrive from
the server, and gets stuck forever.
This isn't a complete fix - getParamDescriptions and getCopyStart still
have the same issue, but it's a step in the right direction.
Michael Paquier and me. Backpatch to all supported versions.
M src/interfaces/libpq/fe-protocol2.c
M src/interfaces/libpq/fe-protocol3.c
Turn install.bat into a pure one line wrapper fort he perl script.
commit : 341b877d324b259fc1c81ef9c6dc2ea96d06d1e6
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 7 Jul 2015 16:31:52 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 7 Jul 2015 16:31:52 +0300
Build.bat and vcregress.bat got similar treatment years ago. I'm not sure
why install.bat wasn't treated at the same time, but it seems like a good
idea anyway.
The immediate problem with the old install.bat was that it had quoting
issues, and wouldn't work if the target directory's name contained spaces.
This fixes that problem.
I committed this to master yesterday, this is a backpatch of the same for
all supported versions.
M src/tools/msvc/install.bat
M src/tools/msvc/install.pl
Make numeric form of PG version number readily available in Makefiles.
commit : 29ff43adfbfdd072b1d1aa3846ec01ff3108b666
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 Jul 2015 12:01:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 Jul 2015 12:01:02 -0400
Expose PG_VERSION_NUM (e.g., "90600") as a Make variable; but for
consistency with the other Make variables holding similar info,
call the variable just VERSION_NUM not PG_VERSION_NUM.
There was some discussion of making this value available as a pg_config
value as well. However, that would entail substantially more work than
this two-line patch. Given that there was not exactly universal consensus
that we need this at all, let's just do a minimal amount of work for now.
Back-patch of commit a5d489ccb7e613c7ca3be6141092b8c1d2c13fa7, so that this
variable is actually useful for its intended purpose sometime before 2020.
Michael Paquier, reviewed by Pavel Stehule
M configure
M configure.in
M src/Makefile.global.in
PL/Perl: Add alternative expected file for Perl 5.22
commit : fdfe0b1cd9b1b604530640fd37f159590d8e237f
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 3 Jul 2015 18:04:33 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 3 Jul 2015 18:04:33 -0400
A src/pl/plperl/expected/plperl_elog_1.out
Fix broken link in documentation.
commit : 33018d0730f307c274e7536ca744614cfa705ef5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 30 Jun 2015 18:47:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 30 Jun 2015 18:47:32 -0400
HP's web server has apparently become case-sensitive sometime recently.
Per bug #13479 from Daniel Abraham. Corrected link identified by Alvaro.
M doc/src/sgml/runtime.sgml
Test -lrt for sched_yield
commit : b185c42c16d84ed7cfd406d6822459bcfee766a8
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 30 Jun 2015 14:20:37 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 30 Jun 2015 14:20:37 -0300
Apparently, this is needed in some Solaris versions.
Author: Oskari Saarenmaa
M configure
M configure.in
Revoke incorrectly applied patch version
commit : 2cb58109560d21abd9d1fa5dca2649be54cbeec0
author : Simon Riggs <simon@2ndQuadrant.com>
date : Sat, 27 Jun 2015 02:22:45 +0100
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Sat, 27 Jun 2015 02:22:45 +0100
M src/backend/access/heap/heapam.c
Avoid hot standby cancels from VAC FREEZE
commit : e1ca691f6b81bda44d2971e090804f0b94834711
author : Simon Riggs <simon@2ndQuadrant.com>
date : Sat, 27 Jun 2015 00:48:27 +0100
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Sat, 27 Jun 2015 00:48:27 +0100
VACUUM FREEZE generated false cancelations of standby queries on an
otherwise idle master. Caused by an off-by-one error on cutoff_xid
which goes back to original commit.
Backpatch to all versions 9.0+
Analysis and report by Marco Nenciarini
Bug fix by Simon Riggs
M src/backend/access/heap/heapam.c
Fix the logic for putting relations into the relcache init file.
commit : 45c69178b5ff5b5c7ff18fcb4e339d3524c0ec39
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Jun 2015 14:39:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Jun 2015 14:39:06 -0400
Commit f3b5565dd4e59576be4c772da364704863e6a835 was a couple of bricks shy
of a load; specifically, it missed putting pg_trigger_tgrelid_tgname_index
into the relcache init file, because that index is not used by any
syscache. However, we have historically nailed that index into cache for
performance reasons. The upshot was that load_relcache_init_file always
decided that the init file was busted and silently ignored it, resulting
in a significant hit to backend startup speed.
To fix, reinstantiate RelationIdIsInInitFile() as a wrapper around
RelationSupportsSysCache(), which can know about additional relations
that should be in the init file despite being unknown to syscache.c.
Also install some guards against future mistakes of this type: make
write_relcache_init_file Assert that all nailed relations get written to
the init file, and make load_relcache_init_file emit a WARNING if it takes
the "wrong number of nailed relations" exit path. Now that we remove the
init files during postmaster startup, that case should never occur in the
field, even if we are starting a minor-version update that added or removed
rels from the nailed set. So the warning shouldn't ever be seen by end
users, but it will show up in the regression tests if somebody breaks this
logic.
Back-patch to all supported branches, like the previous commit.
M src/backend/utils/cache/inval.c
M src/backend/utils/cache/relcache.c
M src/include/utils/relcache.h
Fix thinko in comment (launcher -> worker)
commit : 2c652c3fa5346c2fad2bdbed31720327a1f713a3
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sat, 20 Jun 2015 11:45:58 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sat, 20 Jun 2015 11:45:58 -0300
M src/backend/postmaster/autovacuum.c
Clamp autovacuum launcher sleep time to 5 minutes
commit : d68df5e40d430d03141b531afaf4e5ef8833ef7e
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 19 Jun 2015 12:44:33 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 19 Jun 2015 12:44:33 -0300
This avoids the problem that it might go to sleep for an unreasonable
amount of time in unusual conditions like the server clock moving
backwards an unreasonable amount of time.
(Simply moving the server clock forward again doesn't solve the problem
unless you wake up the autovacuum launcher manually, say by sending it
SIGHUP).
Per trouble report from Prakash Itnal in
https://www.postgresql.org/message-id/CAHC5u79-UqbapAABH2t4Rh2eYdyge0Zid-X=Xz-ZWZCBK42S0Q@mail.gmail.com
Analyzed independently by Haribabu Kommi and Tom Lane.
M src/backend/postmaster/autovacuum.c
Check for out of memory when allocating sqlca.
commit : d278ff3b26fb226a6b390e5c8a7dd66cbfc5c37e
author : Michael Meskes <meskes@postgresql.org>
date : Mon, 15 Jun 2015 14:21:03 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Mon, 15 Jun 2015 14:21:03 +0200
Patch by Michael Paquier
Conflicts:
src/interfaces/ecpg/ecpglib/connect.c
M src/interfaces/ecpg/compatlib/informix.c
M src/interfaces/ecpg/ecpglib/connect.c
M src/interfaces/ecpg/ecpglib/data.c
M src/interfaces/ecpg/ecpglib/descriptor.c
M src/interfaces/ecpg/ecpglib/error.c
M src/interfaces/ecpg/ecpglib/execute.c
M src/interfaces/ecpg/ecpglib/misc.c
Fix memory leak in ecpglib's connect function.
commit : abf92840a113207ff78c17514c1d141850300586
author : Michael Meskes <meskes@postgresql.org>
date : Mon, 15 Jun 2015 14:20:09 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Mon, 15 Jun 2015 14:20:09 +0200
Patch by Michael Paquier
M src/interfaces/ecpg/ecpglib/connect.c
Fixed some memory leaks in ECPG.
commit : 235bd4ccb6e8db319451c5c64b0748691f746589
author : Michael Meskes <meskes@postgresql.org>
date : Fri, 12 Jun 2015 14:52:55 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Fri, 12 Jun 2015 14:52:55 +0200
Patch by Michael Paquier
Conflicts:
src/interfaces/ecpg/preproc/variable.c
src/interfaces/ecpg/preproc/pgc.l
src/interfaces/ecpg/preproc/descriptor.c
M src/interfaces/ecpg/preproc/descriptor.c
M src/interfaces/ecpg/preproc/pgc.l
M src/interfaces/ecpg/preproc/variable.c
Fix intoasc() in Informix compat lib. This function used to be a noop.
commit : 4678be6178059e2a15bd21f2e3b8781df5084796
author : Michael Meskes <meskes@postgresql.org>
date : Fri, 12 Jun 2015 14:50:47 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Fri, 12 Jun 2015 14:50:47 +0200
Patch by Michael Paquier
M src/interfaces/ecpg/compatlib/informix.c