Stamp 9.2.18.
commit : 01de6f3fd80721583baf2378ee8fe2b06a448ed0
author : Tom Lane <[email protected]>
date : Mon, 8 Aug 2016 16:33:27 -0400
committer: Tom Lane <[email protected]>
date : Mon, 8 Aug 2016 16:33:27 -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
Last-minute updates for release notes.
commit : c5081941f921bd342529b255ed2af1adccc253ed
author : Tom Lane <[email protected]>
date : Mon, 8 Aug 2016 11:56:10 -0400
committer: Tom Lane <[email protected]>
date : Mon, 8 Aug 2016 11:56:10 -0400 Security: CVE-2016-5423, CVE-2016-5424 M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
Fix several one-byte buffer over-reads in to_number
commit : b0134fe84da073f5c8ed4bbfac4a7111c1f7d799
author : Peter Eisentraut <[email protected]>
date : Mon, 8 Aug 2016 11:12:59 -0400
committer: Peter Eisentraut <[email protected]>
date : Mon, 8 Aug 2016 11:12:59 -0400 Several places in NUM_numpart_from_char(), which is called from the SQL
function to_number(text, text), could accidentally read one byte past
the end of the input buffer (which comes from the input text datum and
is not null-terminated).
1. One leading space character would be skipped, but there was no check
that the input was at least one byte long. This does not happen in
practice, but for defensiveness, add a check anyway.
2. Commit 4a3a1e2cf apparently accidentally doubled that code that skips
one space character (so that two spaces might be skipped), but there
was no overflow check before skipping the second byte. Fix by
removing that duplicate code.
3. A logic error would allow a one-byte over-read when looking for a
trailing sign (S) placeholder.
In each case, the extra byte cannot be read out directly, but looking at
it might cause a crash.
The third item was discovered by Piotr Stefaniak, the first two were
found and analyzed by Tom Lane and Peter Eisentraut. M src/backend/utils/adt/formatting.c
Translation updates
commit : e990c738b4f96befb43daa11c7d352a8d68d127d
author : Peter Eisentraut <[email protected]>
date : Mon, 8 Aug 2016 10:48:56 -0400
committer: Peter Eisentraut <[email protected]>
date : Mon, 8 Aug 2016 10:48:56 -0400 Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 940819d75443c03de7554441c3b1e2bc42f76c8f M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/ru.po
M src/bin/psql/po/de.po
Fix two errors with nested CASE/WHEN constructs.
commit : 8b32516db20c836d6e3c31d81adf75b3a297663d
author : Tom Lane <[email protected]>
date : Mon, 8 Aug 2016 10:33:47 -0400
committer: Tom Lane <[email protected]>
date : Mon, 8 Aug 2016 10:33:47 -0400 ExecEvalCase() tried to save a cycle or two by passing
&econtext->caseValue_isNull as the isNull argument to its sub-evaluation of
the CASE value expression. If that subexpression itself contained a CASE,
then *isNull was an alias for econtext->caseValue_isNull within the
recursive call of ExecEvalCase(), leading to confusion about whether the
inner call's caseValue was null or not. In the worst case this could lead
to a core dump due to dereferencing a null pointer. Fix by not assigning
to the global variable until control comes back from the subexpression.
Also, avoid using the passed-in isNull pointer transiently for evaluation
of WHEN expressions. (Either one of these changes would have been
sufficient to fix the known misbehavior, but it's clear now that each of
these choices was in itself dangerous coding practice and best avoided.
There do not seem to be any similar hazards elsewhere in execQual.c.)
Also, it was possible for inlining of a SQL function that implements the
equality operator used for a CASE comparison to result in one CASE
expression's CaseTestExpr node being inserted inside another CASE
expression. This would certainly result in wrong answers since the
improperly nested CaseTestExpr would be caused to return the inner CASE's
comparison value not the outer's. If the CASE values were of different
data types, a crash might result; moreover such situations could be abused
to allow disclosure of portions of server memory. To fix, teach
inline_function to check for "bare" CaseTestExpr nodes in the arguments of
a function to be inlined, and avoid inlining if there are any.
Heikki Linnakangas, Michael Paquier, Tom Lane
Report: https://github.com/greenplum-db/gpdb/pull/327
Report: <[email protected]>
Security: CVE-2016-5423 M src/backend/executor/execQual.c
M src/backend/optimizer/util/clauses.c
M src/test/regress/expected/case.out
M src/test/regress/sql/case.sql
Obstruct shell, SQL, and conninfo injection via database and role names.
commit : e8f4922c8683881236b1feb11d4e8ea35ab41cd7
author : Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:46 -0400
committer: Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:46 -0400 Due to simplistic quoting and confusion of database names with conninfo
strings, roles with the CREATEDB or CREATEROLE option could escalate to
superuser privileges when a superuser next ran certain maintenance
commands. The new coding rule for PQconnectdbParams() calls, documented
at conninfo_array_parse(), is to pass expand_dbname=true and wrap
literal database names in a trivial connection string. Escape
zero-length values in appendConnStrVal(). Back-patch to 9.1 (all
supported versions).
Nathan Bossart, Michael Paquier, and Noah Misch. Reviewed by Peter
Eisentraut. Reported by Nathan Bossart.
Security: CVE-2016-5424 M contrib/pg_upgrade/pg_upgrade.h
M contrib/pg_upgrade/server.c
M contrib/pg_upgrade/test.sh
M contrib/pg_upgrade/util.c
M contrib/pg_upgrade/version.c
M contrib/pg_upgrade/version_old_8_3.c
M src/bin/pg_dump/dumputils.c
M src/bin/pg_dump/dumputils.h
M src/bin/pg_dump/pg_backup.h
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_db.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/psql/command.c
M src/bin/scripts/Makefile
M src/bin/scripts/clusterdb.c
M src/bin/scripts/reindexdb.c
M src/bin/scripts/vacuumdb.c
M src/interfaces/libpq/fe-connect.c
M src/tools/msvc/vcregress.pl
Promote pg_dumpall shell/connstr quoting functions to src/fe_utils.
commit : f1d0b09cf17ee12481a62faa9413f9cc3f3f8112
author : Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:46 -0400
committer: Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:46 -0400 Rename these newly-extern functions with terms more typical of their new
neighbors. No functional changes; a subsequent commit will use them in
more places. Back-patch to 9.1 (all supported versions). Back branches
lack src/fe_utils, so instead rename the functions in place; the
subsequent commit will copy them into the other programs using them.
Security: CVE-2016-5424 M src/bin/pg_dump/pg_dumpall.c
Back-patch "Only quote libpq connection string values that need quoting."
commit : a19edcd2407d7dc8677513d1770e41b11a851163
author : Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:53 -0400
committer: Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:53 -0400 Back-patch commit 2953cd6d17210935098c803c52c6df5b12a725b9 and certain
runPgDump() bits of 3dee636e0404885d07885d41c0d70e50c784f324 to 9.2 and
9.1. This synchronizes their doConnStrQuoting() implementations with
later releases. Subsequent security patches will modify that function.
Security: CVE-2016-5424 M src/bin/pg_dump/pg_dumpall.c
Fix Windows shell argument quoting.
commit : 4837155292f67f10576f3d7204ffd5379bbe3a7b
author : Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:46 -0400
committer: Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:46 -0400 The incorrect quoting may have permitted arbitrary command execution.
At a minimum, it gave broader control over the command line to actors
supposed to have control over a single argument. Back-patch to 9.1 (all
supported versions).
Security: CVE-2016-5424 M src/bin/pg_dump/pg_dumpall.c
Reject, in pg_dumpall, names containing CR or LF.
commit : ffbdab65d3451d72762319829b4bc26dc71a8b48
author : Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:46 -0400
committer: Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:46 -0400 These characters prematurely terminate Windows shell command processing,
causing the shell to execute a prefix of the intended command. The
chief alternative to rejecting these characters was to bypass the
Windows shell with CreateProcess(), but the ability to use such names
has little value. Back-patch to 9.1 (all supported versions).
This change formally revokes support for these characters in database
names and roles names. Don't document this; the error message is
self-explanatory, and too few users would benefit. A future major
release may forbid creation of databases and roles so named. For now,
check only at known weak points in pg_dumpall. Future commits will,
without notice, reject affected names from other frontend programs.
Also extend the restriction to pg_dumpall --dbname=CONNSTR arguments and
--file arguments. Unlike the effects on role name arguments and
database names, this does not reflect a broad policy change. A
migration to CreateProcess() could lift these two restrictions.
Reviewed by Peter Eisentraut.
Security: CVE-2016-5424 M src/bin/pg_dump/pg_dumpall.c
Field conninfo strings throughout src/bin/scripts.
commit : a466ea33c0acbf9938144ffd9eecdabbb69e8f46
author : Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:46 -0400
committer: Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:46 -0400 These programs nominally accepted conninfo strings, but they would
proceed to use the original dbname parameter as though it were an
unadorned database name. This caused "reindexdb dbname=foo" to issue an
SQL command that always failed, and other programs printed a conninfo
string in error messages that purported to print a database name. Fix
both problems by using PQdb() to retrieve actual database names.
Continue to print the full conninfo string when reporting a connection
failure. It is informative there, and if the database name is the sole
problem, the server-side error message will include the name. Beyond
those user-visible fixes, this allows a subsequent commit to synthesize
and use conninfo strings without that implementation detail leaking into
messages. As a side effect, the "vacuuming database" message now
appears after, not before, the connection attempt. Back-patch to 9.1
(all supported versions).
Reviewed by Michael Paquier and Peter Eisentraut.
Security: CVE-2016-5424 M src/bin/scripts/clusterdb.c
M src/bin/scripts/createlang.c
M src/bin/scripts/droplang.c
M src/bin/scripts/reindexdb.c
M src/bin/scripts/vacuumdb.c
Introduce a psql "\connect -reuse-previous=on|off" option.
commit : f744e8906f7d029af2b9860469d8ebf77cb47e56
author : Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:46 -0400
committer: Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:46 -0400 The decision to reuse values of parameters from a previous connection
has been based on whether the new target is a conninfo string. Add this
means of overriding that default. This feature arose as one component
of a fix for security vulnerabilities in pg_dump, pg_dumpall, and
pg_upgrade, so back-patch to 9.1 (all supported versions). In 9.3 and
later, comment paragraphs that required update had already-incorrect
claims about behavior when no connection is open; fix those problems.
Security: CVE-2016-5424 M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/command.c
M src/bin/psql/startup.c
Sort out paired double quotes in \connect, \password and \crosstabview.
commit : 0cc3b12d284fb0e693abfd24e3950a19d3478380
author : Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:46 -0400
committer: Noah Misch <[email protected]>
date : Mon, 8 Aug 2016 10:07:46 -0400 In arguments, these meta-commands wrongly treated each pair as closing
the double quoted string. Make the behavior match the documentation.
This is a compatibility break, but I more expect to find software with
untested reliance on the documented behavior than software reliant on
today's behavior. Back-patch to 9.1 (all supported versions).
Reviewed by Tom Lane and Peter Eisentraut.
Security: CVE-2016-5424 M src/bin/psql/psqlscan.l
Release notes for 9.5.4, 9.4.9, 9.3.14, 9.2.18, 9.1.23.
commit : 22f9b3dd3d92fa3f8f250c3cca468e6c27ca2b34
author : Tom Lane <[email protected]>
date : Sun, 7 Aug 2016 21:31:02 -0400
committer: Tom Lane <[email protected]>
date : Sun, 7 Aug 2016 21:31:02 -0400 M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
Fix misestimation of n_distinct for a nearly-unique column with many nulls.
commit : 127d73009a6d8ea7c17c6fe55458a2bfcf6a1593
author : Tom Lane <[email protected]>
date : Sun, 7 Aug 2016 18:52:02 -0400
committer: Tom Lane <[email protected]>
date : Sun, 7 Aug 2016 18:52:02 -0400 If ANALYZE found no repeated non-null entries in its sample, it set the
column's stadistinct value to -1.0, intending to indicate that the entries
are all distinct. But what this value actually means is that the number
of distinct values is 100% of the table's rowcount, and thus it was
overestimating the number of distinct values by however many nulls there
are. This could lead to very poor selectivity estimates, as for example
in a recent report from Andreas Joseph Krogh. We should discount the
stadistinct value by whatever we've estimated the nulls fraction to be.
(That is what will happen if we choose to use a negative stadistinct for
a column that does have repeated entries, so this code path was just
inconsistent.)
In addition to fixing the stadistinct entries stored by several different
ANALYZE code paths, adjust the logic where get_variable_numdistinct()
forces an "all distinct" estimate on the basis of finding a relevant unique
index. Unique indexes don't reject nulls, so there's no reason to assume
that the null fraction doesn't apply.
Back-patch to all supported branches. Back-patching is a bit of a judgment
call, but this problem seems to affect only a few users (else we'd have
identified it long ago), and it's bad enough when it does happen that
destabilizing plan choices in a worse direction seems unlikely.
Patch by me, with documentation wording suggested by Dean Rasheed
Report: <VisenaEmail.26.df42f82acae38a58.156463942b8@tc7-visena>
Discussion: <[email protected]> M doc/src/sgml/catalogs.sgml
M src/backend/commands/analyze.c
M src/backend/tsearch/ts_typanalyze.c
M src/backend/utils/adt/selfuncs.c
M src/include/catalog/pg_statistic.h
Teach libpq to decode server version correctly from future servers.
commit : 3e40d9227f98088afcaf4f00c7025c465dad3551
author : Tom Lane <[email protected]>
date : Fri, 5 Aug 2016 18:58:12 -0400
committer: Tom Lane <[email protected]>
date : Fri, 5 Aug 2016 18:58:12 -0400 Beginning with the next development cycle, PG servers will report two-part
not three-part version numbers. Fix libpq so that it will compute the
correct numeric representation of such server versions for reporting by
PQserverVersion(). It's desirable to get this into the field and
back-patched ASAP, so that older clients are more likely to understand the
new server version numbering by the time any such servers are in the wild.
(The results with an old client would probably not be catastrophic anyway
for a released server; for example "10.1" would be interpreted as 100100
which would be wrong in detail but would not likely cause an old client to
misbehave badly. But "10devel" or "10beta1" would result in sversion==0
which at best would result in disabling all use of modern features.)
Extracted from a patch by Peter Eisentraut; comments added by me
Patch: <[email protected]> M src/interfaces/libpq/fe-exec.c
Update time zone data files to tzdata release 2016f.
commit : 7822792f74c404dd87a2cba4352de4640ef0893c
author : Tom Lane <[email protected]>
date : Fri, 5 Aug 2016 12:58:17 -0400
committer: Tom Lane <[email protected]>
date : Fri, 5 Aug 2016 12:58:17 -0400 DST law changes in Kemerovo and Novosibirsk. Historical corrections for
Azerbaijan, Belarus, and Morocco. Asia/Novokuznetsk and Asia/Novosibirsk
now use numeric time zone abbreviations instead of invented ones. Zones
for Antarctic bases and other locations that have been uninhabited for
portions of the time span known to the tzdata database now report "-00"
rather than "zzz" as the zone abbreviation for those time spans.
Also, I decided to remove some of the timezone/data/ files that we don't
use. At one time that subdirectory was a complete copy of what IANA
distributes in the tzdata tarballs, but that hasn't been true for a long
time. There seems no good reason to keep shipping those specific files
but not others; they're just bloating our tarballs. M src/timezone/data/africa
M src/timezone/data/antarctica
M src/timezone/data/asia
M src/timezone/data/australasia
M src/timezone/data/backzone
M src/timezone/data/europe
D src/timezone/data/iso3166.tab
D src/timezone/data/leapseconds
M src/timezone/data/northamerica
M src/timezone/data/southamerica
D src/timezone/data/yearistype.sh
D src/timezone/data/zone.tab
D src/timezone/data/zone1970.tab
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Default
doc: Remove documentation of nonexistent information schema columns
commit : 49afd5e9ddfcb0f69ce417f612b7bbb672db07d8
author : Peter Eisentraut <[email protected]>
date : Wed, 3 Aug 2016 13:45:55 -0400
committer: Peter Eisentraut <[email protected]>
date : Wed, 3 Aug 2016 13:45:55 -0400 These were probably copied in by accident.
From: Clément Prévost <[email protected]> M doc/src/sgml/information_schema.sgml
doc: OS collation changes can break indexes
commit : 0f2b9d9cce905941bb4c507167c993c0264caea9
author : Bruce Momjian <[email protected]>
date : Tue, 2 Aug 2016 17:13:10 -0400
committer: Bruce Momjian <[email protected]>
date : Tue, 2 Aug 2016 17:13:10 -0400 Discussion: [email protected]
Reviewed-by: Christoph Berg
Backpatch-through: 9.1 M doc/src/sgml/runtime.sgml
Fix pg_dump's handling of public schema with both -c and -C options.
commit : a5a7caaa1b5c6a00ee3fb891cd330cce862e33b7
author : Tom Lane <[email protected]>
date : Tue, 2 Aug 2016 12:48:51 -0400
committer: Tom Lane <[email protected]>
date : Tue, 2 Aug 2016 12:48:51 -0400 Since -c plus -C requests dropping and recreating the target database
as a whole, not dropping individual objects in it, we should assume that
the public schema already exists and need not be created. The previous
coding considered only the state of the -c option, so it would emit
"CREATE SCHEMA public" anyway, leading to an unexpected error in restore.
Back-patch to 9.2. Older versions did not accept -c with -C so the
issue doesn't arise there. (The logic being patched here dates to 8.0,
cf commit 2193121fa, so it's not really wrong that it didn't consider
the case at the time.)
Note that versions before 9.6 will still attempt to emit REVOKE/GRANT
on the public schema; but that happens without -c/-C too, and doesn't
seem to be the focus of this complaint. I considered extending this
stanza to also skip the public schema's ACL, but that would be a
misfeature, as it'd break cases where users intentionally changed that
ACL. The real fix for this aspect is Stephen Frost's work to not dump
built-in ACLs, and that's not going to get back-ported.
Per bugs #13804 and #14271. Solution found by David Johnston and later
rediscovered by me.
Report: <[email protected]>
Report: <[email protected]> M src/bin/pg_dump/pg_backup_archiver.c
Fixed array checking code for "unsigned long long" datatypes in libecpg.
commit : 295edbecf73eb479257077c4c70e36f55ee6d3ef
author : Michael Meskes <[email protected]>
date : Mon, 1 Aug 2016 06:36:27 +0200
committer: Michael Meskes <[email protected]>
date : Mon, 1 Aug 2016 06:36:27 +0200 M src/interfaces/ecpg/ecpglib/data.c
Fix pg_basebackup so that it accepts 0 as a valid compression level.
commit : a216177599928d409d90fe06678e1cc6fb2be234
author : Fujii Masao <[email protected]>
date : Mon, 1 Aug 2016 17:36:14 +0900
committer: Fujii Masao <[email protected]>
date : Mon, 1 Aug 2016 17:36:14 +0900 The help message for pg_basebackup specifies that the numbers 0 through 9
are accepted as valid values of -Z option. But, previously -Z 0 was rejected
as an invalid compression level.
Per discussion, it's better to make pg_basebackup treat 0 as valid
compression level meaning no compression, like pg_dump.
Back-patch to all supported versions.
Reported-By: Jeff Janes
Reviewed-By: Amit Kapila
Discussion: CAMkU=1x+GwjSayc57v6w87ij6iRGFWt=hVfM0B64b1_bPVKRqg@mail.gmail.com M doc/src/sgml/ref/pg_basebackup.sgml
M src/bin/pg_basebackup/pg_basebackup.c
Doc: remove claim that hash index creation depends on effective_cache_size.
commit : de818d4c735a0cffd172e111dc38c040d4cacead
author : Tom Lane <[email protected]>
date : Sun, 31 Jul 2016 18:32:34 -0400
committer: Tom Lane <[email protected]>
date : Sun, 31 Jul 2016 18:32:34 -0400 This text was added by commit ff213239c, and not long thereafter obsoleted
by commit 4adc2f72a (which made the test depend on NBuffers instead); but
nobody noticed the need for an update. Commit 9563d5b5e adds some further
dependency on maintenance_work_mem, but the existing verbiage seems to
cover that with about as much precision as we really want here. Let's
just take it all out rather than leaving ourselves open to more errors of
omission in future. (That solution makes this change back-patchable, too.)
Noted by Peter Geoghegan.
Discussion: <CAM3SWZRVANbj9GA9j40fAwheQCZQtSwqTN1GBTVwRrRbmSf7cg@mail.gmail.com> M doc/src/sgml/ref/create_index.sgml
doc: apply hypen fix that was not backpatched
commit : aea496cac1d61a382ec0e81e9681654f70c3e8c2
author : Bruce Momjian <[email protected]>
date : Sat, 30 Jul 2016 14:52:17 -0400
committer: Bruce Momjian <[email protected]>
date : Sat, 30 Jul 2016 14:52:17 -0400 Head patch was 42ec6c2da699e8e0b1774988fa97297a2cdf716c.
Reported-by: Alexander Law
Discussion: [email protected]
Backpatch-through: 9.1 M doc/src/sgml/runtime.sgml
Guard against empty buffer in gets_fromFile()'s check for a newline.
commit : 76c10ca318df0e7f2b2e2840ae496d7000d1ca37
author : Tom Lane <[email protected]>
date : Thu, 28 Jul 2016 18:57:24 -0400
committer: Tom Lane <[email protected]>
date : Thu, 28 Jul 2016 18:57:24 -0400 Per the fgets() specification, it cannot return without reading some data
unless it reports EOF or error. So the code here assumed that the data
buffer would necessarily be nonempty when we go to check for a newline
having been read. However, Agostino Sarubbo noticed that this could fail
to be true if the first byte of the data is a NUL (\0). The fgets() API
doesn't really work for embedded NULs, which is something I don't feel
any great need for us to worry about since we generally don't allow NULs
in SQL strings anyway. But we should not access off the end of our own
buffer if the case occurs. Normally this would just be a harmless read,
but if you were unlucky the byte before the buffer would contain '\n'
and we'd overwrite it with '\0', and if you were really unlucky that
might be valuable data and psql would crash.
Agostino reported this to pgsql-security, but after discussion we concluded
that it isn't worth treating as a security bug; if you can control the
input to psql you can do far more interesting things than just maybe-crash
it. Nonetheless, it is a bug, so back-patch to all supported versions. M src/bin/psql/input.c
Fix assorted fallout from IS [NOT] NULL patch.
commit : 7b8526e5d6e0a010d4461aa565ff4cc13c2dc447
author : Tom Lane <[email protected]>
date : Thu, 28 Jul 2016 16:09:15 -0400
committer: Tom Lane <[email protected]>
date : Thu, 28 Jul 2016 16:09:15 -0400 Commits 4452000f3 et al established semantics for NullTest.argisrow that
are a bit different from its initial conception: rather than being merely
a cache of whether we've determined the input to have composite type,
the flag now has the further meaning that we should apply field-by-field
testing as per the standard's definition of IS [NOT] NULL. If argisrow
is false and yet the input has composite type, the construct instead has
the semantics of IS [NOT] DISTINCT FROM NULL. Update the comments in
primnodes.h to clarify this, and fix ruleutils.c and deparse.c to print
such cases correctly. In the case of ruleutils.c, this merely results in
cosmetic changes in EXPLAIN output, since the case can't currently arise
in stored rules. However, it represents a live bug for deparse.c, which
would formerly have sent a remote query that had semantics different
from the local behavior. (From the user's standpoint, this means that
testing a remote nested-composite column for null-ness could have had
unexpected recursive behavior much like that fixed in 4452000f3.)
In a related but somewhat independent fix, make plancat.c set argisrow
to false in all NullTest expressions constructed to represent "attnotnull"
constructs. Since attnotnull is actually enforced as a simple null-value
check, this is a more accurate representation of the semantics; we were
previously overpromising what it meant for composite columns, which might
possibly lead to incorrect planner optimizations. (It seems that what the
SQL spec expects a NOT NULL constraint to mean is an IS NOT NULL test, so
arguably we are violating the spec and should fix attnotnull to do the
other thing. If we ever do, this part should get reverted.)
Back-patch, same as the previous commit.
Discussion: <[email protected]> M src/backend/optimizer/util/plancat.c
M src/backend/utils/adt/ruleutils.c
M src/include/nodes/primnodes.h
M src/test/regress/expected/rowtypes.out
Improve documentation about CREATE TABLE ... LIKE.
commit : a9a998180aa417b972a4502a4ed9c69c35a7e556
author : Tom Lane <[email protected]>
date : Thu, 28 Jul 2016 13:26:59 -0400
committer: Tom Lane <[email protected]>
date : Thu, 28 Jul 2016 13:26:59 -0400 The docs failed to explain that LIKE INCLUDING INDEXES would not preserve
the names of indexes and associated constraints. Also, it wasn't mentioned
that EXCLUDE constraints would be copied by this option. The latter
oversight seems enough of a documentation bug to justify back-patching.
In passing, do some minor copy-editing in the same area, and add an entry
for LIKE under "Compatibility", since it's not exactly a faithful
implementation of the standard's feature.
Discussion: <[email protected]> M doc/src/sgml/ref/create_table.sgml
M src/backend/parser/parse_utilcmd.c
Register atexit hook only once in pg_upgrade.
commit : 737f25cfedf05884c6ffa468b4e1024b5bcc3b81
author : Tom Lane <[email protected]>
date : Thu, 28 Jul 2016 11:39:11 -0400
committer: Tom Lane <[email protected]>
date : Thu, 28 Jul 2016 11:39:11 -0400 start_postmaster() registered stop_postmaster_atexit as an atexit(3)
callback each time through, although the obvious intention was to do
so only once per program run. The extra registrations were harmless,
so long as we didn't exceed ATEXIT_MAX, but still it's a bug.
Artur Zakirov, with bikeshedding by Kyotaro Horiguchi and me
Discussion: <[email protected]> M contrib/pg_upgrade/server.c
Fix incorrect description of udt_privileges view in documentation.
commit : 5e50a6718ac523be2fd9265463ecbbf21da43f25
author : Fujii Masao <[email protected]>
date : Thu, 28 Jul 2016 22:34:42 +0900
committer: Fujii Masao <[email protected]>
date : Thu, 28 Jul 2016 22:34:42 +0900 The description of udt_privileges view contained an incorrect copy-pasted word.
Back-patch to 9.2 where udt_privileges view was added.
Author: Alexander Law M doc/src/sgml/information_schema.sgml
Fix constant-folding of ROW(...) IS [NOT] NULL with composite fields.
commit : bcdd8a19490974f73a2473d3a3cece8d3558d676
author : Tom Lane <[email protected]>
date : Tue, 26 Jul 2016 15:25:02 -0400
committer: Tom Lane <[email protected]>
date : Tue, 26 Jul 2016 15:25:02 -0400 The SQL standard appears to specify that IS [NOT] NULL's tests of field
nullness are non-recursive, ie, we shouldn't consider that a composite
field with value ROW(NULL,NULL) is null for this purpose.
ExecEvalNullTest got this right, but eval_const_expressions did not,
leading to weird inconsistencies depending on whether the expression
was such that the planner could apply constant folding.
Also, adjust the docs to mention that IS [NOT] DISTINCT FROM NULL can be
used as a substitute test if a simple null check is wanted for a rowtype
argument. That motivated reordering things so that IS [NOT] DISTINCT FROM
is described before IS [NOT] NULL. In HEAD, I went a bit further and added
a table showing all the comparison-related predicates.
Per bug #14235. Back-patch to all supported branches, since it's certainly
undesirable that constant-folding should change the semantics.
Report and patch by Andrew Gierth; assorted wordsmithing and revised
regression test cases by me.
Report: <[email protected]> M doc/src/sgml/func.sgml
M src/backend/executor/execQual.c
M src/backend/optimizer/util/clauses.c
M src/test/regress/expected/rowtypes.out
M src/test/regress/sql/rowtypes.sql
Make the AIX case of Makefile.shlib safe for parallel make.
commit : a4daf59eef9845a93c73056f6983b375c2a41fe9
author : Noah Misch <[email protected]>
date : Sat, 23 Jul 2016 20:30:03 -0400
committer: Noah Misch <[email protected]>
date : Sat, 23 Jul 2016 20:30:03 -0400 Use our typical approach, from src/backend/parser. Back-patch to 9.1
(all supported versions). M src/Makefile.shlib
Make contrib regression tests safe for Danish locale.
commit : a1e75055368e28985cec9cc2c6fc133f4e144da2
author : Tom Lane <[email protected]>
date : Thu, 21 Jul 2016 16:52:36 -0400
committer: Tom Lane <[email protected]>
date : Thu, 21 Jul 2016 16:52:36 -0400 In btree_gin and citext, avoid some not-particularly-interesting
dependencies on the sorting of 'aa'. In tsearch2, use COLLATE "C" to
remove an uninteresting dependency on locale sort order (and thereby
allow removal of a variant expected-file).
Also, in citext, avoid assuming that lower('I') = 'i'. This isn't relevant
to Danish but it does fail in Turkish. M contrib/btree_gin/expected/bytea.out
M contrib/btree_gin/expected/text.out
M contrib/btree_gin/expected/varchar.out
M contrib/btree_gin/sql/bytea.sql
M contrib/btree_gin/sql/text.sql
M contrib/btree_gin/sql/varchar.sql
M contrib/citext/expected/citext.out
M contrib/citext/expected/citext_1.out
M contrib/citext/sql/citext.sql
M contrib/tsearch2/expected/tsearch2.out
D contrib/tsearch2/expected/tsearch2_1.out
M contrib/tsearch2/sql/tsearch2.sql
Make pltcl regression tests safe for Danish locale.
commit : 52502e7a599f1ad013a88da226387a02de5d9639
author : Tom Lane <[email protected]>
date : Thu, 21 Jul 2016 14:24:07 -0400
committer: Tom Lane <[email protected]>
date : Thu, 21 Jul 2016 14:24:07 -0400 Another peculiarity of Danish locale is that it has an unusual idea
of how to sort upper vs. lower case. One of the pltcl test cases has
an issue with that. Now that COLLATE works in all supported branches,
we can just change the test to be locale-independent, and get rid of
the variant expected file that used to support non-C locales. M src/pl/tcl/expected/pltcl_queries.out
D src/pl/tcl/expected/pltcl_queries_1.out
M src/pl/tcl/sql/pltcl_queries.sql
Fix MSVC build for changes in zic.
commit : 4d37b7cffcfc5468c5a17cf41d96372b36dab1ad
author : Tom Lane <[email protected]>
date : Tue, 19 Jul 2016 17:53:31 -0400
committer: Tom Lane <[email protected]>
date : Tue, 19 Jul 2016 17:53:31 -0400 Ooops, I missed back-patching commit f5f15ea6a along with the other stuff. M src/tools/msvc/Mkvcbuild.pm
Sync back-branch copies of the timezone code with IANA release tzcode2016c.
commit : cd951aa614530ce562f47ca78120fc2bf5b58ba9
author : Tom Lane <[email protected]>
date : Tue, 19 Jul 2016 15:59:36 -0400
committer: Tom Lane <[email protected]>
date : Tue, 19 Jul 2016 15:59:36 -0400 Back-patch commit 1c1a7cbd6a1600c9, along with subsequent portability
fixes, into all active branches. Also, back-patch commits 696027727 and
596857043 (addition of zic -P option) into 9.1 and 9.2, just to reduce
differences between the branches. src/timezone/ is now largely identical
in all active branches, except that in 9.1, pgtz.c retains the
initial-timezone-selection code that was moved over to initdb in 9.2.
Ordinarily we wouldn't risk this much code churn in back branches, but it
seems necessary in this case, because among the changes are two feature
additions in the "zic" zone data file compiler (a larger limit on the
number of allowed DST transitions, and addition of a "%z" escape in zone
abbreviations). IANA have not yet started to use those features in their
tzdata files, but presumably they will before too long. If we don't update
then we'll be unable to adopt new timezone data. Also, installations built
with --with-system-tzdata (which includes most distro-supplied builds, I
believe) might fail even if we don't update our copies of the data files.
There are assorted bug fixes too, mostly affecting obscure timezones or
post-2037 dates.
Discussion: <[email protected]> M src/bin/initdb/findtimezone.c
M src/timezone/.gitignore
M src/timezone/Makefile
M src/timezone/README
D src/timezone/ialloc.c
M src/timezone/localtime.c
M src/timezone/pgtz.c
M src/timezone/pgtz.h
M src/timezone/private.h
D src/timezone/scheck.c
M src/timezone/strftime.c
M src/timezone/tzfile.h
M src/timezone/zic.c
Use correct symbol for minimum int64 value
commit : 6c0be49b2ab7a673656d385ba09fc0c1657c6e33
author : Peter Eisentraut <[email protected]>
date : Sun, 17 Jul 2016 09:37:33 -0400
committer: Peter Eisentraut <[email protected]>
date : Sun, 17 Jul 2016 09:37:33 -0400 The old code used SEQ_MINVALUE to get the smallest int64 value. This
was done as a convenience to avoid having to deal with INT64_IS_BUSTED,
but that is obsolete now. Also, it is incorrect because the smallest
int64 value is actually SEQ_MINVALUE-1. Fix by writing out the constant
the long way, as it is done elsewhere in the code. M contrib/btree_gin/btree_gin.c
Fix crash in close_ps() for NaN input coordinates.
commit : 89b301104a6c5522bb9dc91565ac0e2cb5f4ddb4
author : Tom Lane <[email protected]>
date : Sat, 16 Jul 2016 14:42:37 -0400
committer: Tom Lane <[email protected]>
date : Sat, 16 Jul 2016 14:42:37 -0400 The Assert() here seems unreasonably optimistic. Andreas Seltenreich
found that it could fail with NaNs in the input geometries, and it
seems likely to me that it might fail in corner cases due to roundoff
error, even for ordinary input values. As a band-aid, make the function
return SQL NULL instead of crashing.
Report: <[email protected]> M src/backend/utils/adt/geo_ops.c
Fix torn-page, unlogged xid and further risks from heap_update().
commit : 941557f18b611bd2295aa159e790a53d6ffd31dd
author : Andres Freund <[email protected]>
date : Fri, 15 Jul 2016 17:49:48 -0700
committer: Andres Freund <[email protected]>
date : Fri, 15 Jul 2016 17:49:48 -0700 When heap_update needs to look for a page for the new tuple version,
because the current one doesn't have sufficient free space, or when
columns have to be processed by the tuple toaster, it has to release the
lock on the old page during that. Otherwise there'd be lock ordering and
lock nesting issues.
To avoid concurrent sessions from trying to update / delete / lock the
tuple while the page's content lock is released, the tuple's xmax is set
to the current session's xid.
That unfortunately was done without any WAL logging, thereby violating
the rule that no XIDs may appear on disk, without an according WAL
record. If the database were to crash / fail over when the page level
lock is released, and some activity lead to the page being written out
to disk, the xid could end up being reused; potentially leading to the
row becoming invisible.
There might be additional risks by not having t_ctid point at the tuple
itself, without having set the appropriate lock infomask fields.
To fix, compute the appropriate xmax/infomask combination for locking
the tuple, and perform WAL logging using the existing XLOG_HEAP_LOCK
record. That allows the fix to be backpatched.
This issue has existed for a long time. There appears to have been
partial attempts at preventing dangers, but these never have fully been
implemented, and were removed a long time ago, in
11919160 (cf. HEAP_XMAX_UNLOGGED).
In master / 9.6, there's an additional issue, namely that the
visibilitymap's freeze bit isn't reset at that point yet. Since that's a
new issue, introduced only in a892234f830, that'll be fixed in a
separate commit.
Author: Masahiko Sawada and Andres Freund
Reported-By: Different aspects by Thomas Munro, Noah Misch, and others
Discussion: CAEepm=3fWAbWryVW9swHyLTY4sXVf0xbLvXqOwUoDiNCx9mBjQ@mail.gmail.com
Backpatch: 9.1/all supported versions M src/backend/access/heap/heapam.c
doc: Fix typos
commit : 544ea9d7e0839695c3a796d3529fec92d503abb1
author : Peter Eisentraut <[email protected]>
date : Thu, 14 Jul 2016 22:28:03 -0400
committer: Peter Eisentraut <[email protected]>
date : Thu, 14 Jul 2016 22:28:03 -0400 From: Alexander Law <[email protected]> M doc/src/sgml/btree-gist.sgml
M doc/src/sgml/sepgsql.sgml
Fix GiST index build for NaN values in geometric types.
commit : 042009f2441cea6ef0a01c3880a806e172629fbf
author : Tom Lane <[email protected]>
date : Thu, 14 Jul 2016 18:46:00 -0400
committer: Tom Lane <[email protected]>
date : Thu, 14 Jul 2016 18:46:00 -0400 GiST index build could go into an infinite loop when presented with boxes
(or points, circles or polygons) containing NaN component values. This
happened essentially because the code assumed that x == x is true for any
"double" value x; but it's not true for NaNs. The looping behavior was not
the only problem though: we also attempted to sort the items using simple
double comparisons. Since NaNs violate the trichotomy law, qsort could
(in principle at least) get arbitrarily confused and mess up the sorting of
ordinary values as well as NaNs. And we based splitting choices on box size
calculations that could produce NaNs, again resulting in undesirable
behavior.
To fix, replace all comparisons of doubles in this logic with
float8_cmp_internal, which is NaN-aware and is careful to sort NaNs
consistently, higher than any non-NaN. Also rearrange the box size
calculation to not produce NaNs; instead it should produce an infinity
for a box with NaN on one side and not-NaN on the other.
I don't by any means claim that this solves all problems with NaNs in
geometric values, but it should at least make GiST index insertion work
reliably with such data. It's likely that the index search side of things
still needs some work, and probably regular geometric operations too.
But with this patch we're laying down a convention for how such cases
ought to behave.
Per bug #14238 from Guang-Dih Lei. Back-patch to 9.2; the code used before
commit 7f3bd86843e5aad8 is quite different and doesn't lock up on my simple
test case, nor on the submitter's dataset.
Report: <[email protected]>
Discussion: <[email protected]> M src/backend/access/gist/gistproc.c
M src/backend/utils/adt/float.c
M src/include/utils/builtins.h
doc: Update URL for PL/PHP
commit : e1cbe5c962b278803d4c19a40109b7959aacee14
author : Peter Eisentraut <[email protected]>
date : Mon, 11 Jul 2016 12:13:36 -0400
committer: Peter Eisentraut <[email protected]>
date : Mon, 11 Jul 2016 12:13:36 -0400 M doc/src/sgml/external-projects.sgml
Fix TAP tests and MSVC scripts for pathnames with spaces.
commit : fdf2ee62e6365b2da3a288a90f1607d4ce5caf92
author : Tom Lane <[email protected]>
date : Mon, 11 Jul 2016 11:24:04 -0400
committer: Tom Lane <[email protected]>
date : Mon, 11 Jul 2016 11:24:04 -0400 Back-patch relevant parts of commit 30b2731bd into 9.1-9.3.
Michael Paquier, Kyotaro Horiguchi
Discussion: <[email protected]> M src/tools/msvc/Install.pm
M src/tools/msvc/vcregress.pl
doc: mention dependency on collation libraries
commit : cfb33bc33a233c77571e007102bc4242e402762a
author : Bruce Momjian <[email protected]>
date : Sat, 2 Jul 2016 11:22:35 -0400
committer: Bruce Momjian <[email protected]>
date : Sat, 2 Jul 2016 11:22:35 -0400 Document that index storage is dependent on the operating system's
collation library ordering, and any change in that ordering can create
invalid indexes.
Discussion: [email protected]
Backpatch-through: 9.1 M doc/src/sgml/runtime.sgml
Make "postgres -C guc" print "" not "(null)" for null-valued GUCs.
commit : dd41661d2c613c3e4f8328191758398bfbcbd598
author : Tom Lane <[email protected]>
date : Wed, 22 Jun 2016 11:55:18 -0400
committer: Tom Lane <[email protected]>
date : Wed, 22 Jun 2016 11:55:18 -0400 Commit 0b0baf262 et al made this case print "(null)" on the grounds that
that's what happened on platforms that didn't crash. But neither behavior
was actually intentional. What we should print is just an empty string,
for compatibility with the behavior of SHOW and other ways of examining
string GUCs. Those code paths don't distinguish NULL from empty strings,
so we should not here either. Per gripe from Alain Radix.
Like the previous patch, back-patch to 9.2 where -C option was introduced.
Discussion: <CA+YdpwxPUADrmxSD7+Td=uOshMB1KkDN7G7cf+FGmNjjxMhjbw@mail.gmail.com> M src/backend/postmaster/postmaster.c
Document that dependency tracking doesn't consider function bodies.
commit : 85743887e847b187bb16ec1f0ca3b967bc124223
author : Tom Lane <[email protected]>
date : Tue, 21 Jun 2016 20:07:58 -0400
committer: Tom Lane <[email protected]>
date : Tue, 21 Jun 2016 20:07:58 -0400 If there's anyplace in our SGML docs that explains this behavior, I can't
find it right at the moment. Add an explanation in "Dependency Tracking"
which seems like the authoritative place for such a discussion. Per
gripe from Michelle Schwan.
While at it, update this section's example of a dependency-related
error message: they last looked like that in 8.3. And remove the
explanation of dependency updates from pre-7.3 installations, which
is probably no longer worth anybody's brain cells to read.
The bogus error message example seems like an actual documentation bug,
so back-patch to all supported branches.
Discussion: <[email protected]> M doc/src/sgml/ddl.sgml
Docs: improve description of psql's %R prompt escape sequence.
commit : 09e592b3935d0ce2970cdebdd4c6bb7d7ac9c28e
author : Tom Lane <[email protected]>
date : Sun, 19 Jun 2016 13:11:40 -0400
committer: Tom Lane <[email protected]>
date : Sun, 19 Jun 2016 13:11:40 -0400 Dilian Palauzov pointed out in bug #14201 that the docs failed to mention
the possibility of %R producing '(' due to an unmatched parenthesis.
He proposed just adding that in the same style as the other options were
listed; but it seemed to me that the sentence was already nearly
unintelligible, so I rewrote it a bit more extensively.
Report: <[email protected]> M doc/src/sgml/ref/psql-ref.sgml
Fix validation of overly-long IPv6 addresses.
commit : f66e0fec386754e85edb3355b1d000c99a38f5cb
author : Tom Lane <[email protected]>
date : Thu, 16 Jun 2016 17:16:32 -0400
committer: Tom Lane <[email protected]>
date : Thu, 16 Jun 2016 17:16:32 -0400 The inet/cidr types sometimes failed to reject IPv6 inputs with too many
colon-separated fields, instead translating them to '::/0'. This is the
result of a thinko in the original ISC code that seems to be as yet
unreported elsewhere. Per bug #14198 from Stefan Kaltenbrunner.
Report: <[email protected]> M src/backend/utils/adt/inet_net_pton.c
Avoid crash in "postgres -C guc" for a GUC with a null string value.
commit : 23ed284a5dda5286bd91bb601f30e5e6fae478af
author : Tom Lane <[email protected]>
date : Thu, 16 Jun 2016 12:17:03 -0400
committer: Tom Lane <[email protected]>
date : Thu, 16 Jun 2016 12:17:03 -0400 Emit "(null)" instead, which was the behavior all along on platforms
that don't crash, eg OS X. Per report from Jehan-Guillaume de Rorthais.
Back-patch to 9.2 where -C option was introduced.
Michael Paquier
Report: <20160615204036.2d35d86a@firost> M src/backend/postmaster/postmaster.c
Fix multiple minor infelicities in aclchk.c error reports.
commit : cd05539ec7f5eba2c1370447f27d2343c96bbeee
author : Tom Lane <[email protected]>
date : Mon, 13 Jun 2016 13:53:10 -0400
committer: Tom Lane <[email protected]>
date : Mon, 13 Jun 2016 13:53:10 -0400 pg_type_aclmask reported the wrong type's OID when complaining that
it could not find a type's typelem. It also failed to provide a
suitable errcode when the initially given OID doesn't exist (which
is a user-facing error, since that OID can be user-specified).
pg_foreign_data_wrapper_aclmask and pg_foreign_server_aclmask likewise
lacked errcode specifications. Trivial cosmetic adjustments too.
The wrong-type-OID problem was reported by Petru-Florin Mihancea in
bug #14186; the other issues noted by me while reading the code.
These errors all seem to be aboriginal in the respective routines, so
back-patch as necessary.
Report: <[email protected]> M src/backend/catalog/aclchk.c
Clarify documentation of ceil/ceiling/floor functions.
commit : a36c8219df2b3b93916bc5256df03e076c3615c6
author : Tom Lane <[email protected]>
date : Thu, 9 Jun 2016 11:58:00 -0400
committer: Tom Lane <[email protected]>
date : Thu, 9 Jun 2016 11:58:00 -0400 Document these as "nearest integer >= argument" and "nearest integer <=
argument", which will hopefully be less confusing than the old formulation.
New wording is from Matlab via Dean Rasheed.
I changed the pg_description entries as well as the SGML docs. In the
back branches, this will only affect installations initdb'd in the future,
but it should be harmless otherwise.
Discussion: <CAEZATCW3yzJo-NMSiQs5jXNFbTsCEftZS-Og8=FvFdiU+kYuSA@mail.gmail.com> M doc/src/sgml/func.sgml
M src/include/catalog/pg_proc.h
nls-global.mk: search build dir for source files, too
commit : 3dcdf9800be99a9b2409115c8aa542b234aa324f
author : Alvaro Herrera <[email protected]>
date : Tue, 7 Jun 2016 18:55:18 -0400
committer: Alvaro Herrera <[email protected]>
date : Tue, 7 Jun 2016 18:55:18 -0400 In VPATH builds, the build directory was not being searched for files in
GETTEXT_FILES, leading to failure to construct the .pot files. This has
bit me all along, but never hard enough to get it fixed; I suppose not a
lot of people uses VPATH and NLS-enabled builds, and those that do,
don't do "make update-po" often.
This is a longstanding problem, so backpatch all the way back. M src/nls-global.mk
Don't reset changes_since_analyze after a selective-columns ANALYZE.
commit : 3201709de3a552113573f73d308b40bba8f73186
author : Tom Lane <[email protected]>
date : Mon, 6 Jun 2016 17:44:18 -0400
committer: Tom Lane <[email protected]>
date : Mon, 6 Jun 2016 17:44:18 -0400 If we ANALYZE only selected columns of a table, we should not postpone
auto-analyze because of that; other columns may well still need stats
updates. As committed, the counter is left alone if a column list is
given, whether or not it includes all analyzable columns of the table.
Per complaint from Tomasz Ostrowski.
It's been like this a long time, so back-patch to all supported branches.
Report: <[email protected]> M src/backend/commands/analyze.c
M src/backend/postmaster/pgstat.c
M src/include/pgstat.h
Avoid hot standby cancels from VAC FREEZE
commit : 294509ea9bb3305230659fd76bd355aec6fcd039
author : Alvaro Herrera <[email protected]>
date : Wed, 25 May 2016 19:39:49 -0400
committer: Alvaro Herrera <[email protected]>
date : Wed, 25 May 2016 19:39:49 -0400 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.
Analysis and report by Marco Nenciarini
Bug fix by Simon Riggs
This is a correct backpatch of commit 66fbcb0d2e to branches 9.1 through
9.4. That commit was backpatched to 9.0 originally, but it was
immediately reverted in 9.0-9.4 because it didn't compile. M src/backend/access/heap/heapam.c
Fetch XIDs atomically during vac_truncate_clog().
commit : 4cf0978ea2733548149ee7f11e588975daaf7609
author : Tom Lane <[email protected]>
date : Tue, 24 May 2016 15:47:51 -0400
committer: Tom Lane <[email protected]>
date : Tue, 24 May 2016 15:47:51 -0400 Because vac_update_datfrozenxid() updates datfrozenxid and datminmxid
in-place, it's unsafe to assume that successive reads of those values will
give consistent results. Fetch each one just once to ensure sane behavior
in the minimum calculation. Noted while reviewing Alexander Korotkov's
patch in the same area.
Discussion: <[email protected]> M src/backend/commands/vacuum.c
Avoid consuming an XID during vac_truncate_clog().
commit : 2e7f0c34aa6dd2f4c02f57d9dd5c37eeeb661198
author : Tom Lane <[email protected]>
date : Tue, 24 May 2016 15:20:12 -0400
committer: Tom Lane <[email protected]>
date : Tue, 24 May 2016 15:20:12 -0400 vac_truncate_clog() uses its own transaction ID as the comparison point in
a sanity check that no database's datfrozenxid has already wrapped around
"into the future". That was probably fine when written, but in a lazy
vacuum we won't have assigned an XID, so calling GetCurrentTransactionId()
causes an XID to be assigned when otherwise one would not be. Most of the
time that's not a big problem ... but if we are hard up against the
wraparound limit, consuming XIDs during antiwraparound vacuums is a very
bad thing.
Instead, use ReadNewTransactionId(), which not only avoids this problem
but is in itself a better comparison point to test whether wraparound
has already occurred.
Report and patch by Alexander Korotkov. Back-patch to all versions.
Report: <CAPpHfdspOkmiQsxh-UZw2chM6dRMwXAJGEmmbmqYR=yvM7-s6A@mail.gmail.com> M src/backend/commands/vacuum.c
Fix latent crash in do_text_output_multiline().
commit : fca2eb3d43226cb119b682fda7716c5a4c28a841
author : Tom Lane <[email protected]>
date : Mon, 23 May 2016 14:16:41 -0400
committer: Tom Lane <[email protected]>
date : Mon, 23 May 2016 14:16:41 -0400 do_text_output_multiline() would fail (typically with a null pointer
dereference crash) if its input string did not end with a newline. Such
cases do not arise in our current sources; but it certainly could happen
in future, or in extension code's usage of the function, so we should fix
it. To fix, replace "eol += len" with "eol = text + len".
While at it, make two cosmetic improvements: mark the input string const,
and rename the argument from "text" to "txt" to dodge pgindent strangeness
(since "text" is a typedef name).
Even though this problem is only latent at present, it seems like a good
idea to back-patch the fix, since it's a very simple/safe patch and it's
not out of the realm of possibility that we might in future back-patch
something that expects sane behavior from do_text_output_multiline().
Per report from Hao Lee.
Report: <CAGoxFiFPAGyPAJLcFxTB5cGhTW2yOVBDYeqDugYwV4dEd1L_Ag@mail.gmail.com> M src/backend/executor/execTuples.c
M src/include/executor/executor.h
Further improve documentation about --quote-all-identifiers switch.
commit : ae52f3bb5183fdbd7c2e449d38c803e01ba6831b
author : Tom Lane <[email protected]>
date : Fri, 20 May 2016 15:51:57 -0400
committer: Tom Lane <[email protected]>
date : Fri, 20 May 2016 15:51:57 -0400 Mention it in the Notes section too, per suggestion from David Johnston.
Discussion: <[email protected]> M doc/src/sgml/ref/pg_dump.sgml
Improve documentation about pg_dump's --quote-all-identifiers switch.
commit : b215c624ebf00225b955c1ebafdf6be1b96d63a8
author : Tom Lane <[email protected]>
date : Fri, 20 May 2016 14:59:48 -0400
committer: Tom Lane <[email protected]>
date : Fri, 20 May 2016 14:59:48 -0400 Per bug #14152 from Alejandro Martínez. Back-patch to all supported
branches.
Discussion: <[email protected]> M doc/src/sgml/ref/pg_dump.sgml
M doc/src/sgml/ref/pg_dumpall.sgml
doc: Fix typo
commit : 8e6d6a72257f7ae2e7b6b53b8857c2e3c0c52af7
author : Peter Eisentraut <[email protected]>
date : Fri, 13 May 2016 21:24:13 -0400
committer: Peter Eisentraut <[email protected]>
date : Fri, 13 May 2016 21:24:13 -0400 From: Alexander Law <[email protected]> M doc/src/sgml/gin.sgml
Ensure plan stability in contrib/btree_gist regression test.
commit : b15ab18ed7e30d2e404f385c3b59d7b3768b141b
author : Tom Lane <[email protected]>
date : Thu, 12 May 2016 20:04:12 -0400
committer: Tom Lane <[email protected]>
date : Thu, 12 May 2016 20:04:12 -0400 Buildfarm member skink failed with symptoms suggesting that an
auto-analyze had happened and changed the plan displayed for a
test query. Although this is evidently of low probability,
regression tests that sometimes fail are no fun, so add commands
to force a bitmap scan to be chosen. M contrib/btree_gist/expected/not_equal.out
M contrib/btree_gist/sql/not_equal.sql
Fix autovacuum for shared relations
commit : ca4c6d043ffa6233d4cc47ef2e117e2e52a79e11
author : Alvaro Herrera <[email protected]>
date : Tue, 10 May 2016 16:23:54 -0300
committer: Alvaro Herrera <[email protected]>
date : Tue, 10 May 2016 16:23:54 -0300 The table-skipping logic in autovacuum would fail to consider that
multiple workers could be processing the same shared catalog in
different databases. This normally wouldn't be a problem: firstly
because autovacuum workers not for wraparound would simply ignore tables
in which they cannot acquire lock, and secondly because most of the time
these tables are small enough that even if multiple for-wraparound
workers are stuck in the same catalog, they would be over pretty
quickly. But in cases where the catalogs are severely bloated it could
become a problem.
Backpatch all the way back, because the problem has been there since the
beginning.
Reported by Ondřej Světlík
Discussion: https://www.postgresql.org/message-id/572B63B1.3030603%40flexibee.eu
https://www.postgresql.org/message-id/572A1072.5080308%40flexibee.eu M src/backend/postmaster/autovacuum.c