Stamp 9.4.5.
commit : d25c7d70ff46d1b2f2400f29d100190efe84d70d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 15:12:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 15:12:06 -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
Docs: explain contrib/pg_stat_statements' handling of GC failure.
commit : e96b697adb138b0bbe34082761b4e4538abcc9e6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 12:44:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 12:44:12 -0400
Failure to perform garbage collection now has a user-visible effect, so
explain that and explain that reducing pgss_max is the way to prevent it.
Per gripe from Andrew Dunstan.
M doc/src/sgml/pgstatstatements.sgml
doc: Update URLs of external projects
commit : ffdf2a20f177b5366e979e07cbfb05fe22edc06f
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
Fix insufficiently-portable regression test case.
commit : 868b79adb460dfb702a83eb502e08abde458cc98
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 12:19:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Oct 2015 12:19:15 -0400
Some of the buildfarm members are evidently miserly enough of stack space
to pass the originally-committed form of this test. Increase the
requirement 10X to hopefully ensure that it fails as-expected everywhere.
Security: CVE-2015-5289
M src/test/regress/expected/json.out
M src/test/regress/expected/json_1.out
M src/test/regress/expected/jsonb.out
M src/test/regress/expected/jsonb_1.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/jsonb.sql
Translation updates
commit : 5d250a80c0f4b67df6bd2ebd517536b6c4875911
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 5 Oct 2015 10:55:01 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 5 Oct 2015 10:55:01 -0400
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: a985921768deca2a137f3bada7b3ea900201f661
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/it.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/es.po
M src/bin/initdb/po/it.po
M src/bin/initdb/po/ru.po
M src/bin/pg_basebackup/po/es.po
M src/bin/pg_basebackup/po/it.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_config/po/es.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/de.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/de.po
M src/bin/psql/po/es.po
M src/bin/psql/po/it.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/pt_BR.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/it.po
M src/bin/scripts/po/ru.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/tcl/po/es.po
Last-minute updates for release notes.
commit : 1ecae3a9afa162d07816e746344097dba58fddc0
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
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
Remove outdated comment about relation level autovacuum freeze limits.
commit : 2fc66bfd80b5f69a80845e24c8a3c90cb2842176
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 : bed3f6d0354a7ca2fcd7d088ff271b422dbf9921
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 : a0c02ed5b4ef24d91a6fb22d447fc5cba8aeb146
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/rangetypes.c
M src/backend/utils/adt/rowtypes.c
Prevent stack overflow in json-related functions.
commit : 16d58b5b534fa783e2259b407c237fc166ebf7e4
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
Sufficiently-deep recursion heretofore elicited a SIGSEGV. If an
application constructs PostgreSQL json or jsonb values from arbitrary
user input, application users could have exploited this to terminate all
active database connections. That applies to 9.3, where the json parser
adopted recursive descent, and later versions. Only row_to_json() and
array_to_json() were at risk in 9.2, both in a non-security capacity.
Back-patch to 9.2, where the json type was introduced.
Oskari Saarenmaa, reviewed by Michael Paquier.
Security: CVE-2015-5289
M src/backend/utils/adt/json.c
M src/test/regress/expected/json.out
M src/test/regress/expected/json_1.out
M src/test/regress/expected/jsonb.out
M src/test/regress/expected/jsonb_1.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/jsonb.sql
pgcrypto: Detect and report too-short crypt() salts.
commit : 4d95419e8a2006e91a4356b8bb49c1563933f139
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 : 13ac4c035de96eb66c87bfba7faf4c5890293c36
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 : 439b65e84e2464e1881e56e2f7218553730293dc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 19:38:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 19:38:00 -0400
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
Improve contrib/pg_stat_statements' handling of garbage collection failure.
commit : 93840f96c7c24bd9500f1066af5e1d3101fe0229
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 17:58:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Oct 2015 17:58:30 -0400
If we can't read the query texts file (whether because out-of-memory, or
for some other reason), give up and reset the file to empty, discarding all
stored query texts, though not the statistics per se. We used to leave
things alone and hope for better luck next time, but the problem is that
the file is only going to get bigger and even harder to slurp into memory.
Better to do something that will get us out of trouble.
Likewise reset the file to empty for any other failure within gc_qtexts().
The previous behavior after a write error was to discard query texts but
not do anything to truncate the file, which is just weird.
Also, increase the maximum supported file size from MaxAllocSize to
MaxAllocHugeSize; this makes it more likely we'll be able to do a garbage
collection successfully.
Also, fix recalculation of mean_query_len within entry_dealloc() to match
the calculation in gc_qtexts(). The previous coding overlooked the
possibility of dropped texts (query_len == -1) and would underestimate the
mean of the remaining entries in such cases, thus possibly causing excess
garbage collection cycles.
In passing, add some errdetail to the log entry that complains about
insufficient memory to read the query texts file, which after all was
Jim Nasby's original complaint.
Back-patch to 9.4 where the current handling of query texts was
introduced.
Peter Geoghegan, rather editorialized upon by me
M contrib/pg_stat_statements/pg_stat_statements.c
Further twiddling of nodeHash.c hashtable sizing calculation.
commit : 4075fc4b97f9b4988250ede0288849bf78cab90c
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 : ff4cbc1ff3d23fe9c40110c8953e0d07457b136b
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
Improve errhint() about replication slot naming restrictions.
commit : 99557984bc91446d50a70fc5ecb1306bc3cf56f6
author : Andres Freund <andres@anarazel.de>
date : Sat, 3 Oct 2015 15:29:08 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sat, 3 Oct 2015 15:29:08 +0200
The existing hint talked about "may only contain letters", but the
actual requirement is more strict: only lower case letters are allowed.
Reported-By: Rushabh Lathia
Author: Rushabh Lathia
Discussion: AGPqQf2x50qcwbYOBKzb4x75sO_V3g81ZsA8+Ji9iN5t_khFhQ@mail.gmail.com
Backpatch: 9.4-, where replication slots were added
M contrib/test_decoding/expected/ddl.out
M src/backend/replication/slot.c
Update time zone data files to tzdata release 2015g.
commit : 8e45497a231e4e83ba2c9ca7cb3561a7d9e65f22
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 : bb1d979612706655bd8be1ea54beadeee5bade85
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 : c5e38b93c62fa360bb054c41a864ab45d9eccea0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 14:51:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 2 Oct 2015 14:51:58 -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 : c0215b2cf651f06d3040daaf2c0b9836950413e3
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
M src/test/regress/expected/regex.out
M src/test/regress/sql/regex.sql
Add some more query-cancel checks to regular expression matching.
commit : 109def0325a65fe83015ea5bdf56bda5efb014bf
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 : 2171661bd923ada937095b62cb71a9bfec8fa7bb
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 pg_dump to handle inherited NOT VALID check constraints correctly.
commit : 35435af38884df683c6d0d6dcfb20a8c6b65fac1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Oct 2015 16:19:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Oct 2015 16:19:49 -0400
This case seems to have been overlooked when unvalidated check constraints
were introduced, in 9.2. The code would attempt to dump such constraints
over again for each child table, even though adding them to the parent
table is sufficient.
In 9.2 and 9.3, also fix contrib/pg_upgrade/Makefile so that the "make
clean" target fully cleans up after a failed test. This evidently got
dealt with at some point in 9.4, but it wasn't back-patched. I ran into
it while testing this fix ...
Per bug #13656 from Ingmar Brouns.
M src/bin/pg_dump/pg_dump.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Fix documentation error in commit 8703059c6b55c427100e00a09f66534b6ccbfaa1.
commit : 1128b7735dd23dc9dedf034f7e8236d84f22fd51
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
Fix mention of htup.h in storage.sgml
commit : 5091f39afe7fef1cccaf501d3c5dd1ec847c7f97
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 1 Oct 2015 23:00:52 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 1 Oct 2015 23:00:52 +0900
Previously it was documented that the details on HeapTupleHeaderData
struct could be found in htup.h. This is not correct because it's now
defined in htup_details.h.
Back-patch to 9.3 where the definition of HeapTupleHeaderData struct
was moved from htup.h to htup_details.h.
Michael Paquier
M doc/src/sgml/storage.sgml
Improve LISTEN startup time when there are many unread notifications.
commit : 03f9b63e24ea6a40afbf518a281e9fca134e999c
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 plperl to handle non-ASCII error message texts correctly.
commit : b62c870ff1774c98865a930f2f0a09544e11d2e5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Sep 2015 10:52:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Sep 2015 10:52:22 -0400
We were passing error message texts to croak() verbatim, which turns out
not to work if the text contains non-ASCII characters; Perl mangles their
encoding, as reported in bug #13638 from Michal Leinweber. To fix, convert
the text into a UTF8-encoded SV first.
It's hard to test this without risking failures in different database
encodings; but we can follow the lead of plpython, which is already
assuming that no-break space (U+00A0) has an equivalent in all encodings
we care about running the regression tests in (cf commit 2dfa15de5).
Back-patch to 9.1. The code is quite different in 9.0, and anyway it seems
too risky to put something like this into 9.0's final minor release.
Alex Hunsaker, with suggestions from Tim Bunce and Tom Lane
M src/pl/plperl/SPI.xs
M src/pl/plperl/Util.xs
M src/pl/plperl/expected/plperl_elog.out
M src/pl/plperl/expected/plperl_elog_1.out
M src/pl/plperl/plperl.c
M src/pl/plperl/plperl_helpers.h
M src/pl/plperl/sql/plperl_elog.sql
Fix compiler warning about unused function in non-readline case.
commit : 84008295068c798b4a8623ed9d7873d277ade25c
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
Second try at fixing O(N^2) problem in foreign key references.
commit : 67d0f7a379481a4171c65e4001071f8838d16a67
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Sep 2015 13:16:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Sep 2015 13:16:30 -0400
This replaces ill-fated commit 5ddc72887a012f6a8b85707ef27d85c274faf53d,
which was reverted because it broke active uses of FK cache entries. In
this patch, we still do nothing more to invalidatable cache entries than
mark them as needing revalidation, so we won't break active uses. To keep
down the overhead of InvalidateConstraintCacheCallBack(), keep a list of
just the currently-valid cache entries. (The entries are large enough that
some added space for list links doesn't seem like a big problem.) This
would still be O(N^2) when there are many valid entries, though, so when
the list gets too long, just force the "sinval reset" behavior to remove
everything from the list. I set the threshold at 1000 entries, somewhat
arbitrarily. Possibly that could be fine-tuned later. Another item for
future study is whether it's worth adding reference counting so that we
could safely remove invalidated entries. As-is, problem cases are likely
to end up with large and mostly invalid FK caches.
Like the previous attempt, backpatch to 9.3.
Jan Wieck and Tom Lane
M src/backend/utils/adt/ri_triggers.c
Further fix for psql's code for locale-aware formatting of numeric output.
commit : c961f401b267facca469c83963eddef9227bf244
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Sep 2015 12:20:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Sep 2015 12:20:45 -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 : 49917edadf9d787efbd71b7e1e689eb48c2a1c47
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 : 348dd2847fa4a379e452ee00ab2016ec1629202d
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
Improve handling of collations in contrib/postgres_fdw.
commit : 0da864c53c6c4a84ed1cfa2cef2945df23196451
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Sep 2015 12:47:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 24 Sep 2015 12:47:30 -0400
If we have a local Var of say varchar type with default collation, and
we apply a RelabelType to convert that to text with default collation, we
don't want to consider that as creating an FDW_COLLATE_UNSAFE situation.
It should be okay to compare that to a remote Var, so long as the remote
Var determines the comparison collation. (When we actually ship such an
expression to the remote side, the local Var would become a Param with
default collation, meaning the remote Var would in fact control the
comparison collation, because non-default implicit collation overrides
default implicit collation in parse_collate.c.) To fix, be more precise
about what FDW_COLLATE_NONE means: it applies either to a noncollatable
data type or to a collatable type with default collation, if that collation
can't be traced to a remote Var. (When it can, FDW_COLLATE_SAFE is
appropriate.) We were essentially using that interpretation already at
the Var/Const/Param level, but we weren't bubbling it up properly.
An alternative fix would be to introduce a separate FDW_COLLATE_DEFAULT
value to describe the second situation, but that would add more code
without changing the actual behavior, so it didn't seem worthwhile.
Also, since we're clarifying the rule to be that we care about whether
operator/function input collations match, there seems no need to fail
immediately upon seeing a Const/Param/non-foreign-Var with nondefault
collation. We only have to reject if it appears in a collation-sensitive
context (for example, "var IS NOT NULL" is perfectly safe from a collation
standpoint, whatever collation the var has). So just set the state to
UNSAFE rather than failing immediately.
Per report from Jeevan Chalke. This essentially corrects some sloppy
thinking in commit ed3ddf918b59545583a4b374566bc1148e75f593, so back-patch
to 9.3 where that logic appeared.
M contrib/postgres_fdw/deparse.c
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
Lower *_freeze_max_age minimum values.
commit : 4ff753c91bbfb05d56a9ce7517d4bafe3c87b7ce
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: back to 9.0 (in parts)
M src/backend/utils/misc/guc.c
Docs: fix typo in to_char() example.
commit : d546ce7281c57b2bff3fc8702b88035dbcb0826c
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
test_decoding: Protect against rare spurious test failures.
commit : a3e58e79a97f26ae20a0520ba98b82478a9d66ef
author : Andres Freund <andres@anarazel.de>
date : Tue, 22 Sep 2015 15:33:30 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 22 Sep 2015 15:33:30 +0200
A bunch of tests missed specifying that empty transactions shouldn't be
displayed. That causes problems when e.g. autovacuum runs in an
unfortunate moment. The tests in question only run for a very short
time, making this quite unlikely.
Reported-By: Buildfarm member axolotl
Backpatch: 9.4, where logical decoding was introduced
M contrib/test_decoding/expected/binary.out
M contrib/test_decoding/sql/binary.sql
Fix whitespace
commit : 32b68ed1ba8202249e283689ccbbd8a040e67942
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 21 Sep 2015 13:39:34 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 21 Sep 2015 13:39:34 -0400
M src/interfaces/ecpg/ecpglib/execute.c
Fix possible internal overflow in numeric multiplication.
commit : fa9fc3a1b8069c0ab5edcd6f8b0caf679fed9392
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 : 7496aba8085a21f8296f19b2e8f07e9723f946a5
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 : e32c5f118ec2da80fd76da1241dd721ceb3e9127
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 : f38070d630149a98984a7145093e08706ad99828
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 : f7d896ab919af6ef74117c6121443721902beba3
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/regcomp.c
M src/backend/regex/regexec.c
M src/include/regex/regguts.h
Honour TEMP_CONFIG when testing pg_upgrade
commit : 5ed2d2cba8823670392400bc6663ff2dbd260292
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 17 Sep 2015 11:57:00 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 17 Sep 2015 11:57:00 -0400
This setting contains extra configuration for the temp instance, as used
in pg_regress' --temp-config flag.
Backpatch to 9.2 where test.sh was introduced.
M contrib/pg_upgrade/test.sh
Fix documentation of regular expression character-entry escapes.
commit : e2e46a9d1c22aa8a6ef7fd498a063fc7d4d300ef
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
Revert "Fix an O(N^2) problem in foreign key references".
commit : 541ec18acf2f6c8df095e45af980f59b82475d1e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Sep 2015 11:08:56 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Sep 2015 11:08:56 -0400
Commit 5ddc72887a012f6a8b85707ef27d85c274faf53d does not actually work
because it will happily blow away ri_constraint_cache entries that are
in active use in outer call levels. In any case, it's a very ugly,
brute-force solution to the problem of limiting the cache size.
Revert until it can be redesigned.
M src/backend/utils/adt/ri_triggers.c
pg_dump, pg_upgrade: allow postgres/template1 tablespace moves
commit : 35d2fc1f299a977483a1ac6d08bfbda104ad2b25
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 11 Sep 2015 15:51:11 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 11 Sep 2015 15:51:11 -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
Fix an O(N^2) problem in foreign key references.
commit : 7d0712890d1e18379394cec33b01edb7102928de
author : Kevin Grittner <kgrittn@postgresql.org>
date : Fri, 11 Sep 2015 13:20:30 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Fri, 11 Sep 2015 13:20:30 -0500
Commit 45ba424f improved foreign key lookups during bulk updates
when the FK value does not change. When restoring a schema dump
from a database with many (say 100,000) foreign keys, this cache
would grow very big and every ALTER TABLE command was causing an
InvalidateConstraintCacheCallBack(), which uses a sequential hash
table scan. This could cause a severe performance regression in
restoring a schema dump (including during pg_upgrade).
The patch uses a heuristic method of detecting when the hash table
should be destroyed and recreated.
InvalidateConstraintCacheCallBack() adds the current size of the
hash table to a counter. When that sum reaches 1,000,000, the hash
table is flushed. This fixes the regression without noticeable
harm to the bulk update use case.
Jan Wieck
Backpatch to 9.3 where the performance regression was introduced.
M src/backend/utils/adt/ri_triggers.c
Correct description of PageHeaderData layout in documentation
commit : 907f3a94f1aa7122f87568455277934e03bb9d92
author : Fujii Masao <fujii@postgresql.org>
date : Fri, 11 Sep 2015 13:02:15 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Fri, 11 Sep 2015 13:02:15 +0900
Back-patch to 9.3 where PageHeaderData layout was changed.
Michael Paquier
M doc/src/sgml/storage.sgml
Fix setrefs.c comment properly.
commit : 59d310b6e6cc9be5eda543d914133b4f696e3800
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Sep 2015 10:25:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Sep 2015 10:25:58 -0400
The "typo" alleged in commit 1e460d4bd was actually a comment that was
correct when written, but I missed updating it in commit b5282aa89.
Use a slightly less specific (and hopefully more future-proof) description
of what is collected. Back-patch to 9.2 where that commit appeared, and
revert the comment to its then-entirely-correct state before that.
M src/backend/optimizer/plan/setrefs.c
Fix typo in setrefs.c
commit : 21a7c077b8278b64e54bfb7b24504a764d0c0167
author : Stephen Frost <sfrost@snowman.net>
date : Thu, 10 Sep 2015 09:22:19 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Thu, 10 Sep 2015 09:22:19 -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
Revert ed47666 and part of ef57b98
commit : 7786fe004c6b07fa5becdb65870e1f0d8f0ca92f
author : Stephen Frost <sfrost@snowman.net>
date : Thu, 10 Sep 2015 08:58:35 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Thu, 10 Sep 2015 08:58:35 -0400
This reverts ed47666, which ended up adding a second tempoary
installation for all 'make check' runs, and reverts the part of
ef57b98 that changed the TAP 'prove_check' section, which appears to
have been unintentional to begin with on this branch.
Analysis and patch by Noah.
M src/Makefile.global.in
Fix minor bug in regexp makesearch() function.
commit : 48c6a1ab9713d57984a2eec401a9648ddbe29ae4
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
Remove files signaling a standby promotion request at postmaster startup
commit : 2244c0652d2c20cd2557fb1940458b5f21cd48e0
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 9 Sep 2015 22:51:44 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 9 Sep 2015 22:51:44 +0900
This commit makes postmaster forcibly remove the files signaling
a standby promotion request. Otherwise, the existence of those files
can trigger a promotion too early, whether a user wants that or not.
This removal of files is usually unnecessary because they can exist
only during a few moments during a standby promotion. However
there is a race condition: if pg_ctl promote is executed and creates
the files during a promotion, the files can stay around even after
the server is brought up to new master. Then, if new standby starts
by using the backup taken from that master, the files can exist
at the server startup and should be removed in order to avoid
an unexpected promotion.
Back-patch to 9.1 where promote signal file was introduced.
Problem reported by Feike Steenbergen.
Original patch by Michael Paquier, modified by me.
Discussion: 20150528100705.4686.91426@wrigleys.postgresql.org
M src/backend/access/transam/xlog.c
M src/backend/postmaster/postmaster.c
M src/include/access/xlog.h
Add temp-check, with_temp_install definition - 9.4
commit : ed476669e998b788770f07338aefd2594ff4cce9
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 8 Sep 2015 17:38:30 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 8 Sep 2015 17:38:30 -0400
Commit fa4a4df93c8c28d5684cacb1677fbd13f58bb9f2 attempted to backpatch
to 9.4 a change to improve the logging of TAP tests. Unfortunately, due
to how 9.4 and 9.5 had diverged, the backpatch to 9.4 depended on a few
things which didn't exist in 9.4 (but did in 9.5), specifically, the
'temp-check' production and the 'with_temp_install' definition (which
also required 'abs_top_builddir').
Add these definitions into REL9_4_STABLE to allow the TAP tests to run
correctly under 'make check'.
M src/Makefile.global.in
Lock all relations referred to in updatable views
commit : 83d004904d82759118635dc1a6a7503d4da785e9
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 8 Sep 2015 17:02:56 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 8 Sep 2015 17:02:56 -0400
Even views considered "simple" enough to be automatically updatable may
have mulitple relations involved (eg: in a where clause). We need to
make sure and lock those relations when rewriting the query.
Back-patch to 9.3 where updatable views were added.
Pointed out by Andres, patch thanks to Dean Rasheed.
M src/backend/rewrite/rewriteHandler.c
Add gin_fuzzy_search_limit to postgresql.conf.sample.
commit : b74af40bb2945d44842434a2480d8b3f053bcf58
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 : ac711dd27f71aada76af2d2e2de0e3f32e3191c6
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 : 8582cf1eb49d9b857f2397aa924e76ed5484cf43
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 : 0198a8d82a16ccffefbc692278eccba85f41c381
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 : b6e367373bfada76d0cefae04ce4cb01c2b537dd
author : Teodor Sigaev <teodor@sigaev.ru>
date : Mon, 7 Sep 2015 17:17:42 +0300
committer: Teodor Sigaev <teodor@sigaev.ru>
date : Mon, 7 Sep 2015 17:17:42 +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 : 1e0309465bfdf67dcb8ed0597c3aa1257582f14e
author : Teodor Sigaev <teodor@sigaev.ru>
date : Mon, 7 Sep 2015 15:21:44 +0300
committer: Teodor Sigaev <teodor@sigaev.ru>
date : Mon, 7 Sep 2015 15:21:44 +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 : b17ce6208363470d753503f9430d21ecc898cc79
author : Greg Stark <stark@mit.edu>
date : Sun, 6 Sep 2015 02:04:37 +0100
committer: Greg Stark <stark@mit.edu>
date : Sun, 6 Sep 2015 02:04:37 +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 CreateTableSpace() so it will compile without HAVE_SYMLINK.
commit : 74fc81ed244b10a6adaade722f2d6cdfaf7c09a8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Sep 2015 16:15:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Sep 2015 16:15:38 -0400
This has been broken since 9.3 (commit 82b1b213cad3a69c to be exact),
which suggests that nobody is any longer using a Windows build system that
doesn't provide a symlink emulation. Still, it's wrong on its own terms,
so repair.
YUriy Zhuravlev
M src/backend/commands/tablespace.c
Fix misc typos.
commit : 29602295bacf6e1e59abd6b82734f51d9c107ba8
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 contrib/cube/cube.c
M doc/src/sgml/sources.sgml
M src/backend/access/common/heaptuple.c
M src/backend/access/gin/ginfast.c
M src/backend/access/gist/gistproc.c
M src/backend/access/heap/heapam.c
M src/backend/access/heap/rewriteheap.c
M src/backend/optimizer/path/costsize.c
M src/backend/utils/adt/regproc.c
Fix subtransaction cleanup after an outer-subtransaction portal fails.
commit : 37d10c524c73cebc88ec9c69adc44917a3d67dcd
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
Document that max_worker_processes must be high enough in standby.
commit : 7f7fd9b345f5a13062a066e89763d882aa24c9cb
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 3 Sep 2015 22:30:16 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 3 Sep 2015 22:30:16 +0900
The setting values of some parameters including max_worker_processes
must be equal to or higher than the values on the master. However,
previously max_worker_processes was not listed as such parameter
in the document. So this commit adds it to that list.
Back-patch to 9.4 where max_worker_processes was added.
M doc/src/sgml/high-availability.sgml
M src/backend/access/transam/xlog.c
psql: print longtable as a possible \pset option
commit : ce6e50aebe5d0874d64767b8963b162fdc186fa7
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 31 Aug 2015 12:24:16 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 31 Aug 2015 12:24:16 -0400
For some reason this message was not updated when the longtable option
was added.
Backpatch through 9.3
M src/bin/psql/command.c
Fix sepgsql regression tests.
commit : 12da677179c3febd8d3c829fffa5cd2f922f6286
author : Joe Conway <mail@joeconway.com>
date : Sun, 30 Aug 2015 11:09:31 -0700
committer: Joe Conway <mail@joeconway.com>
date : Sun, 30 Aug 2015 11:09:31 -0700
The regression tests for sepgsql were broken by changes in the
base distro as-shipped policies. Specifically, definition of
unconfined_t in the system default policy was changed to bypass
multi-category rules, which the regression test depended on.
Fix that by defining a custom privileged domain
(sepgsql_regtest_superuser_t) and using it instead of system's
unconfined_t domain. The new sepgsql_regtest_superuser_t domain
performs almost like the current unconfined_t, but restricted by
multi-category policy as the traditional unconfined_t was.
The custom policy module is a self defined domain, and so should not
be affected by related future system policy changes. However, it still
uses the unconfined_u:unconfined_r pair for selinux-user and role.
Those definitions have not been changed for several years and seem
less risky to rely on than the unconfined_t domain. Additionally, if
we define custom user/role, they would need to be manually defined
at the operating system level, adding more complexity to an already
non-standard and complex regression test.
Back-patch to 9.3. The regression tests will need more work before
working correctly on 9.2. Starting with 9.2, sepgsql has had dependencies
on libselinux versions that are only available on newer distros with
the changed set of policies (e.g. RHEL 7.x). On 9.1 sepgsql works
fine with the older distros with original policy set (e.g. RHEL 6.x),
and on which the existing regression tests work fine. We might want
eventually change 9.1 sepgsql regression tests to be more independent
from the underlying OS policies, however more work will be needed to
make that happen and it is not clear that it is worth the effort.
Kohei KaiGai with review by Adam Brightwell and me, commentary by
Stephen, Alvaro, Tom, Robert, and others.
M contrib/sepgsql/expected/alter.out
M contrib/sepgsql/expected/ddl.out
M contrib/sepgsql/expected/dml.out
M contrib/sepgsql/expected/label.out
M contrib/sepgsql/expected/misc.out
M contrib/sepgsql/launcher
M contrib/sepgsql/sepgsql-regtest.te
M contrib/sepgsql/sql/alter.sql
M contrib/sepgsql/sql/ddl.sql
M contrib/sepgsql/sql/dml.sql
M contrib/sepgsql/sql/label.sql
Use "mb" not the nonexistent "rmb" for pg_read_barrier() on Alpha.
commit : 747ca66977d5539a5ab9e5f33d3ca074fc3fd19b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Aug 2015 16:34:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Aug 2015 16:34:30 -0400
It's only necessary to fix this in 9.4; later versions don't have this
code (because we ripped out Alpha support entirely), while earlier ones
aren't actually using pg_read_barrier() anywhere.
Per rather belated report from Christoph Berg.
M src/include/storage/barrier.h
Fix s_lock.h PPC assembly code to be compatible with native AIX assembler.
commit : 3da9c060fc775f17e43ae8608b818079a0099516
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 : bef458460fc4cf33939c55dc115f5c7e450370e7
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 : fc3649fd4c4b1571103f141bd804406e95e449b5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Aug 2015 19:11:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Aug 2015 19:11:17 -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 : fe939d950e362094c14e97f4e91c063374588534
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 plpython crash when returning string representation of a RECORD result.
commit : 22b9ce79879bdf0aa8ff56ca4973f894ed69813c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Aug 2015 12:21:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Aug 2015 12:21:37 -0400
PLyString_ToComposite() blithely overwrote proc->result.out.d, even though
for a composite result type the other union variant proc->result.out.r is
the one that should be valid. This could result in a crash if out.r had
in fact been filled in (proc->result.is_rowtype == 1) and then somebody
later attempted to use that data; as per bug #13579 from Paweł Michalak.
Just to add insult to injury, it didn't work for RECORD results anyway,
because record_in() would refuse the case.
Fix by doing the I/O function lookup in a local PLyTypeInfo variable,
as we were doing already in PLyObject_ToComposite(). This is not a great
technique because any fn_extra data allocated by the input function will
be leaked permanently (thanks to using TopMemoryContext as fn_mcxt).
But that's a pre-existing issue that is much less serious than a crash,
so leave it to be fixed separately.
This bug would be a potential security issue, except that plpython is
only available to superusers and the crash requires coding the function
in a way that didn't work before today's patches.
Add regression test cases covering all the supported methods of converting
composite results.
Back-patch to 9.1 where the faulty coding was introduced.
M src/pl/plpython/expected/plpython_composite.out
M src/pl/plpython/plpy_typeio.c
M src/pl/plpython/sql/plpython_composite.sql
Allow record_in() and record_recv() to work for transient record types.
commit : f7ed465e0f32aa4569aa861db74af20827c198f6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Aug 2015 11:19:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Aug 2015 11:19:33 -0400
If we have the typmod that identifies a registered record type, there's no
reason that record_in() should refuse to perform input conversion for it.
Now, in direct SQL usage, record_in() will always be passed typmod = -1
with type OID RECORDOID, because no typmodin exists for type RECORD, so the
case can't arise. However, some InputFunctionCall users such as PLs may be
able to supply the right typmod, so we should allow this to support them.
Note: the previous coding and comment here predate commit 59c016aa9f490b53.
There has been no case since 8.1 in which the passed type OID wouldn't be
valid; and if it weren't, this error message wouldn't be apropos anyway.
Better to let lookup_rowtype_tupdesc complain about it.
Back-patch to 9.1, as this is necessary for my upcoming plpython fix.
I'm committing it separately just to make it a bit more visible in the
commit history.
M src/backend/utils/adt/rowtypes.c
Fix a few bogus statement type names in plpgsql error messages.
commit : 928d0226e5420e5883bfc693cf8c6dce60aad368
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
Add docs about postgres_fdw's setting of search_path and other GUCs.
commit : d509560d1fbfeac79abb6593cc9c0df2be2792b6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Aug 2015 14:31:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Aug 2015 14:31:04 -0400
This behavior wasn't documented, but it should be because it's user-visible
in triggers and other functions executed on the remote server.
Per question from Adam Fuchs.
Back-patch to 9.3 where postgres_fdw was added.
M doc/src/sgml/postgres-fdw.sgml
Improve documentation about MVCC-unsafe utility commands.
commit : ff2ee45f2f3d528e1c95828a14ca8cbdfb9778d2
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
Don't use 'bool' as a struct member name in help_config.c.
commit : c9b727310b4488a15795464a5fb1f3153738076a
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
Use the correct type for TableInfo->relreplident.
commit : 2360f01efa9041d75cab9a9e7640327979864b2c
author : Andres Freund <andres@anarazel.de>
date : Wed, 12 Aug 2015 15:52:10 +0200
committer: Andres Freund <andres@anarazel.de>
date : Wed, 12 Aug 2015 15:52:10 +0200
Mistakenly relreplident was stored as a bool. That works today as c.h
typedefs bool to a char, but isn't very future proof.
Discussion: 20150812084351.GD8470@awork2.anarazel.de
Backpatch: 9.4 where replica identity was introduced.
M src/bin/pg_dump/pg_dump.h
Encoding PG_UHC is code page 949.
commit : a0104e08079dc5e7b903c7d6906cc6b64c4ad041
author : Noah Misch <noah@leadboat.com>
date : Fri, 14 Aug 2015 20:23:13 -0400
committer: Noah Misch <noah@leadboat.com>
date : Fri, 14 Aug 2015 20:23:13 -0400
This fixes presentation of non-ASCII messages to the Windows event log
and console in rare cases involving Korean locale. Processes like the
postmaster and checkpointer, but not processes attached to databases,
were affected. Back-patch to 9.4, where MessageEncoding was introduced.
The problem exists in all supported versions, but this change has no
effect in the absence of the code recognizing PG_UHC MessageEncoding.
Noticed while investigating bug #13427 from Dmitri Bourlatchkov.
M src/backend/utils/mb/encnames.c
Restore old pgwin32_message_to_UTF16() behavior outside transactions.
commit : f988da953945136c8e511550226884dcbebe5b6b
author : Noah Misch <noah@leadboat.com>
date : Fri, 14 Aug 2015 20:23:09 -0400
committer: Noah Misch <noah@leadboat.com>
date : Fri, 14 Aug 2015 20:23:09 -0400
Commit 49c817eab78c6f0ce8c3bf46766b73d6cf3190b7 replaced with a hard
error the dubious pg_do_encoding_conversion() behavior when outside a
transaction. Reintroduce the historic soft failure locally within
pgwin32_message_to_UTF16(). This fixes errors when writing messages in
less-common encodings to the Windows event log or console. Back-patch
to 9.4, where the aforementioned commit first appeared.
Per bug #13427 from Dmitri Bourlatchkov.
M src/backend/utils/mb/mbutils.c
Improve regression test case to avoid depending on system catalog stats.
commit : 3bfd40180859e252090f072805ec24b16c360f2f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Aug 2015 13:25:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Aug 2015 13:25:01 -0400
In commit 95f4e59c32866716 I added a regression test case that examined
the plan of a query on system catalogs. That isn't a terribly great idea
because the catalogs tend to change from version to version, or even
within a version if someone makes an unrelated regression-test change that
populates the catalogs a bit differently. Usually I try to make planner
test cases rely on test tables that have not changed since Berkeley days,
but I got sloppy in this case because the submitted crasher example queried
the catalogs and I didn't spend enough time on rewriting it. But it was a
problem waiting to happen, as I was rudely reminded when I tried to port
that patch into Salesforce's Postgres variant :-(. So spend a little more
effort and rewrite the query to not use any system catalogs. I verified
that this version still provokes the Assert if 95f4e59c32866716's code fix
is reverted.
I also removed the EXPLAIN output from the test, as it turns out that the
assertion occurs while considering a plan that isn't the one ultimately
selected anyway; so there's no value in risking any cross-platform
variation in that printout.
Back-patch to 9.2, like the previous patch.
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix declaration of isarray variable.
commit : 83fd92290a4144db0963614e21c60a74d49abeb9
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 : 8cd3a7adabcd1837a1aca80f11257ef11589630f
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 : 157d40640cdd885b72f27db358ba66d12feaec7d
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 : a35a527f2d6b28f78e9eab42801ec0170ffcb898
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
Minor cleanups in slot related code.
commit : e9a080d3692893081306fee262565ba87080dfd0
author : Andres Freund <andres@anarazel.de>
date : Tue, 11 Aug 2015 12:32:49 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 11 Aug 2015 12:32:49 +0200
Fix a bunch of typos, and remove two superflous includes.
Author: Gurjeet Singh
Discussion: CABwTF4Wh_dBCzTU=49pFXR6coR4NW1ynb+vBqT+Po=7fuq5iCw@mail.gmail.com
Backpatch: 9.4
M src/backend/replication/logical/logical.c
M src/backend/replication/slot.c
Fix privilege dumping from servers too old to have that type of privilege.
commit : 3352c23a611bdf2e1bcbd697f1265f0042b08136
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 : 7e0add386184ef7aa599e5b3a96f16a57fa53566
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 mucking with PlaceHolderVar-related restrictions on join order.
commit : 7371ab74feb7a6bcb8cab0ae4e1f7753460b703d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Aug 2015 17:18:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Aug 2015 17:18:17 -0400
Commit 85e5e222b1dd02f135a8c3bf387d0d6d88e669bd turns out not to have taken
care of all cases of the partially-evaluatable-PlaceHolderVar problem found
by Andreas Seltenreich's fuzz testing. I had set it up to check for risky
PHVs only in the event that we were making a star-schema-based exception to
the param_source_rels join ordering heuristic. However, it turns out that
the problem can occur even in joins that satisfy the param_source_rels
heuristic, in which case allow_star_schema_join() isn't consulted.
Refactor so that we check for risky PHVs whenever the proposed join has
any remaining parameterization.
Back-patch to 9.2, like the previous patch (except for the regression test
case, which only works back to 9.3 because it uses LATERAL).
Note that this discovery implies that problems of this sort could've
occurred in 9.2 and up even before the star-schema patch; though I've not
tried to prove that experimentally.
M src/backend/optimizer/path/joinpath.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix copy & paste mistake in pg_get_replication_slots().
commit : d4ad167d9577cca8c75fee329e2765d930e0c29f
author : Andres Freund <andres@anarazel.de>
date : Mon, 10 Aug 2015 13:28:19 +0200
committer: Andres Freund <andres@anarazel.de>
date : Mon, 10 Aug 2015 13:28:19 +0200
XLogRecPtr was compared with InvalidTransactionId instead of
InvalidXLogRecPtr. As both are defined to the same value this doesn't
cause any actual problems, but it's still wrong.
Backpatch: 9.4-master, bug was introduced in 9.4
M src/backend/replication/slotfuncs.c
Fix typo in LDAP example
commit : 68b5c08c3978a1ff76b4bc354bf892c7eb8df5c8
author : Magnus Hagander <magnus@hagander.net>
date : Sun, 9 Aug 2015 14:49:47 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Sun, 9 Aug 2015 14:49:47 +0200
Reported by William Meitzen
M doc/src/sgml/client-auth.sgml
Further adjustments to PlaceHolderVar removal.
commit : 30b4ccdab70aad4178cf6876f25c5bba27035558
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 7 Aug 2015 14:13:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 7 Aug 2015 14:13:39 -0400
A new test case from Andreas Seltenreich showed that we were still a bit
confused about removing PlaceHolderVars during join removal. Specifically,
remove_rel_from_query would remove a PHV that was used only underneath
the removable join, even if the place where it's used was the join partner
relation and not the join clause being deleted. This would lead to a
"too late to create a new PlaceHolderInfo" error later on. We can defend
against that by checking ph_eval_at to see if the PHV could possibly be
getting used at some partner rel.
Also improve some nearby LATERAL-related logic. I decided that the check
on ph_lateral needed to take precedence over the check on ph_needed, in
case there's a lateral reference underneath the join being considered.
(That may be impossible, but I'm not convinced of it, and it's easy enough
to defend against the case.) Also, I realized that remove_rel_from_query's
logic for updating LateralJoinInfos is dead code, because we don't build
those at all until after join removal.
Back-patch to 9.3. Previous versions didn't have the LATERAL issues, of
course, and they also didn't attempt to remove PlaceHolderInfos during join
removal. (I'm starting to wonder if changing that was really such a great
idea.)
M src/backend/optimizer/plan/analyzejoins.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix attach-related race condition in shm_mq_send_bytes.
commit : e9215461d2a6081812d9c3619c9ec81e5682fe0f
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 7 Aug 2015 09:04:07 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 7 Aug 2015 09:04:07 -0500
Spotted by Antonin Houska.
M src/backend/storage/ipc/shm_mq.c
Fix old oversight in join removal logic.
commit : 8c7bb02409548a88fa02d6f8771e2a6ca27007d3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Aug 2015 22:14:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Aug 2015 22:14:07 -0400
Commit 9e7e29c75ad441450f9b8287bd51c13521641e3b introduced an Assert that
join removal didn't reduce the eval_at set of any PlaceHolderVar to empty.
At first glance it looks like join_is_removable ensures that's true --- but
actually, the loop in join_is_removable skips PlaceHolderVars that are not
referenced above the join due to be removed. So, if we don't want any
empty eval_at sets, the right thing to do is to delete any now-unreferenced
PlaceHolderVars from the data structure entirely.
Per fuzz testing by Andreas Seltenreich. Back-patch to 9.3 where the
aforesaid Assert was added.
M src/backend/optimizer/plan/analyzejoins.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix eclass_useful_for_merging to give valid results for appendrel children.
commit : d31e79415bc0cbae8b20192ab8a979c9ebbe5dac
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Aug 2015 20:14:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Aug 2015 20:14:37 -0400
Formerly, this function would always return "true" for an appendrel child
relation, because it would think that the appendrel parent was a potential
join target for the child. In principle that should only lead to some
inefficiency in planning, but fuzz testing by Andreas Seltenreich disclosed
that it could lead to "could not find pathkey item to sort" planner errors
in odd corner cases. Specifically, we would think that all columns of a
child table's multicolumn index were interesting pathkeys, causing us to
generate a MergeAppend path that sorts by all the columns. However, if any
of those columns weren't actually used above the level of the appendrel,
they would not get added to that rel's targetlist, which would result in
being unable to resolve the MergeAppend's sort keys against its targetlist
during createplan.c.
Backpatch to 9.3. In older versions, columns of an appendrel get added
to its targetlist even if they're not mentioned above the scan level,
so that the failure doesn't occur. It might be worth back-patching this
fix to older versions anyway, but I'll refrain for the moment.
M src/backend/optimizer/path/equivclass.c
M src/backend/optimizer/path/pathkeys.c
M src/include/optimizer/paths.h
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql
Further fixes for degenerate outer join clauses.
commit : 7ef507ad77343f87acb324e32212c44eabd0db7b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Aug 2015 15:35:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Aug 2015 15:35:27 -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
Fix incorrect calculation in shm_mq_receive.
commit : e72f2115ef6d574c64f42ea8b4cbe96accee08b2
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 6 Aug 2015 13:25:45 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 6 Aug 2015 13:25:45 -0400
If some, but not all, of the length word has already been read, and the
next attempt to read sees exactly the number of bytes needed to complete
the length word, or fewer, then we'll incorrectly read less than all of
the available data.
Antonin Houska
M src/backend/storage/ipc/shm_mq.c
Fix `make installcheck` for serializable transactions.
commit : 543e2057fb0e89d64d7250f1afa57ac8305b85a4
author : Kevin Grittner <kgrittn@postgresql.org>
date : Thu, 6 Aug 2015 10:35:19 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Thu, 6 Aug 2015 10:35:19 -0500
Commit e5550d5fec66aa74caad1f79b79826ec64898688 added some new
tests for ALTER TABLE which involved table scans. When
default_transaction_isolation = 'serializable' these acquire
relation-level SIReadLocks. The test results didn't cope with
that. Add SIReadLock as the minimum lock level for purposes of
these tests.
This could also be fixed by excluding this type of lock from the
my_locks view, but it would be a bug for SIReadLock to show up for
a relation which was not otherwise locked, so do it this way to
allow that sort of condition to cause a regression test failure.
There is some question whether we could avoid taking SIReadLocks
during these operations, but confirming the safety of that and
figuring out how to avoid the locks is not trivial, and would be
a separate patch.
Backpatch to 9.4 where the new tests were added.
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Make real sure we don't reassociate joins into or out of SEMI/ANTI joins.
commit : 4d94b5f1f003404f86b2659eff9814466d03640e
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 : aa9f8cb131a91df16db69fd271f81e761db29625
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 : fa6e785fd34eb35ae82ebd447fdbc9970ce5bf3b
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 : 118c9bb8d14ebfcbb4a0a4af6f029d8d8fe46ad6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 18:18:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 18:18:46 -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
Fix a PlaceHolderVar-related oversight in star-schema planning patch.
commit : b58e8caf0cdd5e2657771b32a84464d7ff5ecebc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 14:55:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 4 Aug 2015 14:55:32 -0400
In commit b514a7460d9127ddda6598307272c701cbb133b7, I changed the planner
so that it would allow nestloop paths to remain partially parameterized,
ie the inner relation might need parameters from both the current outer
relation and some upper-level outer relation. That's fine so long as we're
talking about distinct parameters; but the patch also allowed creation of
nestloop paths for cases where the inner relation's parameter was a
PlaceHolderVar whose eval_at set included the current outer relation and
some upper-level one. That does *not* work.
In principle we could allow such a PlaceHolderVar to be evaluated at the
lower join node using values passed down from the upper relation along with
values from the join's own outer relation. However, nodeNestloop.c only
supports simple Vars not arbitrary expressions as nestloop parameters.
createplan.c is also a few bricks shy of being able to handle such cases;
it misplaces the PlaceHolderVar parameters in the plan tree, which is why
the visible symptoms of this bug are "plan should not reference subplan's
variable" and "failed to assign all NestLoopParams to plan nodes" planner
errors.
Adding the necessary complexity to make this work doesn't seem like it
would be repaid in significantly better plans, because in cases where such
a PHV exists, there is probably a corresponding join order constraint that
would allow a good plan to be found without using the star-schema exception.
Furthermore, adding complexity to nodeNestloop.c would create a run-time
penalty even for plans where this whole consideration is irrelevant.
So let's just reject such paths instead.
Per fuzz testing by Andreas Seltenreich; the added regression test is based
on his example query. Back-patch to 9.2, like the previous patch.
M src/backend/optimizer/path/joinpath.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Cap wal_buffers to avoid a server crash when it's set very large.
commit : 3a35ca5add65fb58bda52d62695a5b83cd6c0ae7
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
contrib/isn now needs a .gitignore file.
commit : 4424356c033d4f10f7f0d18f2835f219ee09c8c0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Aug 2015 23:57:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Aug 2015 23:57:32 -0400
Oversight in commit cb3384a0cb4cf900622b77865f60e31259923079.
Back-patch to 9.1, like that commit.
A contrib/isn/.gitignore
Fix output of ISBN-13 numbers beginning with 979.
commit : d7d4bd2c3b89bb06dbdd900221862ea905b67aeb
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 2 Aug 2015 22:12:33 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 2 Aug 2015 22:12:33 +0300
An EAN beginning with 979 (but not 9790 - those are ISMN's) are accepted
as ISBN numbers, but they cannot be represented in the old, 10-digit ISBN
format. They must be output in the new 13-digit ISBN-13 format. We printed
out an incorrect value for those.
Also add a regression test, to test this and some other basic functionality
of the module.
Patch by Fabien Coelho. This fixes bug #13442, reported by B.Z. Backpatch
to 9.1, where we started to recognize ISBN-13 numbers.
M contrib/isn/Makefile
A contrib/isn/expected/isn.out
M contrib/isn/isn.c
A contrib/isn/sql/isn.sql
Fix incorrect order of lock file removal and failure to close() sockets.
commit : c6d901292f3de94f82a3cfb0f0149eacda09f92b
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/libpq/pqcomm.c
M src/backend/postmaster/postmaster.c
M src/backend/utils/init/miscinit.c
M src/include/libpq/libpq.h
Fix race condition that lead to WALInsertLock deadlock with commit_delay.
commit : bab959906911c97437f410a03b0346e6dd28d528
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 2 Aug 2015 20:08:10 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Sun, 2 Aug 2015 20:08:10 +0300
If a call to WaitForXLogInsertionsToFinish() returned a value in the middle
of a page, and another backend then started to insert a record to the same
page, and then you called WaitXLogInsertionsToFinish() again, the second
call might return a smaller value than the first call. The problem was in
GetXLogBuffer(), which always updated the insertingAt value to the
beginning of the requested page, not the actual requested location. Because
of that, the second call might return a xlog pointer to the beginning of
the page, while the first one returned a later position on the same page.
XLogFlush() performs two calls to WaitXLogInsertionsToFinish() in
succession, and holds WALWriteLock on the second call, which can deadlock
if the second call to WaitXLogInsertionsToFinish() blocks.
Reported by Spiros Ioannou. Backpatch to 9.4, where the more scalable
WALInsertLock mechanism, and this bug, was introduced.
M src/backend/access/transam/xlog.c
Fix some planner issues with degenerate outer join clauses.
commit : e39a3b2efee07237ee34572472edf8a07dbb9e2f
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
Fix an oversight in checking whether a join with LATERAL refs is legal.
commit : 216977a7d99507ca3227a505510bf5ced4f14799
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 Jul 2015 19:26:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 Jul 2015 19:26:33 -0400
In many cases, we can implement a semijoin as a plain innerjoin by first
passing the righthand-side relation through a unique-ification step.
However, one of the cases where this does NOT work is where the RHS has
a LATERAL reference to the LHS; that makes the RHS dependent on the LHS
so that unique-ification is meaningless. joinpath.c understood this,
and so would not generate any join paths of this kind ... but join_is_legal
neglected to check for the case, so it would think that we could do it.
The upshot would be a "could not devise a query plan for the given query"
failure once we had failed to generate any join paths at all for the bogus
join pair.
Back-patch to 9.3 where LATERAL was added.
M src/backend/optimizer/path/joinrels.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Consolidate makefile code for setting top_srcdir, srcdir and VPATH.
commit : 0efa0f62d2f8572e109134f80169aa4224da1b8a
author : Noah Misch <noah@leadboat.com>
date : Thu, 30 Jul 2015 20:48:41 -0400
committer: Noah Misch <noah@leadboat.com>
date : Thu, 30 Jul 2015 20:48:41 -0400
Responsibility was formerly split between Makefile.global and pgxs.mk.
As a result of commit b58233c71b93a32fcab7219585cafc25a27eb769, in the
PGXS case, these variables were unset while parsing Makefile.global and
callees. Inclusion of Makefile.custom did not work from PGXS, and the
subtle difference seemed like a recipe for future bugs. Back-patch to
9.4, where that commit first appeared.
M src/Makefile.global.in
M src/makefiles/pgxs.mk
Avoid some zero-divide hazards in the planner.
commit : 3b4a9dbfa5339405f7f78639b83bfb563603cfe3
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/planner.c
M src/backend/utils/adt/selfuncs.c
Blacklist xlc 32-bit inlining.
commit : 76cf5f1956cec181dcf0956d0d7b673453a50e74
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 : 0f272b8b4cf2a2217de64cb72e12530efb9c9e3b
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 : 082d4283b0e96ad58d7a4bcc196e3bcd9584fb78
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 : ab60847822463613629e11e0675952320319197a
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
Make tap tests store postmaster logs and handle vpaths correctly
commit : 450bf0ba530101822e6d5ecdd3d9c13fe01ebce5
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 28 Jul 2015 16:04:54 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 28 Jul 2015 16:04:54 -0400
Given this it is possible that the buildfarm animals running these tests
will be able to capture adequate logging to allow diagnosis of failures.
M src/Makefile.global.in
M src/test/perl/TestLib.pm
Remove an unsafe Assert, and explain join_clause_is_movable_into() better.
commit : d20f7d5c37d105bef1c5b72dd27d1921dd15252a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 28 Jul 2015 13:20:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 28 Jul 2015 13:20:40 -0400
join_clause_is_movable_into() is approximate, in the sense that it might
sometimes return "false" when actually it would be valid to push the given
join clause down to the specified level. This is okay ... but there was
an Assert in get_joinrel_parampathinfo() that's only safe if the answers
are always exact. Comment out the Assert, and add a bunch of commentary
to clarify what's going on.
Per fuzz testing by Andreas Seltenreich. The added regression test is
a pretty silly query, but it's based on his crasher example.
Back-patch to 9.2 where the faulty logic was introduced.
M src/backend/optimizer/util/relnode.c
M src/backend/optimizer/util/restrictinfo.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Improve logging of TAP tests.
commit : ef57b982d5207b29969080a39160bbcb6614e8c3
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 28 Jul 2015 12:22:21 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 28 Jul 2015 12:22:21 -0400
Create a log file for each test run. Stdout and stderr of the test script,
as well as any subprocesses run as part of the test, are redirected to
the log file. This makes it a lot easier to debug test failures. Also print
the test output (ok 12 - ... messages) to the log file, and the command
line of any external programs executed with the system_or_bail and run_log
functions. This makes it a lot easier to debug failing tests.
Modify some of the pg_ctl and other command invocations to not use 'silent'
or 'quiet' options, and don't redirect output to /dev/null, so that you get
all the information in the log instead.
In the passing, construct some command lines in a way that works if $tempdir
contains quote-characters. I haven't systematically gone through all of
them or tested that, so I don't know if this is enough to make that work.
pg_rewind tests had a custom mechanism for creating a similar log file. Use
the new generic facility instead.
Michael Paquier and Heikki Linnakangas.
This os a backpatch of Heikki's commit
1ea06203b82b98b5098808667f6ba652181ef5b2 modified by me to suit 9.4
M src/Makefile.global.in
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/bin/pg_controldata/t/001_pg_controldata.pl
M src/bin/pg_ctl/t/001_start_stop.pl
M src/bin/pg_ctl/t/002_status.pl
A src/test/perl/SimpleTee.pm
M src/test/perl/TestLib.pm
Don't assume that PageIsEmpty() returns true on an all-zeros page.
commit : 0e98ad0915ce5a665f39707db7652c67a64b5b22
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 27 Jul 2015 18:54:09 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 27 Jul 2015 18:54:09 +0300
It does currently, and I don't see us changing that any time soon, but we
don't make that assumption anywhere else.
Per Tom Lane's suggestion. Backpatch to 9.2, like the previous patch that
added this assumption.
M src/backend/access/spgist/spgvacuum.c
Reuse all-zero pages in GIN.
commit : 746e7f1c187b1dae02b049b1918e5471d7fedfb6
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 handling of all-zero pages in SP-GiST vacuum.
commit : 579b9f97ce99c3ddc8e1de0e1b1f160da2e669c7
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 27 Jul 2015 12:28:21 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 27 Jul 2015 12:28:21 +0300
SP-GiST initialized an all-zeros page at vacuum, but that was not
WAL-logged, which is not safe. You might get a torn page write, when it gets
flushed to disk, and end-up with a half-initialized index page. To fix,
leave it in the all-zeros state, and add it to the FSM. It will be
initialized when reused. Also don't set the page-deleted flag when recycling
an empty page. That was also not WAL-logged, and a torn write of that would
cause the page to have an invalid checksum.
Backpatch to 9.2, where SP-GiST indexes were added.
M src/backend/access/spgist/spgvacuum.c
M src/include/access/spgist_private.h
Make entirely-dummy appendrels get marked as such in set_append_rel_size.
commit : 491c24f055fd14032dee6ed75d43d3aa076add0e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 26 Jul 2015 16:19:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 26 Jul 2015 16:19:08 -0400
The planner generally expects that the estimated rowcount of any relation
is at least one row, *unless* it has been proven empty by constraint
exclusion or similar mechanisms, which is marked by installing a dummy path
as the rel's cheapest path (cf. IS_DUMMY_REL). When I split up
allpaths.c's processing of base rels into separate set_base_rel_sizes and
set_base_rel_pathlists steps, the intention was that dummy rels would get
marked as such during the "set size" step; this is what justifies an Assert
in indxpath.c's get_loop_count that other relations should either be dummy
or have positive rowcount. Unfortunately I didn't get that quite right
for append relations: if all the child rels have been proven empty then
set_append_rel_size would come up with a rowcount of zero, which is
correct, but it didn't then do set_dummy_rel_pathlist. (We would have
ended up with the right state after set_append_rel_pathlist, but that's
too late, if we generate indexpaths for some other rel first.)
In addition to fixing the actual bug, I installed an Assert enforcing this
convention in set_rel_size; that then allows simplification of a couple
of now-redundant tests for zero rowcount in set_append_rel_size.
Also, to cover the possibility that third-party FDWs have been careless
about not returning a zero rowcount estimate, apply clamp_row_est to
whatever an FDW comes up with as the rows estimate.
Per report from Andreas Seltenreich. Back-patch to 9.2. Earlier branches
did not have the separation between set_base_rel_sizes and
set_base_rel_pathlists steps, so there was no intermediate state where an
appendrel would have had inconsistent rowcount and pathlist. It's possible
that adding the Assert to set_rel_size would be a good idea in older
branches too; but since they're not under development any more, it's likely
not worth the trouble.
M src/backend/optimizer/path/allpaths.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Restore use of zlib default compression in pg_dump directory mode.
commit : 41ed5bb9aeddddbe8f8afb901567fd5f306d2a45
author : Andrew Dunstan <andrew@dunslane.net>
date : Sat, 25 Jul 2015 17:14:36 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sat, 25 Jul 2015 17:14:36 -0400
This was broken by commit 0e7e355f27302b62af3e1add93853ccd45678443 and
friends, which ignored the fact that gzopen() will treat "-1" in the
mode argument as an invalid character, which it ignores, and a flag for
compression level 1. Now, when this value is encountered no compression
level flag is passed to gzopen, leaving it to use the zlib default.
Also, enforce the documented allowed range for pg_dump's -Z option,
namely 0 .. 9, and remove some consequently dead code from
pg_backup_tar.c.
Problem reported by Marc Mamin.
Backpatch to 9.1, like the patch that introduced the bug.
M src/bin/pg_dump/compress_io.c
M src/bin/pg_dump/pg_backup_tar.c
M src/bin/pg_dump/pg_dump.c
Fix off-by-one error in calculating subtrans/multixact truncation point.
commit : b7551339dfde58682dfd9f32f6cea27491da6463
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 23 Jul 2015 01:30:09 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 23 Jul 2015 01:30:09 +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
Fix add_rte_to_flat_rtable() for recent feature additions.
commit : b6e7780346bae5fe07bd4631d355e692e1a8d006
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 Jul 2015 20:03:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 Jul 2015 20:03:58 -0400
The TABLESAMPLE and row security patches each overlooked this function,
though their errors of omission were opposite: RLS failed to zero out the
securityQuals field, leading to wasteful copying of useless expression
trees in finished plans, while TABLESAMPLE neglected to add a comment
saying that it intentionally *isn't* deleting the tablesample subtree.
There probably should be a similar comment about ctename, too.
Back-patch as appropriate.
M src/backend/optimizer/plan/setrefs.c
Fix (some of) pltcl memory usage
commit : 49c30004073fdb90800054cd1d13e5ab441f6283
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
Make WaitLatchOrSocket's timeout detection more robust.
commit : 29efe1b5ebc82512cae363349bae6dd22e9b00eb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 Jul 2015 11:47:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 Jul 2015 11:47:13 -0400
In the previous coding, timeout would be noticed and reported only when
poll() or socket() returned zero (or the equivalent behavior on Windows).
Ordinarily that should work well enough, but it seems conceivable that we
could get into a state where poll() always returns a nonzero value --- for
example, if it is noticing a condition on one of the file descriptors that
we do not think is reason to exit the loop. If that happened, we'd be in a
busy-wait loop that would fail to terminate even when the timeout expires.
We can make this more robust at essentially no cost, by deciding to exit
of our own accord if we compute a zero or negative time-remaining-to-wait.
Previously the code noted this but just clamped the time-remaining to zero,
expecting that we'd detect timeout on the next loop iteration.
Back-patch to 9.2. While 9.1 had a version of WaitLatchOrSocket, it was
primitive compared to later versions, and did not guarantee reliable
detection of timeouts anyway. (Essentially, this is a refinement of
commit 3e7fdcffd6f77187, which was back-patched only as far as 9.2.)
M src/backend/port/unix_latch.c
M src/backend/port/win32_latch.c
AIX: Test the -qlonglong option before use.
commit : f3f037e187c601d76777ae10b10657a0c0d3299c
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 : b8f368276916b677f0678982e81723fe30e5c582
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/backend/utils/sort/gen_qsort_tuple.pl
M src/port/qsort.c
M src/port/qsort_arg.c
Fix spelling error
commit : c97883a5ba5c0d6b6210d8753f8ac5b99b305984
author : Magnus Hagander <magnus@hagander.net>
date : Thu, 16 Jul 2015 10:31:58 +0300
committer: Magnus Hagander <magnus@hagander.net>
date : Thu, 16 Jul 2015 10:31:58 +0300
David Rowley
M src/backend/optimizer/plan/createplan.c
AIX: Link the postgres executable with -Wl,-brtllib.
commit : 2405107b43ac0739b31251f433a5aaa87b61ecf1
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 assorted memory leaks.
commit : 1ed5493877220affaa235427f4346afd932ce1ae
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 12 Jul 2015 16:25:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 12 Jul 2015 16:25:51 -0400
Per Coverity (not that any of these are so non-obvious that they should not
have been caught before commit). The extent of leakage is probably minor
to unnoticeable, but a leak is a leak. Back-patch as necessary.
Michael Paquier
M src/bin/pg_dump/pg_dump.c
Improve documentation about array concat operator vs. underlying functions.
commit : 8989a52657332c98fab56de6b86c41d93ea0c621
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 Jul 2015 18:50:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 Jul 2015 18:50:31 -0400
The documentation implied that there was seldom any reason to use the
array_append, array_prepend, and array_cat functions directly. But that's
not really true, because they can help make it clear which case is meant,
which the || operator can't do since it's overloaded to represent all three
cases. Add some discussion and examples illustrating the potentially
confusing behavior that can ensue if the parser misinterprets what was
meant.
Per a complaint from Michael Herold. Back-patch to 9.2, which is where ||
started to behave this way.
M doc/src/sgml/array.sgml
Fix postmaster's handling of a startup-process crash.
commit : 0d01c5b932ef2da9e5e281e2aa8541536e1ecdd1
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 : cf0c44611c5c15ef49f2699223bf8c9e8fa980cf
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
Replace use of "diff -q".
commit : 42b6922f31169f644446837120da9ba6e982e937
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
POSIX does not specify the -q option, and many implementations do not
offer it. Don't bother changing the MSVC build system, because having
non-GNU diff on Windows is vanishingly unlikely. Back-patch to 9.2,
where this invocation was introduced.
M contrib/pg_upgrade/test.sh
Fix null pointer dereference in "\c" psql command.
commit : eb1525e8968e64c7ec31701fa02c6da999b58d1a
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
Fix portability issue in pg_upgrade test script: avoid $PWD.
commit : 58c58d1a9f4ba5372f683eb823e065ed12469e5e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Jul 2015 12:49:18 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Jul 2015 12:49:18 -0400
SUSv2-era shells don't set the PWD variable, though anything more modern
does. In the buildfarm environment this could lead to test.sh executing
with PWD pointing to $HOME or another high-level directory, so that there
were conflicts between concurrent executions of the test in different
branch subdirectories. This appears to be the explanation for recent
intermittent failures on buildfarm members binturong and dingo (and might
well have something to do with the buildfarm script's failure to capture
log files from pg_upgrade tests, too).
To fix, just use `pwd` in place of $PWD. AFAICS test.sh is the only place
in our source tree that depended on $PWD. Back-patch to all versions
containing this script.
Per buildfarm. Thanks to Oskari Saarenmaa for diagnosing the problem.
M contrib/pg_upgrade/test.sh
Improve handling of out-of-memory in libpq.
commit : 992c6f0d2ca839ba54279fbc1a5d5e01e2e18f58
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 : 4dac5651b15ded7ce3b730aec936bec957b2c86a
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
Fix logical decoding bug leading to inefficient reopening of files.
commit : 81fc89a5eb006628246029cd49974e158ea153ba
author : Andres Freund <andres@anarazel.de>
date : Tue, 7 Jul 2015 13:12:59 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 7 Jul 2015 13:12:59 +0200
When spilling transaction data to disk a simple typo caused the output
file to be closed and reopened for every serialized change. That happens
to not have a huge impact on linux, which is why it probably wasn't
noticed so far, but on windows that appears to trigger actual disk
writes after every change. Not fun.
The bug fortunately does not have any impact besides speed. A change
could end up being in the wrong segment (last instead of next), but
since we read all files to the end, that's just ugly, not really
problematic. It's not a problem to upgrade, since transaction spill
files do not persist across restarts.
Bug: #13484
Reported-By: Olivier Gosseaume
Discussion: 20150703090217.1190.63940@wrigleys.postgresql.org
Backpatch to 9.4, where logical decoding was added.
M src/backend/replication/logical/reorderbuffer.c
Fix pg_recvlogical not to fsync output when it's a tty or pipe.
commit : 1790b35baf52fff7f670f7cc1159a1b40b36e701
author : Andres Freund <andres@anarazel.de>
date : Tue, 7 Jul 2015 12:47:44 +0200
committer: Andres Freund <andres@anarazel.de>
date : Tue, 7 Jul 2015 12:47:44 +0200
The previous coding tried to handle possible failures when fsyncing a
tty or pipe fd by accepting EINVAL - but apparently some
platforms (windows, OSX) don't reliably return that. So instead check
whether the output fd refers to a pipe or a tty when opening it.
Reported-By: Olivier Gosseaume, Marko Tiikkaja
Discussion: 559AF98B.3050901@joh.to
Backpatch to 9.4, where pg_recvlogical was added.
M src/bin/pg_basebackup/pg_recvlogical.c
Remove incorrect warning from pg_archivecleanup document.
commit : 0471894a6f01007752abd37ca493ed371a720bdd
author : Fujii Masao <fujii@postgresql.org>
date : Mon, 6 Jul 2015 20:58:58 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Mon, 6 Jul 2015 20:58:58 +0900
The .backup file name can be passed to pg_archivecleanup even if
it includes the extension which is specified in -x option.
However, previously the document incorrectly warned a user
not to do that.
Back-patch to 9.2 where pg_archivecleanup's -x option and
the warning were added.
M doc/src/sgml/pgarchivecleanup.sgml
Fix some typos in regression test comments.
commit : 353f4fde794fca07f6f654219a12d8087930fa28
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 Jul 2015 13:14:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 Jul 2015 13:14:38 -0400
Back-patch to avoid unnecessary cross-branch differences.
CharSyam
M src/test/regress/expected/alter_generic.out
M src/test/regress/expected/jsonb.out
M src/test/regress/expected/jsonb_1.out
M src/test/regress/sql/alter_generic.sql
M src/test/regress/sql/jsonb.sql
Make numeric form of PG version number readily available in Makefiles.
commit : 60c38e62cd15b1ad3f769f6d5ec37f98508bca28
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 Jul 2015 12:01:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 Jul 2015 12:01:01 -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 : 4a1944ec6caf41f1008e86296fa8712ba8b59317
author : Peter Eisentraut <peter_e@gmx.net>
date : Sun, 21 Jun 2015 10:37:24 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sun, 21 Jun 2015 10:37:24 -0400
A src/pl/plperl/expected/plperl_elog_1.out
Fix pgbench progress report behaviour when pgbench or a query gets stuck.
commit : 9d6352aaae1bf43f06253dcc931534a5254a937a
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 3 Jul 2015 11:04:57 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 3 Jul 2015 11:04:57 +0300
There were two issues here. First, if a query got stuck so that it took
e.g. 5 seconds, and progress interval was 1 second, no progress reports were
printed until the query returned. Fix so that we wake up specifically to
print the progress report. Secondly, if pgbench got stuck so that it would
nevertheless not print a progress report on time, and enough time passes
that it's already time to print the next progress report, just skip the one
that was missed. Before this patch, it would print the missed one with 0 TPS
immediately after the previous one.
Fabien Coelho. Backpatch to 9.4, where progress reports were added.
M contrib/pgbench/pgbench.c
Don't emit a spurious space at end of line in pg_dump of event triggers.
commit : 0eaa49a5c4848f3f3fa5588dc58cb9af47779fb4
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 2 Jul 2015 12:50:29 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 2 Jul 2015 12:50:29 +0300
Backpatch to 9.3 and above, where event triggers were added.
M src/bin/pg_dump/pg_dump.c
Fix broken link in documentation.
commit : 505f78c446b0a149efb93ec61350e36ddc306152
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 : ef704ec069fd97c41d91640558f70d37a04b6bd1
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 30 Jun 2015 14:20:38 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 30 Jun 2015 14:20:38 -0300
Apparently, this is needed in some Solaris versions.
Author: Oskari Saarenmaa
M configure
M configure.in
Don't call PageGetSpecialPointer() on page until it's been initialized.
commit : 7dc721889b31450cad338a189a97ff0ff46534d5
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 30 Jun 2015 13:37:16 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 30 Jun 2015 13:37:16 +0300
After calling XLogInitBufferForRedo(), the page might be all-zeros if it was
not in page cache already. btree_xlog_unlink_page initialized the page
correctly, but it called PageGetSpecialPointer before initializing it, which
would lead to a corrupt page at WAL replay, if the unlinked page is not in
page cache.
Backpatch to 9.4, the bug came with the rewrite of B-tree page deletion.
M src/backend/access/nbtree/nbtxlog.c
Back-patch some minor bug fixes in GUC code.
commit : 1afc1fe9c7bb72652ff9681c2e59a5751a33cda1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Jun 2015 18:38:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Jun 2015 18:38:06 -0400
In 9.4, fix a 9.4.1 regression that allowed multiple entries for a
PGC_POSTMASTER variable to cause bogus complaints in the postmaster log.
(The issue here was that commit bf007a27acd7b2fb unintentionally reverted
3e3f65973a3c94a6, which suppressed any duplicate entries within
ParseConfigFp. Back-patch the reimplementation just made in HEAD, which
makes use of an "ignore" field to prevent application of superseded items.)
Add missed failure check in AlterSystemSetConfigFile(). We don't really
expect ParseConfigFp() to fail, but that's not an excuse for not checking.
In both 9.3 and 9.4, remove mistaken assignment to ConfigFileLineno that
caused line counting after an include_dir directive to be completely wrong.
M src/backend/utils/misc/guc-file.l
M src/backend/utils/misc/guc.c
M src/include/utils/guc.h
Fix comment for GetCurrentIntegerTimestamp().
commit : f9f71503767f0212a1d4141a2370dfc63c7ec050
author : Kevin Grittner <kgrittn@postgresql.org>
date : Sun, 28 Jun 2015 12:45:41 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Sun, 28 Jun 2015 12:45:41 -0500
The unit of measure is microseconds, not milliseconds.
Backpatch to 9.3 where the function and its comment were added.
M src/backend/utils/adt/timestamp.c
Fix function declaration style to respect the coding standard.
commit : 9a437994400f5fdadac103fc5df0c5d622d5c8be
author : Tatsuo Ishii <ishii@postgresql.org>
date : Sun, 28 Jun 2015 18:54:27 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Sun, 28 Jun 2015 18:54:27 +0900
M contrib/pgbench/pgbench.c
Fix test_decoding's handling of nonexistant columns in old tuple versions.
commit : ed6c8d73619a69c8751c8662242fdce22d31bc42
author : Andres Freund <andres@anarazel.de>
date : Sat, 27 Jun 2015 18:49:00 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sat, 27 Jun 2015 18:49:00 +0200
test_decoding used fastgetattr() to extract column values. That's wrong
when decoding updates and deletes if a table's replica identity is set
to FULL and new columns have been added since the old version of the
tuple was created. Due to the lack of a crosscheck with the datum's
natts values an invalid value will be output, leading to errors or
worse.
Bug: #13470
Reported-By: Krzysztof Kotlarski
Discussion: 20150626100333.3874.90852@wrigleys.postgresql.org
Backpatch to 9.4, where the feature, including the bug, was added.
M contrib/test_decoding/expected/ddl.out
M contrib/test_decoding/sql/ddl.sql
M contrib/test_decoding/test_decoding.c
Add opaque declaration of HTAB to tqual.h.
commit : 524e1e40316afc3cf8ba70910fefe1f99b18144f
author : Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 27 Jun 2015 09:55:08 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Sat, 27 Jun 2015 09:55:08 -0500
Commit b89e151054a05f0f6d356ca52e3b725dd0505e53 added the
ResolveCminCmaxDuringDecoding declaration to tqual.h, which uses an
HTAB parameter, without declaring HTAB. It accidentally fails to
fail to build with current sources because a declaration happens to
be included, directly or indirectly, in all source files that
currently use tqual.h before tqual.h is first included, but we
shouldn't count on that. Since an opaque declaration is enough
here, just use that, as was done in snapmgr.h.
Backpatch to 9.4, where the HTAB reference was added to tqual.h.
M src/include/utils/tqual.h
Revoke incorrectly applied patch version
commit : 8ab0ef89d918eacda05413a6ea593b0d6e9525b9
author : Simon Riggs <simon@2ndQuadrant.com>
date : Sat, 27 Jun 2015 02:21:03 +0100
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Sat, 27 Jun 2015 02:21:03 +0100
M src/backend/access/heap/heapam.c
Avoid hot standby cancels from VAC FREEZE
commit : 9af67b667cca10b3f458548c90a75e4e45ced2b3
author : Simon Riggs <simon@2ndQuadrant.com>
date : Sat, 27 Jun 2015 00:44:56 +0100
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Sat, 27 Jun 2015 00:44:56 +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 a couple of bugs with wal_log_hints.
commit : b6c4b58ac52aa9046c45bd8c2c9fc8925087c8d3
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 26 Jun 2015 12:38:24 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 26 Jun 2015 12:38:24 +0300
1. Replay of the WAL record for setting a bit in the visibility map
contained an assertion that a full-page image of that record type can only
occur with checksums enabled. But it can also happen with wal_log_hints, so
remove the assertion. Unlike checksums, wal_log_hints can be changed on the
fly, so it would be complicated to figure out if it was enabled at the time
that the WAL record was generated.
2. wal_log_hints has the same effect on the locking needed to read the LSN
of a page as data checksums. BufferGetLSNAtomic() didn't get the memo.
Backpatch to 9.4, where wal_log_hints was added.
M src/backend/access/heap/heapam.c
M src/backend/storage/buffer/bufmgr.c
Allow background workers to connect to no particular database.
commit : 8364510a463a06375d237de19dcae929e7fb8360
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 25 Jun 2015 15:52:13 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 25 Jun 2015 15:52:13 -0400
The documentation claims that this is supported, but it didn't
actually work. Fix that.
Reported by Pavel Stehule; patch by me.
M src/backend/utils/init/postinit.c
Fix the logic for putting relations into the relcache init file.
commit : e118555cf92c06f16893e577363b6764ed2339e3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Jun 2015 14:39:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Jun 2015 14:39:05 -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
Docs: fix claim that to_char('FM') removes trailing zeroes.
commit : 38c6b19415f107bede50e956f9cedc6e0dfca14a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Jun 2015 10:44:03 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Jun 2015 10:44:03 -0400
Of course, what it removes is leading zeroes. Seems to have been a thinko
in commit ffe92d15d53625d5ae0c23f4e1984ed43614a33d. Noted by Hubert Depesz
Lubaczewski.
M doc/src/sgml/func.sgml
Improve inheritance_planner()'s performance for large inheritance sets.
commit : d8f9ab776c579cbc886840795cd51fab5a3c2d8a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 22 Jun 2015 18:53:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 22 Jun 2015 18:53:27 -0400
Commit c03ad5602f529787968fa3201b35c119bbc6d782 introduced a planner
performance regression for UPDATE/DELETE on large inheritance sets.
It required copying the append_rel_list (which is of size proportional to
the number of inherited tables) once for each inherited table, thus
resulting in O(N^2) time and memory consumption. While it's difficult to
avoid that in general, the extra work only has to be done for
append_rel_list entries that actually reference subquery RTEs, which
inheritance-set entries will not. So we can buy back essentially all of
the loss in cases without subqueries in FROM; and even for those, the added
work is mainly proportional to the number of UNION ALL subqueries.
Back-patch to 9.2, like the previous commit.
Tom Lane and Dean Rasheed, per a complaint from Thomas Munro.
M src/backend/optimizer/plan/planner.c
Truncate strings in tarCreateHeader() with strlcpy(), not sprintf().
commit : d1c1e48832f31c1a4d01201a31a60c751ed4895c
author : Noah Misch <noah@leadboat.com>
date : Sun, 21 Jun 2015 20:04:36 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sun, 21 Jun 2015 20:04:36 -0400
This supplements the GNU libc bug #6530 workarounds introduced in commit
54cd4f04576833abc394e131288bf3dd7dcf4806. On affected systems, a
tar-format pg_basebackup failed when some filename beneath the data
directory was not valid character data in the postmaster/walsender
locale. Back-patch to 9.1, where pg_basebackup was introduced. Extant,
bug-prone conversion specifications receive only ASCII bytes or involve
low-importance messages.
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/port/tar.c
Improve multixact emergency autovacuum logic.
commit : ec1408155d3567b9e9871ad092ea773251d515d9
author : Andres Freund <andres@anarazel.de>
date : Sun, 21 Jun 2015 18:57:28 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sun, 21 Jun 2015 18:57:28 +0200
Previously autovacuum was not necessarily triggered if space in the
members slru got tight. The first problem was that the signalling was
tied to values in the offsets slru, but members can advance much
faster. Thats especially a problem if old sessions had been around that
previously prevented the multixact horizon to increase. Secondly the
skipping logic doesn't work if the database was restarted after
autovacuum was triggered - that knowledge is not preserved across
restart. This is especially a problem because it's a common
panic-reaction to restart the database if it gets slow to
anti-wraparound vacuums.
Fix the first problem by separating the logic for members from
offsets. Trigger autovacuum whenever a multixact crosses a segment
boundary, as the current member offset increases in irregular values, so
we can't use a simple modulo logic as for offsets. Add a stopgap for
the second problem, by signalling autovacuum whenver ERRORing out
because of boundaries.
Discussion: 20150608163707.GD20772@alap3.anarazel.de
Backpatch into 9.3, where it became more likely that multixacts wrap
around.
M src/backend/access/transam/multixact.c
Add missing check for wal_debug GUC.
commit : 67876a17eb36cea9d98a89defe1b5dd4d867bd64
author : Andres Freund <andres@anarazel.de>
date : Sun, 21 Jun 2015 18:35:59 +0200
committer: Andres Freund <andres@anarazel.de>
date : Sun, 21 Jun 2015 18:35:59 +0200
9a20a9b2 added a new elog(), enabled when WAL_DEBUG is defined. The
other WAL_DEBUG dependant messages check for the wal_debug GUC, but this
one did not. While at it replace 'upto' with 'up to'.
Discussion: 20150610110253.GF3832@alap3.anarazel.de
Backpatch to 9.4, the first release containing 9a20a9b2.
M src/backend/access/transam/xlog.c
Fix failure to copy setlocale() return value.
commit : b2ed1682d4e13469b968f2f8581ca35df7d4e6ca
author : Noah Misch <noah@leadboat.com>
date : Sat, 20 Jun 2015 12:09:29 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sat, 20 Jun 2015 12:09:29 -0400
POSIX permits setlocale() calls to invalidate any previous setlocale()
return values, but commit 5f538ad004aa00cf0881f179f0cde789aad4f47e
neglected to account for setlocale(LC_CTYPE, NULL) doing so. The effect
was to set the LC_CTYPE environment variable to an unintended value.
pg_perm_setlocale() sets this variable to assist PL/Perl; without it,
Perl would undo PostgreSQL's locale settings. The known-affected
configurations are 32-bit, release builds using Visual Studio 2012 or
Visual Studio 2013. Visual Studio 2010 is unaffected, as were all
buildfarm-attested configurations. In principle, this bug could leave
the wrong LC_CTYPE in effect after PL/Perl use, which could in turn
facilitate problems like corrupt tsvector datums. No known platform
experiences that consequence, because PL/Perl on Windows does not use
this environment variable.
The bug has been user-visible, as early postmaster failure, on systems
with Windows ANSI code page set to CP936 for "Chinese (Simplified, PRC)"
and probably on systems using other multibyte code pages.
(SetEnvironmentVariable() rejects values containing character data not
valid under the Windows ANSI code page.) Back-patch to 9.4, where the
faulty commit first appeared.
Reported by Didi Hu and 林鹏程. Reviewed by Tom Lane, though this fix
strategy was not his first choice.
M src/backend/utils/adt/pg_locale.c
Fix thinko in comment (launcher -> worker)
commit : b8839b3a74b776f94dae9852453fca98aa20032f
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sat, 20 Jun 2015 11:45:59 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sat, 20 Jun 2015 11:45:59 -0300
M src/backend/postmaster/autovacuum.c
In immediate shutdown, postmaster should not exit till children are gone.
commit : 29722d79b820c8f8e37517e0dbd0deb3995d4986
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 19 Jun 2015 14:23:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 19 Jun 2015 14:23:39 -0400
This adjusts commit 82233ce7ea42d6ba519aaec63008aff49da6c7af so that the
postmaster does not exit until all its child processes have exited, even
if the 5-second timeout elapses and we have to send SIGKILL. There is no
great value in having the postmaster process quit sooner, and doing so can
mislead onlookers into thinking that the cluster is fully terminated when
actually some child processes still survive.
This effect might explain recent test failures on buildfarm member hamster,
wherein we failed to restart a cluster just after shutting it down with
"pg_ctl stop -m immediate".
I also did a bit of code review/beautification, including fixing a faulty
use of the Max() macro on a volatile expression.
Back-patch to 9.4. In older branches, the postmaster never waited for
children to exit during immediate shutdowns, and changing that would be
too much of a behavioral change.
M doc/src/sgml/runtime.sgml
M src/backend/postmaster/postmaster.c
Clamp autovacuum launcher sleep time to 5 minutes
commit : cf733760eae1523022b652d4e673d336ef81b235
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 19 Jun 2015 12:44:35 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 19 Jun 2015 12:44:35 -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
Fix corner case in autovacuum-forcing logic for multixact wraparound.
commit : 8507a5b37bd95717572c5fd1863758f478fe7b10
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 19 Jun 2015 11:28:30 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 19 Jun 2015 11:28:30 -0400
Since find_multixact_start() relies on SimpleLruDoesPhysicalPageExist(),
and that function looks only at the on-disk state, it's possible for it
to fail to find a page that exists in the in-memory SLRU that has not
been written yet. If that happens, SetOffsetVacuumLimit() will
erroneously decide to force emergency autovacuuming immediately.
We should probably fix find_multixact_start() to consider the data
cached in memory as well as on the on-disk state, but that's no excuse
for SetOffsetVacuumLimit() to be stupid about the case where it can
no longer read the value after having previously succeeded in doing so.
Report by Andres Freund.
M src/backend/access/transam/multixact.c
Check for out of memory when allocating sqlca.
commit : 2a781b5bb260209be0d856c6a43d15194d6848e0
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
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 : 853222ce0012d56f26138709eecc7939f04a996d
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
Fix intoasc() in Informix compat lib. This function used to be a noop.
commit : 70767ac268de045b14fb7d6e570071f37ce13e74
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
Fixed some memory leaks in ECPG.
commit : 4f60d66587f6ed27887d20e3d70da61de5541ab2
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
M src/interfaces/ecpg/preproc/descriptor.c
M src/interfaces/ecpg/preproc/pgc.l
M src/interfaces/ecpg/preproc/variable.c
Improve error message and hint for ALTER COLUMN TYPE can't-cast failure.
commit : 1c150f8aa759aaa9e5761da79653894510d868db
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 12 Jun 2015 11:54:03 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 12 Jun 2015 11:54:03 -0400
We already tried to improve this once, but the "improved" text was rather
off-target if you had provided a USING clause. Also, it seems helpful
to provide the exact text of a suggested USING clause, so users can just
copy-and-paste it when needed. Per complaint from Keith Rarick and a
suggestion from Merlin Moncure.
Back-patch to 9.2 where the current wording was adopted.
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Fix typo in comment.
commit : e9eebbaebf8a494c40b316e203287fd71dd0fd90
author : Kevin Grittner <kgrittn@postgresql.org>
date : Wed, 10 Jun 2015 17:04:06 -0500
committer: Kevin Grittner <kgrittn@postgresql.org>
date : Wed, 10 Jun 2015 17:04:06 -0500
Backpatch to 9.4 to minimize possible conflicts.
M src/include/utils/tqual.h