Stamp 9.3.17.
commit : 57811b751a8f6cc3e7fce01e4944e556ae4578af
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2017 17:20:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2017 17:20:54 -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
Further patch rangetypes_selfuncs.c's statistics slot management.
commit : 417c9ce2695ec0f716eeff30013979587313bdc1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2017 15:02:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2017 15:02:58 -0400
Values in a STATISTIC_KIND_RANGE_LENGTH_HISTOGRAM slot are float8,
not of the type of the column the statistics are for.
This bug is at least partly the fault of sloppy specification comments
for get_attstatsslot()/free_attstatsslot(): the type OID they want is that
of the stavalues entries, not of the underlying column. (I double-checked
other callers and they seem to get this right.) Adjust the comments to be
more correct.
Per buildfarm.
Security: CVE-2017-7484
M src/backend/utils/adt/rangetypes_selfuncs.c
M src/backend/utils/cache/lsyscache.c
M src/include/catalog/pg_statistic.h
Last-minute updates for release notes.
commit : 73b1aee886a211b0438aa3fe4bcded7fd671c1e4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2017 12:57:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2017 12:57:28 -0400
Security: CVE-2017-7484, CVE-2017-7485, CVE-2017-7486
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
Fix possibly-uninitialized variable.
commit : 703da179505e8bac2aa8ebdc600402338cc0f226
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2017 11:18:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2017 11:18:40 -0400
Oversight in e2d4ef8de et al (my fault not Peter's). Per buildfarm.
Security: CVE-2017-7484
M src/backend/utils/adt/rangetypes_selfuncs.c
Match pg_user_mappings limits to information_schema.user_mapping_options.
commit : b5b124046c0dc636d73c4a802bc731431dfd9dba
author : Noah Misch <noah@leadboat.com>
date : Mon, 8 May 2017 07:24:24 -0700
committer: Noah Misch <noah@leadboat.com>
date : Mon, 8 May 2017 07:24:24 -0700
Both views replace the umoptions field with NULL when the user does not
meet qualifications to see it. They used different qualifications, and
pg_user_mappings documented qualifications did not match its implemented
qualifications. Make its documentation and implementation match those
of user_mapping_options. One might argue for stronger qualifications,
but these have long, documented tenure. pg_user_mappings has always
exhibited this problem, so back-patch to 9.2 (all supported versions).
Michael Paquier and Feike Steenbergen. Reviewed by Jeff Janes.
Reported by Andrew Wheelwright.
Security: CVE-2017-7486
M doc/src/sgml/catalogs.sgml
M src/backend/catalog/system_views.sql
M src/test/regress/expected/foreign_data.out
M src/test/regress/expected/rules.out
M src/test/regress/sql/foreign_data.sql
Restore PGREQUIRESSL recognition in libpq.
commit : 3eab8112754c484c192248afe64055d40a231f7b
author : Noah Misch <noah@leadboat.com>
date : Mon, 8 May 2017 07:24:24 -0700
committer: Noah Misch <noah@leadboat.com>
date : Mon, 8 May 2017 07:24:24 -0700
Commit 65c3bf19fd3e1f6a591618e92eb4c54d0b217564 moved handling of the,
already then, deprecated requiressl parameter into conninfo_storeval().
The default PGREQUIRESSL environment variable was however lost in the
change resulting in a potentially silent accept of a non-SSL connection
even when set. Its documentation remained. Restore its implementation.
Also amend the documentation to mark PGREQUIRESSL as deprecated for
those not following the link to requiressl. Back-patch to 9.3, where
commit 65c3bf1 first appeared.
Behavior has been more complex when the user provides both deprecated
and non-deprecated settings. Before commit 65c3bf1, libpq operated
according to the first of these found:
requiressl=1
PGREQUIRESSL=1
sslmode=*
PGSSLMODE=*
(Note requiressl=0 didn't override sslmode=*; it would only suppress
PGREQUIRESSL=1 or a previous requiressl=1. PGREQUIRESSL=0 had no effect
whatsoever.) Starting with commit 65c3bf1, libpq ignored PGREQUIRESSL,
and order of precedence changed to this:
last of requiressl=* or sslmode=*
PGSSLMODE=*
Starting now, adopt the following order of precedence:
last of requiressl=* or sslmode=*
PGSSLMODE=*
PGREQUIRESSL=1
This retains the 65c3bf1 behavior for connection strings that contain
both requiressl=* and sslmode=*. It retains the 65c3bf1 change that
either connection string option overrides both environment variables.
For the first time, PGSSLMODE has precedence over PGREQUIRESSL; this
avoids reducing security of "PGREQUIRESSL=1 PGSSLMODE=verify-full"
configurations originating under v9.3 and later.
Daniel Gustafsson
Security: CVE-2017-7485
M doc/src/sgml/libpq.sgml
M src/interfaces/libpq/fe-connect.c
Translation updates
commit : e2a20e484501c79cf9e0b981f08be15f2c476b2c
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 8 May 2017 10:19:36 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 8 May 2017 10:19:36 -0400
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: d66b118dd9f43b2e9be85a5138dc2be30acb5532
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/it.po
M src/backend/po/ru.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_controldata/po/it.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/it.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetxlog/po/ru.po
M src/bin/psql/po/it.po
M src/interfaces/ecpg/preproc/po/it.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/it.po
M src/pl/plpython/po/fr.po
M src/pl/plpython/po/it.po
M src/pl/plpython/po/ru.po
Add security checks to selectivity estimation functions
commit : 4f1b2089a1b8f82cbd28b4cd8d0e1e9f1486d2b6
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 5 May 2017 12:18:48 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 5 May 2017 12:18:48 -0400
Some selectivity estimation functions run user-supplied operators over
data obtained from pg_statistic without security checks, which allows
those operators to leak pg_statistic data without having privileges on
the underlying tables. Fix by checking that one of the following is
satisfied: (1) the user has table or column privileges on the table
underlying the pg_statistic data, or (2) the function implementing the
user-supplied operator is leak-proof. If neither is satisfied, planning
will proceed as if there are no statistics available.
At least one of these is satisfied in most cases in practice. The only
situations that are negatively impacted are user-defined or
not-leak-proof operators on a security-barrier view.
Reported-by: Robert Haas <robertmhaas@gmail.com>
Author: Peter Eisentraut <peter_e@gmx.net>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Security: CVE-2017-7484
M doc/src/sgml/planstats.sgml
M src/backend/utils/adt/array_selfuncs.c
M src/backend/utils/adt/rangetypes_selfuncs.c
M src/backend/utils/adt/selfuncs.c
M src/include/utils/selfuncs.h
M src/test/regress/expected/privileges.out
M src/test/regress/sql/privileges.sql
Release notes for 9.6.3, 9.5.7, 9.4.12, 9.3.17, 9.2.21.
commit : e2dd4337403edf9b2d69d598ea373b6de969b186
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 May 2017 16:56:03 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 May 2017 16:56:03 -0400
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
Guard against null t->tm_zone in strftime.c.
commit : 9e5f3d013690c7b1b147ac20d3d61dad683a4141
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 May 2017 12:33:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 May 2017 12:33:12 -0400
The upstream IANA code does not guard against null TM_ZONE pointers in this
function, but in our code there is such a check in the other pre-existing
use of t->tm_zone. We do have some places that set pg_tm.tm_zone to NULL.
I'm not entirely sure it's possible to reach strftime with such a value,
but I'm not sure it isn't either, so be safe.
Per Coverity complaint.
M src/timezone/strftime.c
Install the "posixrules" timezone link in MSVC builds.
commit : 5971accd8b08516916c92081ec5576b306712981
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 May 2017 11:57:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 May 2017 11:57:41 -0400
Somehow, we'd missed ever doing this. The consequences aren't too
severe: basically, the timezone library would fall back on its hardwired
notion of the DST transition dates to use for a POSIX-style zone name,
rather than obeying US/Eastern which is the intended behavior. The net
effect would only be to obey current US DST law further back than it
ought to apply; so it's not real surprising that nobody noticed.
David Rowley, per report from Amit Kapila
Discussion: https://postgr.es/m/CAA4eK1LC7CaNhRAQ__C3ht1JVrPzaAXXhEJRnR5L6bfYHiLmWw@mail.gmail.com
M src/tools/msvc/Install.pm
Restore fullname[] contents before falling through in pg_open_tzfile().
commit : 07987304d613be200e8e2e603e448233a344d674
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 May 2017 11:34:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 May 2017 11:34:31 -0400
Fix oversight in commit af2c5aa88: if the shortcut open() doesn't work,
we need to reset fullname[] to be just the name of the toplevel tzdata
directory before we fall through into the pre-existing code. This failed
to be exposed in my (tgl's) testing because the fall-through path is
actually never taken under normal circumstances.
David Rowley, per report from Amit Kapila
Discussion: https://postgr.es/m/CAA4eK1LC7CaNhRAQ__C3ht1JVrPzaAXXhEJRnR5L6bfYHiLmWw@mail.gmail.com
M src/timezone/pgtz.c
Allow queries submitted by postgres_fdw to be canceled.
commit : 3aa16b117a28d70790ce492435d1dfc323edb547
author : Robert Haas <rhaas@postgresql.org>
date : Sat, 6 May 2017 22:17:35 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Sat, 6 May 2017 22:17:35 -0400
Back-patch of commits f039eaac7131ef2a4cf63a10cf98486f8bcd09d2 and
1b812afb0eafe125b820cc3b95e7ca03821aa675, which arranged (in 9.6+) to
make remote queries interruptible. It was known at the time that the
same problem existed in the back-branches, but I did not back-patch
for lack of a user complaint.
Michael Paquier and Etsuro Fujita, adjusted for older branches by me.
Per gripe from Suraj Kharage. This doesn't directly addresss Suraj's
gripe, but since the patch that will do so builds up on top of this
work, it seems best to back-patch this part first.
Discussion: http://postgr.es/m/CAF1DzPU8Kx+fMXEbFoP289xtm3bz3t+ZfxhmKavr98Bh-C0TqQ@mail.gmail.com
M contrib/postgres_fdw/connection.c
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/postgres_fdw.h
Document current_role.
commit : babf8f1c3825fdcd416caa90e51af360a613ea32
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 6 May 2017 14:19:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 6 May 2017 14:19:47 -0400
This system function has been there a very long time, but somehow escaped
being listed in func.sgml.
Fabien Coelho and Tom Lane
Discussion: https://postgr.es/m/alpine.DEB.2.20.1705061027580.3896@lancre
M doc/src/sgml/func.sgml
Allow MSVC to build with Tcl 8.6.
commit : f692583ddbe147e0071654c5e3786bb3bb646249
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 5 May 2017 12:05:34 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 5 May 2017 12:05:34 -0300
Commit eaba54c20c5 added support for Tcl 8.6 for configure-supported
platforms after verifying that pltcl works without further changes, but
the MSVC tooling wasn't updated accordingly. Update MSVC to match,
restructuring the code to avoid duplicating the logic for every Tcl
version supported.
Backpatch to all live branches, like eaba54c20c5. In 9.4 and previous,
change the patch to use backslashes rather than forward, as in the rest
of the file.
Reported by Paresh More, who also tested the patch I provided.
Discussion: https://postgr.es/m/CAAgiCNGVw3ssBtSi3ZNstrz5k00ax=UV+_ZEHUeW_LMSGL2sew@mail.gmail.com
M src/tools/msvc/Mkvcbuild.pm
Give nicer error message when connecting to a v10 server requiring SCRAM.
commit : db73b2820514620a87c4daa40d2dd8b16a214487
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 5 May 2017 11:24:02 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 5 May 2017 11:24:02 +0300
This is just to give the user a hint that they need to upgrade, if they try
to connect to a v10 server that uses SCRAM authentication, with an older
client.
Commit to all stable branches, but not master.
Discussion: https://www.postgresql.org/message-id/bbf45d92-3896-eeb7-7399-2111d517261b@pivotal.io
M src/include/libpq/pqcomm.h
M src/interfaces/libpq/fe-auth.c
Fix cursor_to_xml in tableforest false mode
commit : 6e86b448f2f700ab0a05afbeba80fbadfcd1d70a
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 3 May 2017 21:25:01 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 3 May 2017 21:25:01 -0400
It only produced <row> elements but no wrapping <table> element.
By contrast, cursor_to_xmlschema produced a schema that is now correct
but did not previously match the XML data produced by cursor_to_xml.
In passing, also fix a minor misunderstanding about moving cursors in
the tests related to this.
Reported-by: filip@jirsak.org
Based-on-patch-by: Thomas Munro <thomas.munro@enterprisedb.com>
M src/backend/utils/adt/xml.c
M src/test/regress/expected/xmlmap.out
M src/test/regress/expected/xmlmap_1.out
M src/test/regress/sql/xmlmap.sql
Remove useless and rather expensive stanza in matview regression test.
commit : 85b3bcbcd61cc1b5aac35e53edc67abd1bceee08
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 3 May 2017 19:37:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 3 May 2017 19:37:01 -0400
This removes a test case added by commit b69ec7cc9, which was intended
to exercise a corner case involving the rule used at that time that
materialized views were unpopulated iff they had physical size zero.
We got rid of that rule very shortly later, in commit 1d6c72a55, but
kept the test case. However, because the case now asks what VACUUM
will do to a zero-sized physical file, it would be pretty surprising
if the answer were ever anything but "nothing" ... and if things were
indeed that broken, surely we'd find it out from other tests. Since
the test involves a table that's fairly large by regression-test
standards (100K rows), it's quite slow to run. Dropping it should
save some buildfarm cycles, so let's do that.
Discussion: https://postgr.es/m/32386.1493831320@sss.pgh.pa.us
M src/test/regress/expected/matview.out
M src/test/regress/sql/matview.sql
Improve performance of timezone loading, especially pg_timezone_names view.
commit : 35ac926bfb8d0926f760abab1afe074aa7595210
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 May 2017 21:50:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 May 2017 21:50:35 -0400
tzparse() would attempt to load the "posixrules" timezone database file on
each call. That might seem like it would only be an issue when selecting a
POSIX-style zone name rather than a zone defined in the timezone database,
but it turns out that each zone definition file contains a POSIX-style zone
string and tzload() will call tzparse() to parse that. Thus, when scanning
the whole timezone file tree as we do in the pg_timezone_names view,
"posixrules" was read repetitively for each zone definition file. Fix
that by caching the file on first use within any given process. (We cache
other zone definitions for the life of the process, so there seems little
reason not to cache this one as well.) This probably won't help much in
processes that never run pg_timezone_names, but even one additional SET
of the timezone GUC would come out ahead.
An even worse problem for pg_timezone_names is that pg_open_tzfile()
has an inefficient way of identifying the canonical case of a zone name:
it basically re-descends the directory tree to the zone file. That's not
awful for an individual "SET timezone" operation, but it's pretty horrid
when we're inspecting every zone in the database. And it's pointless too
because we already know the canonical spelling, having just read it from
the filesystem. Fix by teaching pg_open_tzfile() to avoid the directory
search if it's not asked for the canonical name, and backfilling the
proper result in pg_tzenumerate_next().
In combination these changes seem to make the pg_timezone_names view
about 3x faster to read, for me. Since a scan of pg_timezone_names
has up to now been one of the slowest queries in the regression tests,
this should help some little bit for buildfarm cycle times.
Back-patch to all supported branches, not so much because it's likely
that users will care much about the view's performance as because
tracking changes in the upstream IANA timezone code is really painful
if we don't keep all the branches in sync.
Discussion: https://postgr.es/m/27962.1493671706@sss.pgh.pa.us
M src/timezone/README
M src/timezone/localtime.c
M src/timezone/pgtz.c
Ensure commands in extension scripts see the results of preceding DDL.
commit : 062824edd953a5a07fae7400267502d19a8f7bbf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 May 2017 18:05:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 May 2017 18:05:54 -0400
Due to a missing CommandCounterIncrement() call, parsing of a non-utility
command in an extension script would not see the effects of the immediately
preceding DDL command, unless that command's execution ends with
CommandCounterIncrement() internally ... which some do but many don't.
Report by Philippe Beaudoin, diagnosis by Julien Rouhaud.
Rather remarkably, this bug has evaded detection since extensions were
invented, so back-patch to all supported branches.
Discussion: https://postgr.es/m/2cf7941e-4e41-7714-3de8-37b1a8f74dff@free.fr
M src/backend/commands/extension.c
Update time zone data files to tzdata release 2017b.
commit : dc93cafcad89d3e626986166ef0fb87f53ead521
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 May 2017 11:52:59 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 May 2017 11:52:59 -0400
DST law changes in Chile, Haiti, and Mongolia. Historical corrections for
Ecuador, Kazakhstan, Liberia, and Spain.
The IANA crew continue their campaign to replace invented time zone
abbrevations with numeric GMT offsets. This update changes numerous zones
in South America, the Pacific and Indian oceans, and some Asian and Middle
Eastern zones. I kept these abbreviations in the tznames/ data files,
however, so that we will still accept them for input. (We may want to
start trimming those files someday, but I think we should wait for the
upstream dust to settle before deciding what to do.)
In passing, add MESZ (Mitteleuropaeische Sommerzeit) to the tznames lists;
since we accept MEZ (Mitteleuropaeische Zeit) it seems rather strange not
to take the other one. And fix some incorrect, or at least obsolete,
comments that certain abbreviations are not traceable to the IANA data.
M src/timezone/data/africa
M src/timezone/data/antarctica
M src/timezone/data/asia
M src/timezone/data/australasia
M src/timezone/data/backward
M src/timezone/data/backzone
M src/timezone/data/europe
M src/timezone/data/northamerica
M src/timezone/data/southamerica
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/America.txt
M src/timezone/tznames/Antarctica.txt
M src/timezone/tznames/Asia.txt
M src/timezone/tznames/Atlantic.txt
M src/timezone/tznames/Australia.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Europe.txt
M src/timezone/tznames/Indian.txt
M src/timezone/tznames/Pacific.txt
M src/timezone/tznames/README
Sync our copy of the timezone library with IANA release tzcode2017b.
commit : f8cf9719d6e767dc8897a22c71299a307e371de3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Apr 2017 15:13:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Apr 2017 15:13:51 -0400
zic no longer mishandles some transitions in January 2038 when it
attempts to work around Qt bug 53071. This fixes a bug affecting
Pacific/Tongatapu that was introduced in zic 2016e. localtime.c
now contains a workaround, useful when loading a file generated by
a buggy zic.
There are assorted cosmetic changes as well, notably relocation
of a bunch of #defines.
M src/timezone/README
M src/timezone/localtime.c
M src/timezone/pgtz.c
M src/timezone/private.h
M src/timezone/strftime.c
M src/timezone/tzfile.h
M src/timezone/zic.c
Fix VALIDATE CONSTRAINT to consider NO INHERIT attribute.
commit : 954744f7ac759e2dfe1f52e4493f728b98c615f2
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 28 Apr 2017 14:48:38 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 28 Apr 2017 14:48:38 -0400
Currently, trying to validate a NO INHERIT constraint on the parent will
search for the constraint in child tables (where it is not supposed to
exist), wrongly causing a "constraint does not exist" error.
Amit Langote, per a report from Hans Buschmann.
Discussion: http://postgr.es/m/20170421184012.24362.19@wrigleys.postgresql.org
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Fix order of arguments to SubTransSetParent().
commit : 8565808733ec127cf5972b4facc79889aee57850
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 23 Apr 2017 13:10:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 23 Apr 2017 13:10:57 -0400
ProcessTwoPhaseBuffer (formerly StandbyRecoverPreparedTransactions)
mixed up the parent and child XIDs when calling SubTransSetParent to
record the transactions' relationship in pg_subtrans.
Remarkably, analysis by Simon Riggs suggests that this doesn't lead to
visible problems (at least, not in non-Assert builds). That might
explain why we'd not noticed it before. Nonetheless, it's surely wrong.
This code was born broken, so back-patch to all supported branches.
Discussion: https://postgr.es/m/20110.1492905318@sss.pgh.pa.us
M src/backend/access/transam/twophase.c
doc: Update link
commit : 38a6e57db2e99d22a15e71359cd090da17fd77b0
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 21 Apr 2017 19:42:01 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 21 Apr 2017 19:42:01 -0400
The reference "That is the topic of the next section." has been
incorrect since the materialized views documentation got inserted
between the section "rules-views" and "rules-update".
Author: Zertrin <postgres_wiki@zertrin.org>
M doc/src/sgml/rules.sgml
Avoid depending on non-POSIX behavior of fcntl(2).
commit : 899960b9fec20d55ebc8a6b7e22a90d0f65d4d17
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Apr 2017 15:55:56 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Apr 2017 15:55:56 -0400
The POSIX standard does not say that the success return value for
fcntl(F_SETFD) and fcntl(F_SETFL) is zero; it says only that it's not -1.
We had several calls that were making the stronger assumption. Adjust
them to test specifically for -1 for strict spec compliance.
The standard further leaves open the possibility that the O_NONBLOCK
flag bit is not the only active one in F_SETFL's argument. Formally,
therefore, one ought to get the current flags with F_GETFL and store
them back with only the O_NONBLOCK bit changed when trying to change
the nonblock state. In port/noblock.c, we were doing the full pushup
in pg_set_block but not in pg_set_noblock, which is just weird. Make
both of them do it properly, since they have little business making
any assumptions about the socket they're handed. The other places
where we're issuing F_SETFL are working with FDs we just got from
pipe(2), so it's reasonable to assume the FDs' properties are all
default, so I didn't bother adding F_GETFL steps there.
Also, while pg_set_block deserves some points for trying to do things
right, somebody had decided that it'd be even better to cast fcntl's
third argument to "long". Which is completely loony, because POSIX
clearly says the third argument for an F_SETFL call is "int".
Given the lack of field complaints, these missteps apparently are not
of significance on any common platforms. But they're still wrong,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/30882.1492800880@sss.pgh.pa.us
M contrib/pg_test_fsync/pg_test_fsync.c
M src/backend/port/unix_latch.c
M src/backend/postmaster/postmaster.c
M src/port/noblock.c
Support OpenSSL 1.1.0 in 9.3 and 9.2.
commit : 4e91330daca017aeeed2a3deea646a7c9aaaa45f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Apr 2017 13:52:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Apr 2017 13:52:42 -0400
This commit back-patches the equivalent of the 9.5-branch commits
e2838c580 and 48e5ba61e, so that we can work with OpenSSL 1.1.0
in all supported branches.
Original patches by Andreas Karlsson and Heikki Linnakangas,
back-patching work by Andreas Karlsson.
Patch: https://postgr.es/m/0c817abb-3f7d-20fb-583a-58f7593a0bea@proxel.se
Discussion: https://postgr.es/m/5129.1492293840@sss.pgh.pa.us
M configure
M configure.in
M contrib/pgcrypto/internal.c
M contrib/pgcrypto/openssl.c
M contrib/pgcrypto/pgp-s2k.c
M contrib/pgcrypto/px-crypt.c
M contrib/pgcrypto/px.h
M src/backend/libpq/be-secure.c
M src/include/pg_config.h.in
M src/interfaces/libpq/fe-secure.c
M src/interfaces/libpq/libpq-int.h
Back-patch 9.4-era SSL renegotiation code into 9.3 and 9.2.
commit : fbfeceb25362097c5552751427151a07d23b8241
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Apr 2017 12:51:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Apr 2017 12:51:40 -0400
This back-patches 9.4 commits 31cf1a1a4, 86029b31e, and 36a3be654 into
the prior branches, along with relevant bits of b1aebbb6a and 7ce2a45ae.
We had foreseen doing this once the code was proven, but that never did
happen, probably because we got sufficiently fed up with renegotiation
to disable it by default. However, we have to do something now because
the prior code doesn't even compile against OpenSSL 1.1. Per discussion,
the best solution seems to be to make the older branches look like 9.4.
Discussion: https://postgr.es/m/20047.1492305247@sss.pgh.pa.us
M src/backend/libpq/be-secure.c
M src/backend/tcop/postgres.c
Provide a way to control SysV shmem attach address in EXEC_BACKEND builds.
commit : fddc10146eb2cd9e35f8d6849cde88ea2461cdb1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Apr 2017 17:27:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Apr 2017 17:27:38 -0400
In standard non-Windows builds, there's no particular reason to care what
address the kernel chooses to map the shared memory segment at. However,
when building with EXEC_BACKEND, there's a risk that the chosen address
won't be available in all child processes. Linux with ASLR enabled (which
it is by default) seems particularly at risk because it puts shmem segments
into the same area where it maps shared libraries. We can work around
that by specifying a mapping address that's outside the range where
shared libraries could get mapped. On x86_64 Linux, 0x7e0000000000
seems to work well.
This is only meant for testing/debugging purposes, so it doesn't seem
necessary to go as far as providing a GUC (or any user-visible
documentation, though we might change that later). Instead, it's just
controlled by setting an environment variable PG_SHMEM_ADDR to the
desired attach address.
Back-patch to all supported branches, since the point here is to
remove intermittent buildfarm failures on EXEC_BACKEND animals.
Owners of affected animals will need to add a suitable setting of
PG_SHMEM_ADDR to their build_env configuration.
Discussion: https://postgr.es/m/7036.1492231361@sss.pgh.pa.us
M src/backend/port/sysv_shmem.c
Further fix pg_trgm's extraction of trigrams from regular expressions.
commit : fad06b287377748fa058d2c0e768132341060d4b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 14 Apr 2017 14:52:03 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 14 Apr 2017 14:52:03 -0400
Commit 9e43e8714 turns out to have been insufficient: not only is it
necessary to track tentative parent links while considering a set of
arc removals, but it's necessary to track tentative flag additions
as well. This is because we always merge arc target states into
arc source states; therefore, when considering a merge of the final
state with some other, it is the other state that will acquire a new
TSTATE_FIN bit. If there's another arc for the same color trigram
that would cause merging of that state with the initial state, we
failed to recognize the problem. The test cases for the prior commit
evidently only exercised situations where a tentative merge with the
initial state occurs before one with the final state. If it goes the
other way around, we'll happily merge the initial and final states,
either producing a broken final graph that would never match anything,
or triggering the Assert added by the prior commit.
It's tempting to consider switching the merge direction when the merge
involves the final state, but I lack the time to analyze that idea in
detail. Instead just keep track of the flag changes that would result
from proposed merges, in the same way that the prior commit tracked
proposed parent links.
Along the way, add some more debugging support, because I'm not entirely
confident that this is the last bug here. And tweak matters so that
the transformed.dot file uses small integers rather than pointer values
to identify states; that makes it more readable if you're just eyeballing
it rather than fooling with Graphviz. And rename a couple of identically
named struct fields to reduce confusion.
Per report from Corey Csuhta. Add a test case based on his example.
(Note: this case does not trigger the bug under 9.3, apparently because
its different measurement of costs causes it to stop merging states before
it hits the failure. I spent some time trying to find a variant that would
fail in 9.3, without success; but I'm sure such cases exist.)
Like the previous patch, back-patch to 9.3 where this code was added.
Report: https://postgr.es/m/E2B01A4B-4530-406B-8D17-2F67CF9A16BA@csuhta.com
M contrib/pg_trgm/expected/pg_trgm.out
M contrib/pg_trgm/sql/pg_trgm.sql
M contrib/pg_trgm/trgm_regexp.c
Fix regexport.c to behave sanely with lookaround constraints.
commit : 5be58cc89acef45fff14159fdfefbacfac08bfde
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Apr 2017 17:18:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Apr 2017 17:18:35 -0400
regexport.c thought it could just ignore LACON arcs, but the correct
behavior is to treat them as satisfiable while consuming zero input
(rather reminiscently of commit 9f1e642d5). Otherwise, the emitted
simplified-NFA representation may contain no paths leading from initial
to final state, which unsurprisingly confuses pg_trgm, as seen in
bug #14623 from Jeff Janes.
Since regexport's output representation has no concept of an arc that
consumes zero input, recurse internally to find the next normal arc(s)
after any LACON transitions. We'd be forced into changing that
representation if a LACON could be the last arc reaching the final
state, but fortunately the regex library never builds NFAs with such
a configuration, so there always is a next normal arc.
Back-patch to 9.3 where this logic was introduced.
Discussion: https://postgr.es/m/20170413180503.25948.94871@wrigleys.postgresql.org
M contrib/pg_trgm/expected/pg_trgm.out
M contrib/pg_trgm/sql/pg_trgm.sql
M src/backend/regex/regexport.c
Improve castNode notation by introducing list-extraction-specific variants.
commit : ff9398052df511e7789b697e1be3bd940d45d74a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Apr 2017 13:51:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Apr 2017 13:51:29 -0400
This extends the castNode() notation introduced by commit 5bcab1114 to
provide, in one step, extraction of a list cell's pointer and coercion to
a concrete node type. For example, "lfirst_node(Foo, lc)" is the same
as "castNode(Foo, lfirst(lc))". Almost half of the uses of castNode
that have appeared so far include a list extraction call, so this is
pretty widely useful, and it saves a few more keystrokes compared to the
old way.
As with the previous patch, back-patch the addition of these macros to
pg_list.h, so that the notation will be available when back-patching.
Patch by me, after an idea of Andrew Gierth's.
Discussion: https://postgr.es/m/14197.1491841216@sss.pgh.pa.us
M src/include/nodes/pg_list.h
Silence compiler warning in sepgsql
commit : 649cd9085efb2cb4e21eec3b3861f46e89ba3a34
author : Joe Conway <mail@joeconway.com>
date : Thu, 6 Apr 2017 14:21:54 -0700
committer: Joe Conway <mail@joeconway.com>
date : Thu, 6 Apr 2017 14:21:54 -0700
<selinux/label.h> includes <stdbool.h>, which creates an incompatible
We don't care if <stdbool.h> redefines "true"/"false"; those are close
enough.
Complaint and initial patch by Mike Palmiotto. Final approach per
Tom Lane's suggestion, as discussed on hackers. Backpatching to
all supported branches.
Discussion: https://postgr.es/m/flat/623bcaae-112e-ced0-8c22-a84f75ae0c53%40joeconway.com
M contrib/sepgsql/label.c
Remove dead code and fix comments in fast-path function handling.
commit : c2f08c6429457a92c99906e5fa56069c57fbe3f2
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 6 Apr 2017 09:09:39 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 6 Apr 2017 09:09:39 +0300
HandleFunctionRequest() is no longer responsible for reading the protocol
message from the client, since commit 2b3a8b20c2. Fix the outdated
comments.
HandleFunctionRequest() now always returns 0, because the code that used
to return EOF was moved in 2b3a8b20c2. Therefore, the caller no longer
needs to check the return value.
Reported by Andres Freund. Backpatch to all supported versions, even though
this doesn't have any user-visible effect, to make backporting future
patches in this area easier.
Discussion: https://www.postgresql.org/message-id/20170405010525.rt5azbya5fkbhvrx@alap3.anarazel.de
M src/backend/tcop/fastpath.c
M src/backend/tcop/postgres.c
M src/include/tcop/fastpath.h
Simplify the example of VACUUM in documentation.
commit : 82f7c325530064d487fe6a9d378e59472d8346dc
author : Fujii Masao <fujii@postgresql.org>
date : Fri, 31 Mar 2017 01:31:15 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Fri, 31 Mar 2017 01:31:15 +0900
Previously a detailed activity report by VACUUM VERBOSE ANALYZE was
described as an example of VACUUM in docs. But it had been obsolete
for a long time. For example, commit feb4f44d296b88b7f0723f4a4f3945a371276e0b
updated the content of that activity report in 2003, but we had
forgotten to update the example.
So basically we need to update the example. But since no one cared
about the details of VACUUM output and complained about that mistake
for such long time, per discussion on hackers, we decided to get rid
of the detailed activity report from the example and simplify it.
Back-patch to all supported versions.
Reported by Masahiko Sawada, patch by me.
Discussion: https://postgr.es/m/CAD21AoAGA2pB3p-CWmTkxBsbkZS1bcDGBLcYVcvcDxspG_XAfA@mail.gmail.com
M doc/src/sgml/ref/vacuum.sgml
Fix unportable disregard of alignment requirements in RADIUS code.
commit : 3455ddbfa6b7c38d55d2638d062f311343b8f053
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 26 Mar 2017 17:35:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 26 Mar 2017 17:35:35 -0400
The compiler is entitled to store a char[] local variable with no
particular alignment requirement. Our RADIUS code cavalierly took such
a local variable and cast its address to a struct type that does have
alignment requirements. On an alignment-picky machine this would lead
to bus errors. To fix, declare the local variable honestly, and then
cast its address to char * for use in the I/O calls.
Given the lack of field complaints, there must be very few if any
people affected; but nonetheless this is a clear portability issue,
so back-patch to all supported branches.
Noted while looking at a Coverity complaint in the same code.
M src/backend/libpq/auth.c
Revert Windows service check refactoring, and replace with a different fix.
commit : e0e1ef46d8c98dc71f23572851b5467185fae8e0
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 24 Mar 2017 12:39:01 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 24 Mar 2017 12:39:01 +0200
This reverts commit 38bdba54a64bacec78e3266f0848b0b4a824132a, "Fix and
simplify check for whether we're running as Windows service". It turns out
that older versions of MinGW - like that on buildfarm member narwhal - do
not support the CheckTokenMembership() function. This replaces the
refactoring with a much smaller fix, to add a check for SE_GROUP_ENABLED to
pgwin32_is_service().
Only apply to back-branches, and keep the refactoring in HEAD. It's
unlikely that anyone is still really using such an old version of MinGW -
aside from narwhal - but let's not change the minimum requirements in
minor releases.
Discussion: https://www.postgresql.org/message-id/16609.1489773427@sss.pgh.pa.us
Patch: https://www.postgresql.org/message-id/CAB7nPqSvfu%3DKpJ%3DNX%2BYAHmgAmQdzA7N5h31BjzXeMgczhGCC%2BQ%40mail.gmail.com
M src/backend/port/win32/security.c
doc: Fix a few typos and awkward links
commit : 5fdc70826fd023498c1480ae7f398183a5c9be91
author : Peter Eisentraut <peter_e@gmx.net>
date : Sat, 18 Mar 2017 23:44:30 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Sat, 18 Mar 2017 23:44:30 -0400
M doc/src/sgml/config.sgml
M doc/src/sgml/ecpg.sgml
M doc/src/sgml/high-availability.sgml
Remove dead link.
commit : da17ce6881f0c92086d1015351fcfad7e7098fb8
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 17 Mar 2017 09:32:34 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 17 Mar 2017 09:32:34 -0400
David Christensen
Discussion: http://postgr.es/m/82299377-1480-4439-9ABA-5828D71AA22E@endpoint.com
M doc/src/sgml/high-availability.sgml
Fix and simplify check for whether we're running as Windows service.
commit : 3ebcc2498d2b011d42f7ad6a50728b9d7cfb1286
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 17 Mar 2017 11:14:01 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 17 Mar 2017 11:14:01 +0200
If the process token contains SECURITY_SERVICE_RID, but it has been
disabled by the SE_GROUP_USE_FOR_DENY_ONLY attribute, win32_is_service()
would incorrectly report that we're running as a service. That situation
arises, e.g. if postmaster is launched with a restricted security token,
with the "Log in as Service" privilege explicitly removed.
Replace the broken code with CheckProcessTokenMembership(), which does
this correctly. Also replace similar code in win32_is_admin(), even
though it got this right, for simplicity and consistency.
Per bug #13755, reported by Breen Hagan. Back-patch to all supported
versions. Patch by Takayuki Tsunakawa, reviewed by Michael Paquier.
Discussion: https://www.postgresql.org/message-id/20151104062315.2745.67143%40wrigleys.postgresql.org
M src/backend/port/win32/security.c
Avoid having vacuum set reltuples to 0 on non-empty relations in the presence of page pins, which leads to serious estimation errors in the planner. This particularly affects small heavily-accessed tables, especially where locking (e.g. from FK constraints) forces frequent vacuums for mxid cleanup.
commit : 8f8a5aefc73524658f989f3abd929afa5e7d3ff7
author : Andrew Gierth <rhodiumtoad@postgresql.org>
date : Thu, 16 Mar 2017 22:33:18 +0000
committer: Andrew Gierth <rhodiumtoad@postgresql.org>
date : Thu, 16 Mar 2017 22:33:18 +0000
Fix by keeping separate track of pages whose live tuples were actually
counted vs. pages that were only scanned for freezing purposes. Thus,
reltuples can only be set to 0 if all pages of the relation were
actually counted.
Backpatch to all supported versions.
Per bug #14057 from Nicolas Baccelli, analyzed by me.
Discussion: https://postgr.es/m/20160331103739.8956.94469@wrigleys.postgresql.org
M src/backend/commands/vacuumlazy.c
Spelling fixes
commit : a7dcd95dab7227753b44c92397c07e94c13348b5
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 14 Mar 2017 12:57:10 -0400
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 14 Mar 2017 12:57:10 -0400
From: Josh Soref <jsoref@gmail.com>
M contrib/ltree/ltxtquery_io.c
M doc/src/sgml/biblio.sgml
M doc/src/sgml/release-8.4.sgml
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-old.sgml
M src/backend/access/transam/xlog.c
M src/backend/optimizer/geqo/geqo_erx.c
M src/backend/port/dynloader/linux.c
M src/backend/replication/walreceiverfuncs.c
M src/interfaces/libpq/bcc32.mak
M src/test/regress/expected/tsdicts.out
M src/test/regress/sql/tsdicts.sql
Fix failure to mark init buffers as BM_PERMANENT.
commit : 6bd7816e766abd6c10db16ed0af93a512b1a662d
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 14 Mar 2017 11:51:11 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 14 Mar 2017 11:51:11 -0400
This could result in corruption of the init fork of an unlogged index
if the ambuildempty routine for that index used shared buffers to
create the init fork, which was true for gin, gist, and hash indexes.
Patch by me, based on an earlier patch by Michael Paquier, who also
reviewed this one. This also incorporates an idea from Artur
Zakirov.
Discussion: http://postgr.es/m/CACYUyc8yccE4xfxhqxfh_Mh38j7dRFuxfaK1p6dSNAEUakxUyQ@mail.gmail.com
M src/backend/storage/buffer/bufmgr.c
M src/include/storage/buf_internals.h
Remove unnecessary dependency on statement_timeout in prepared_xacts test.
commit : 8c6b940bce881082a1a2aac871656b7044901108
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Mar 2017 16:46:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Mar 2017 16:46:32 -0400
Rather than waiting around for statement_timeout to expire, we can just
try to take the table's lock in nowait mode. This saves some fraction
under 4 seconds when running this test with prepared xacts available,
and it guards against timeout-expired-anyway failures on very slow
machines when prepared xacts are not available, as seen in a recent
failure on axolotl for instance.
This approach could fail if autovacuum were to take an exclusive lock
on the test table concurrently, but there's no reason for it to do so.
Since the main point here is to improve stability in the buildfarm,
back-patch to all supported branches.
M src/test/regress/expected/prepared_xacts.out
M src/test/regress/expected/prepared_xacts_1.out
M src/test/regress/sql/prepared_xacts.sql
Ecpg should support COMMIT PREPARED and ROLLBACK PREPARED.
commit : 04207ef769b59fd8c4b4fba2cb9a6e6a15deeafc
author : Michael Meskes <meskes@postgresql.org>
date : Mon, 13 Mar 2017 20:44:13 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Mon, 13 Mar 2017 20:44:13 +0100
The problem was that "begin transaction" was issued automatically
before executing COMMIT/ROLLBACK PREPARED if not in auto commit. This fix by
Masahiko Sawada fixes this.
M src/interfaces/ecpg/ecpglib/misc.c
Fix pg_file_write() error handling.
commit : e03c6d93bfabc6606a8778b253ae31f2c3ee849d
author : Noah Misch <noah@leadboat.com>
date : Sun, 12 Mar 2017 19:35:31 -0400
committer: Noah Misch <noah@leadboat.com>
date : Sun, 12 Mar 2017 19:35:31 -0400
Detect fclose() failures; given "ln -s /dev/full $PGDATA/devfull",
"pg_file_write('devfull', 'x', true)" now fails as it should. Don't
leak a stream when fwrite() fails. Remove a born-ineffective test that
aimed to skip zero-length writes. Back-patch to 9.2 (all supported
versions).
M contrib/adminpack/adminpack.c
Fix ancient connection leak in dblink
commit : f6cfc14e5ad3b8e5309615f8f7d15f55ba238f97
author : Joe Conway <mail@joeconway.com>
date : Sat, 11 Mar 2017 13:33:22 -0800
committer: Joe Conway <mail@joeconway.com>
date : Sat, 11 Mar 2017 13:33:22 -0800
When using unnamed connections with dblink, every time a new
connection is made, the old one is leaked. Fix that.
This has been an issue probably since dblink was first committed.
Someone complained almost ten years ago, but apparently I decided
not to pursue it at the time, and neither did anyone else, so it
slipped between the cracks. Now that someone else has complained,
fix in all supported branches.
Discussion: (orig) https://postgr.es/m/flat/F680AB59-6D6F-4026-9599-1BE28880273D%40decibel.org#F680AB59-6D6F-4026-9599-1BE28880273D@decibel.org
Discussion: (new) https://postgr.es/m/flat/0A3221C70F24FB45833433255569204D1F6ADF8C@G01JPEXMBYT05
Reported by: Jim Nasby and Takayuki Tsunakawa
M contrib/dblink/dblink.c
Sanitize newlines in object names in "pg_restore -l" output.
commit : 0c0a95c2f83b4ed88ebb7f7759c22cd73e7b3cf3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Mar 2017 14:15:09 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Mar 2017 14:15:09 -0500
Commits 89e0bac86 et al replaced newlines with spaces in object names
printed in SQL comments, but we neglected to consider that the same
names are also printed by "pg_restore -l", and a newline would render
the output unparseable by "pg_restore -L". Apply the same replacement
in "-l" output. Since "pg_restore -L" doesn't actually examine any
object names, only the dump ID field that starts each line, this is
enough to fix things for its purposes.
The previous fix was treated as a security issue, and we might have
done that here as well, except that the issue was reported publicly
to start with. Anyway it's hard to see how this could be exploited
for SQL injection; "pg_restore -L" doesn't do much with the file
except parse it for leading integers.
Per bug #14587 from Milos Urbanek. Back-patch to all supported versions.
Discussion: https://postgr.es/m/20170310155318.1425.30483@wrigleys.postgresql.org
M src/bin/pg_dump/pg_backup_archiver.c
Fix a potential double-free in ecpg.
commit : af471919bc7e501ee75dd48be763fbdb9c7b530a
author : Michael Meskes <meskes@postgresql.org>
date : Fri, 10 Mar 2017 10:32:41 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Fri, 10 Mar 2017 10:32:41 +0100
M src/interfaces/ecpg/preproc/pgc.l
Fix timestamptz regression test to still work with latest IANA zone data.
commit : c6dc45d157a6e04b00231d34a7d7acd296b7e56e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 Mar 2017 17:20:11 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 Mar 2017 17:20:11 -0500
The IANA timezone crew continues to chip away at their project of removing
timezone abbreviations that have no real-world currency from their
database. The tzdata2017a update removes all such abbreviations for
South American zones, as well as much of the Pacific. This breaks some
test cases in timestamptz.sql that were expecting America/Santiago and
America/Caracas to have non-numeric abbreviations.
The test cases involving America/Santiago seem to have selected that
zone more or less at random, so just replace it with America/New_York,
which is of similar longitude. The cases involving America/Caracas are
harder since they were chosen to test a time-varying zone abbreviation
around a point where it changed meaning in the backwards direction.
Fortunately, Europe/Moscow has a similar case in 2014, and the MSK/MSD
abbreviations are well enough attested that IANA seems unlikely to
decide to remove them from the database in future.
With these changes, this regression test should pass when using any IANA
zone database from 2015 or later. One could wish that there were a few
years more daylight on how out-of-date your zone database can be ... but
really the --with-system-tzdata option is only meant for use on platforms
where the zone database is kept up-to-date pretty faithfully, so I do not
think this is a big objection.
Discussion: https://postgr.es/m/6749.1489087470@sss.pgh.pa.us
M src/test/regress/expected/timestamptz.out
M src/test/regress/sql/timestamptz.sql
pg_xlogdump: Remove extra newline in error message
commit : 5c7ce2d03a7380f8049a7ba1d9336ebed144d97c
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 8 Mar 2017 09:57:17 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 8 Mar 2017 09:57:17 -0500
fatal_error() already prints out a trailing newline.
M contrib/pg_xlogdump/pg_xlogdump.c
Repair incorrect pg_dump labeling for some comments and security labels.
commit : 783acfd4dc9f320c4650e8f1b50ba09534edba15
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Mar 2017 19:33:59 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Mar 2017 19:33:59 -0500
We attached no schema label to comments for procedural languages, casts,
transforms, operator classes, operator families, or text search objects.
The first three categories of objects don't really have schemas, but
pg_dump treats them as if they do, and it seems like the TocEntry fields
for their comments had better match the TocEntry fields for the parent
objects. (As an example of a possible hazard, the type names in a CAST
will be formatted with the assumption of a particular search_path, so
failing to ensure that this same path is active for the COMMENT ON command
could lead to an error or to attaching the comment to the wrong cast.)
In the last six cases, this was a flat-out error --- possibly mine to
begin with, but it was a long time ago.
The security label for a procedural language was likewise not correctly
labeled as to schema, and both the comment and security label for a
procedural language were not correctly labeled as to owner.
In simple cases the restore would accidentally work correctly anyway, since
these comments and security labels would normally get emitted right after
the owning object, and so the search path and active user would be correct
anyhow. But it could fail in corner cases; for example a schema-selective
restore would omit comments it should include.
Giuseppe Broccolo noted the oversight, and proposed the correct fix, for
text search dictionary objects; I found the rest by cross-checking other
dumpComment() calls. These oversights are ancient, so back-patch all
the way.
Discussion: https://postgr.es/m/CAFzmHiWwwzLjzwM4x5ki5s_PDMR6NrkipZkjNnO3B0xEpBgJaA@mail.gmail.com
M src/bin/pg_dump/pg_dump.c
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
commit : 7f831f09bb85d93d99f55269479e4b6d105937f8
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 6 Mar 2017 17:04:29 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 6 Mar 2017 17:04:29 -0500
When performing a pg_upgrade, we copy the files behind pg_largeobject
and pg_largeobject_metadata, allowing us to avoid having to dump out and
reload the actual data for large objects and their ACLs.
Unfortunately, that isn't all of the information which can be associated
with large objects. Currently, we also support COMMENTs and SECURITY
LABELs with large objects and these were being silently dropped during a
pg_upgrade as pg_dump would skip everything having to do with a large
object and pg_upgrade only copied the tables mentioned to the new
cluster.
As the file copies happen after the catalog dump and reload, we can't
simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode
output but we also have to include the actual large object definition as
well. With the definition, comments, and security labels in the pg_dump
output and the file copies performed by pg_upgrade, all of the data and
metadata associated with large objects is able to be successfully pulled
forward across a pg_upgrade.
In 9.6 and master, we can simply adjust the dump bitmask to indicate
which components we don't want. In 9.5 and earlier, we have to put
explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL
or the data when in binary-upgrade mode.
Adjustments made to the privileges regression test to allow another test
(large_object.sql) to be added which explicitly leaves a large object
with a comment in place to provide coverage of that case with
pg_upgrade.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/20170221162655.GE9812@tamriel.snowman.net
M src/bin/pg_dump/pg_backup.h
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_dump.c
A src/test/regress/expected/large_object.out
M src/test/regress/expected/privileges.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
A src/test/regress/sql/large_object.sql
M src/test/regress/sql/privileges.sql
Add /config.cache to .gitignore in back branches
commit : 6987277619f218d4056178ac1d9c6d9ef8efc9c8
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 25 Feb 2017 13:04:22 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 25 Feb 2017 13:04:22 -0500
For some reason config.cache was not being git-ignored in these back
branches.
Backpatch-through: 9.2 to 9.4
M .gitignore
Fix contrib/pg_trgm's extraction of trigrams from regular expressions.
commit : 53b5a8c131064c3bc8f81d2617e2328487b4fba9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 Feb 2017 15:04:07 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 Feb 2017 15:04:07 -0500
The logic for removing excess trigrams from the result was faulty.
It intends to avoid merging the initial and final states of the NFA,
which is necessary, but in testing whether removal of a specific trigram
would cause that, it failed to consider the combined effects of all the
state merges that that trigram's removal would cause. This could result
in a broken final graph that would never match anything, leading to GIN
or GiST indexscans not finding anything.
To fix, add a "tentParent" field that is used only within this loop,
and set it to show state merges that we are tentatively going to do.
While examining a particular arc, we must chase up through tentParent
links as well as regular parent links (the former can only appear atop
the latter), and we must account for state init/fin flag merges that
haven't actually been done yet.
To simplify the latter, combine the separate init and fin bool fields
into a bitmap flags field. I also chose to get rid of the "children"
state list, which seems entirely inessential.
Per bug #14563 from Alexey Isayko, which the added test cases are based on.
Back-patch to 9.3 where this code was added.
Report: https://postgr.es/m/20170222111446.1256.67547@wrigleys.postgresql.org
Discussion: https://postgr.es/m/8816.1487787594@sss.pgh.pa.us
M contrib/pg_trgm/expected/pg_trgm.out
M contrib/pg_trgm/sql/pg_trgm.sql
M contrib/pg_trgm/trgm_regexp.c
Fix sloppy handling of corner-case errors in fd.c.
commit : 3f613c6a4073149bb79af8ec82eab9c0a900fd53
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 Feb 2017 17:51:28 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 Feb 2017 17:51:28 -0500
Several places in fd.c had badly-thought-through handling of error returns
from lseek() and close(). The fact that those would seldom fail on valid
FDs is probably the reason we've not noticed this up to now; but if they
did fail, we'd get quite confused.
LruDelete and LruInsert actually just Assert'd that lseek never fails,
which is pretty awful on its face.
In LruDelete, we indeed can't throw an error, because that's likely to get
called during error abort and so throwing an error would probably just lead
to an infinite loop. But by the same token, throwing an error from the
close() right after that was ill-advised, not to mention that it would've
left the LRU state corrupted since we'd already unlinked the VFD from the
list. I also noticed that really, most of the time, we should know the
current seek position and it shouldn't be necessary to do an lseek here at
all. As patched, if we don't have a seek position and an lseek attempt
doesn't give us one, we'll close the file but then subsequent re-open
attempts will fail (except in the somewhat-unlikely case that a
FileSeek(SEEK_SET) call comes between and allows us to re-establish a known
target seek position). This isn't great but it won't result in any state
corruption.
Meanwhile, having an Assert instead of an honest test in LruInsert is
really dangerous: if that lseek failed, a subsequent read or write would
read or write from the start of the file, not where the caller expected,
leading to data corruption.
In both LruDelete and FileClose, if close() fails, just LOG that and mark
the VFD closed anyway. Possibly leaking an FD is preferable to getting
into an infinite loop or corrupting the VFD list. Besides, as far as I can
tell from the POSIX spec, it's unspecified whether or not the file has been
closed, so treating it as still open could be the wrong thing anyhow.
I also fixed a number of other places that were being sloppy about
behaving correctly when the seekPos is unknown.
Also, I changed FileSeek to return -1 with EINVAL for the cases where it
detects a bad offset, rather than throwing a hard elog(ERROR). It seemed
pretty inconsistent that some bad-offset cases would get a failure return
while others got elog(ERROR). It was missing an offset validity check for
the SEEK_CUR case on a closed file, too.
Back-patch to all supported branches, since all this code is fundamentally
identical in all of them.
Discussion: https://postgr.es/m/2982.1487617365@sss.pgh.pa.us
M src/backend/storage/file/fd.c
doc: Update URL for plr
commit : 6b75aee4b645ae48ba99ed383218d50e46c292ae
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 21 Feb 2017 12:35:57 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 21 Feb 2017 12:35:57 -0500
M doc/src/sgml/external-projects.sgml
Fix documentation of to_char/to_timestamp TZ, tz, OF formatting patterns.
commit : 391a239a1c348a83ddf9218b33cab6ee4cd7fce7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 Feb 2017 10:05:01 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 Feb 2017 10:05:01 -0500
These are only supported in to_char, not in the other direction, but the
documentation failed to mention that. Also, describe TZ/tz as printing the
time zone "abbreviation", not "name", because what they print is elsewhere
referred to that way. Per bug #14558.
M doc/src/sgml/func.sgml
Make src/interfaces/libpq/test clean up after itself.
commit : 4be0c2e4417920f27ba2886d2036a672f375fe34
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 Feb 2017 17:18:10 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 Feb 2017 17:18:10 -0500
It failed to remove a .o file during "make clean", and it lacked
a .gitignore file entirely.
A src/interfaces/libpq/test/.gitignore
M src/interfaces/libpq/test/Makefile
Adjust PL/Tcl regression test to dodge a possible bug or zone dependency.
commit : 300ac7ff190fcf20843d3d1b4b55b1bce7f99e0f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 Feb 2017 16:14:52 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 Feb 2017 16:14:52 -0500
One case in the PL/Tcl tests is observed to fail on RHEL5 with a Turkish
time zone setting. It's not clear if this is an old Tcl bug or something
odd about the zone data, but in any case that test is meant to see if the
Tcl [clock] command works at all, not what its corner-case behaviors are.
Therefore we have no need to test exactly which week a Sunday midnight is
considered to fall into. Probe the following Tuesday instead.
Discussion: https://postgr.es/m/797.1487517822@sss.pgh.pa.us
M src/pl/tcl/expected/pltcl_setup.out
M src/pl/tcl/sql/pltcl_setup.sql
Fix help message for pg_basebackup -R
commit : 463d4dbfb24b71ed4fdf2a252d0474704f4952c9
author : Magnus Hagander <magnus@hagander.net>
date : Sat, 18 Feb 2017 13:48:15 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Sat, 18 Feb 2017 13:48:15 +0100
The recovery.conf file that's generated is specifically for
replication, and not needed (or wanted) for regular backup restore, so
indicate that in the message.
M src/bin/pg_basebackup/pg_basebackup.c
Back-patch 9.4-era compiler warning fixes into older branches.
commit : b5005ffa4627c1c805408389da92e2bcf515a192
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Feb 2017 17:12:14 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Feb 2017 17:12:14 -0500
Back-patch commit 4e182361804f8688cef953c998e24134e606aea4
(another thing that longfin's version of clang doesn't like).
M src/pl/plperl/plperl.c
Back-patch 9.4-era compiler warning fixes into older branches.
commit : e9e2bde2d29ceed3817434b85a4dfef84fb25556
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Feb 2017 16:58:26 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Feb 2017 16:58:26 -0500
This applies portions of commits b64b5ccb6 and b1aebbb6a to the older
branches, in hopes of getting -Werror builds to succeed there. The
applied changes simply remove useless tests, eg checking an unsigned
variable to see if it is >= 0. Recent versions of clang warn about
such tests by default.
M contrib/pg_standby/pg_standby.c
M src/interfaces/libpq/fe-exec.c
Document usage of COPT environment variable for adjusting configure flags.
commit : 6b77a0e125897fd3b5c553017a060735803e580e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Feb 2017 16:11:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Feb 2017 16:11:03 -0500
Also add to the existing rather half-baked description of PROFILE,
which does exactly the same thing, but I think people use it differently.
Discussion: https://postgr.es/m/16461.1487361849@sss.pgh.pa.us
M doc/src/sgml/installation.sgml
M src/Makefile.global.in
Make sure that hash join's bulk-tuple-transfer loops are interruptible.
commit : 6a4941f8c622df999614f2a5819ee99db99f70ee
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 15 Feb 2017 16:40:06 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 15 Feb 2017 16:40:06 -0500
The loops in ExecHashJoinNewBatch(), ExecHashIncreaseNumBatches(), and
ExecHashRemoveNextSkewBucket() are all capable of iterating over many
tuples without ever doing a CHECK_FOR_INTERRUPTS, so that the backend
might fail to respond to SIGINT or SIGTERM for an unreasonably long time.
Fix that. In the case of ExecHashJoinNewBatch(), it seems useful to put
the added CHECK_FOR_INTERRUPTS into ExecHashJoinGetSavedTuple() rather
than directly in the loop, because that will also ensure that both
principal code paths through ExecHashJoinOuterGetTuple() will do a
CHECK_FOR_INTERRUPTS, which seems like a good idea to avoid surprises.
Back-patch to all supported branches.
Tom Lane and Thomas Munro
Discussion: https://postgr.es/m/6044.1487121720@sss.pgh.pa.us
M src/backend/executor/nodeHash.c
M src/backend/executor/nodeHashjoin.c
Ignore tablespace ACLs when ignoring schema ACLs.
commit : b167d57d5af09527af61952296f1db8761cbee38
author : Noah Misch <noah@leadboat.com>
date : Sun, 12 Feb 2017 16:03:41 -0500
committer: Noah Misch <noah@leadboat.com>
date : Sun, 12 Feb 2017 16:03:41 -0500
The ALTER TABLE ALTER TYPE implementation can issue DROP INDEX and
CREATE INDEX to refit existing indexes for the new column type. Since
this CREATE INDEX is an implementation detail of an index alteration,
the ensuing DefineIndex() should skip ACL checks specific to index
creation. It already skips the namespace ACL check. Make it skip the
tablespace ACL check, too. Back-patch to 9.2 (all supported versions).
Reviewed by Tom Lane.
M src/backend/commands/indexcmds.c
Correct thinko in last-minute release note item.
commit : 4dd4e3fe10a9d85d5a1455b2231daae8c00c6b79
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Feb 2017 10:24:25 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Feb 2017 10:24:25 -0500
The CREATE INDEX CONCURRENTLY bug can only be triggered by row updates,
not inserts, since the problem would arise from an update incorrectly
being made HOT. Noted by Alvaro.
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml