Revert restructuring of bin/scripts/Makefile
commit : 5181bebba73b2fdcb38f4c7f06491e8092873969
author : Magnus Hagander <[email protected]>
date : Tue, 27 Feb 2018 14:08:53 +0100
committer: Magnus Hagander <[email protected]>
date : Tue, 27 Feb 2018 14:08:53 +0100
The Makefile portion of 91f3ffc5249eff99c311fb27e7b29a44d9c62be1 broke
the MSVC build. This patch reverts the changes to the Makefile and
adjusts it to work with the new code, while keeping the actual code
changes from the original patch.
Author: Victor Wagner <[email protected]>
M src/bin/scripts/Makefile
Stamp 9.4.17.
commit : f46bc90dbcf48766abcddc0221edc66dbffb4785
author : Tom Lane <[email protected]>
date : Mon, 26 Feb 2018 17:17:45 -0500
committer: Tom Lane <[email protected]>
date : Mon, 26 Feb 2018 17:17:45 -0500
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc
Last-minute updates for release notes.
commit : dfebb71692724081374a391b1a8549a467bc1d08
author : Tom Lane <[email protected]>
date : Mon, 26 Feb 2018 12:14:05 -0500
committer: Tom Lane <[email protected]>
date : Mon, 26 Feb 2018 12:14:05 -0500
Security: CVE-2018-1058
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
Document security implications of search_path and the public schema.
commit : f28955e382ee4249ab4283a85664e43c1f635ee9
author : Noah Misch <[email protected]>
date : Mon, 26 Feb 2018 07:39:44 -0800
committer: Noah Misch <[email protected]>
date : Mon, 26 Feb 2018 07:39:44 -0800
The ability to create like-named objects in different schemas opens up
the potential for users to change the behavior of other users' queries,
maliciously or accidentally. When you connect to a PostgreSQL server,
you should remove from your search_path any schema for which a user
other than yourself or superusers holds the CREATE privilege. If you do
not, other users holding CREATE privilege can redefine the behavior of
your commands, causing them to perform arbitrary SQL statements under
your identity. "SET search_path = ..." and "SELECT
pg_catalog.set_config(...)" are not vulnerable to such hijacking, so one
can use either as the first command of a session. As special
exceptions, the following client applications behave as documented
regardless of search_path settings and schema privileges: clusterdb
createdb createlang createuser dropdb droplang dropuser ecpg (not
programs it generates) initdb oid2name pg_archivecleanup pg_basebackup
pg_config pg_controldata pg_ctl pg_dump pg_dumpall pg_isready
pg_receivewal pg_recvlogical pg_resetwal pg_restore pg_rewind pg_standby
pg_test_fsync pg_test_timing pg_upgrade pg_waldump reindexdb vacuumdb
vacuumlo. Not included are core client programs that run user-specified
SQL commands, namely psql and pgbench. PostgreSQL encourages non-core
client applications to do likewise.
Document this in the context of libpq connections, psql connections,
dblink connections, ECPG connections, extension packaging, and schema
usage patterns. The principal defense for applications is "SELECT
pg_catalog.set_config('search_path', '', false)", and the principal
defense for databases is "REVOKE CREATE ON SCHEMA public FROM PUBLIC".
Either one is sufficient to prevent attack. After a REVOKE, consider
auditing the public schema for objects named like pg_catalog objects.
Authors of SECURITY DEFINER functions use some of the same defenses, and
the CREATE FUNCTION reference page already covered them thoroughly.
This is a good opportunity to audit SECURITY DEFINER functions for
robust security practice.
Back-patch to 9.3 (all supported versions).
Reviewed by Michael Paquier and Jonathan S. Katz. Reported by Arseniy
Sharoglazov.
Security: CVE-2018-1058
M doc/src/sgml/config.sgml
M doc/src/sgml/contrib.sgml
M doc/src/sgml/dblink.sgml
M doc/src/sgml/ddl.sgml
M doc/src/sgml/ecpg.sgml
M doc/src/sgml/extend.sgml
M doc/src/sgml/libpq.sgml
M doc/src/sgml/lobj.sgml
M doc/src/sgml/pgbench.sgml
M doc/src/sgml/ref/psql-ref.sgml
M doc/src/sgml/user-manag.sgml
M src/test/examples/testlibpq.c
M src/test/examples/testlibpq2.c
M src/test/examples/testlibpq2.sql
M src/test/examples/testlibpq3.c
M src/test/examples/testlibpq3.sql
M src/test/examples/testlibpq4.c
M src/test/examples/testlo.c
M src/test/examples/testlo64.c
Empty search_path in Autovacuum and non-psql/pgbench clients.
commit : 928bca1a30d7e05cc3857a99e27aa8ed08ed2fac
author : Noah Misch <[email protected]>
date : Mon, 26 Feb 2018 07:39:44 -0800
committer: Noah Misch <[email protected]>
date : Mon, 26 Feb 2018 07:39:44 -0800
This makes the client programs behave as documented regardless of the
connect-time search_path and regardless of user-created objects. Today,
a malicious user with CREATE permission on a search_path schema can take
control of certain of these clients' queries and invoke arbitrary SQL
functions under the client identity, often a superuser. This is
exploitable in the default configuration, where all users have CREATE
privilege on schema "public".
This changes behavior of user-defined code stored in the database, like
pg_index.indexprs and pg_extension_config_dump(). If they reach code
bearing unqualified names, "does not exist" or "no schema has been
selected to create in" errors might appear. Users may fix such errors
by schema-qualifying affected names. After upgrading, consider watching
server logs for these errors.
The --table arguments of src/bin/scripts clients have been lax; for
example, "vacuumdb -Zt pg_am\;CHECKPOINT" performed a checkpoint. That
now fails, but for now, "vacuumdb -Zt 'pg_am(amname);CHECKPOINT'" still
performs a checkpoint.
Back-patch to 9.3 (all supported versions).
Reviewed by Tom Lane, though this fix strategy was not his first choice.
Reported by Arseniy Sharoglazov.
Security: CVE-2018-1058
M contrib/oid2name/oid2name.c
M contrib/pg_upgrade/server.c
M contrib/vacuumlo/vacuumlo.c
M src/backend/postmaster/autovacuum.c
M src/bin/pg_basebackup/streamutil.c
M src/bin/pg_dump/dumputils.c
M src/bin/pg_dump/pg_backup_db.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/scripts/Makefile
M src/bin/scripts/clusterdb.c
M src/bin/scripts/common.c
M src/bin/scripts/common.h
M src/bin/scripts/createdb.c
M src/bin/scripts/createlang.c
M src/bin/scripts/createuser.c
M src/bin/scripts/dropdb.c
M src/bin/scripts/droplang.c
M src/bin/scripts/dropuser.c
M src/bin/scripts/reindexdb.c
M src/bin/scripts/t/010_clusterdb.pl
M src/bin/scripts/t/090_reindexdb.pl
M src/bin/scripts/t/100_vacuumdb.pl
M src/bin/scripts/vacuumdb.c
M src/include/Makefile
A src/include/fe_utils/connect.h
M src/tools/findoidjoins/findoidjoins.c
Back-patch non-static ExecuteSqlQueryForSingleRow().
commit : 461c32b557ddbb0ed67b4b2232a191554ad40c3c
author : Noah Misch <[email protected]>
date : Mon, 26 Feb 2018 07:39:48 -0800
committer: Noah Misch <[email protected]>
date : Mon, 26 Feb 2018 07:39:48 -0800
Back-patch a subset of commit 47e59697679a0877e0525c565b1be437487604a7
to 9.4 and 9.3. The next commit adds calls to this function.
Security: CVE-2018-1058
M src/bin/pg_dump/pg_backup_db.c
M src/bin/pg_dump/pg_backup_db.h
M src/bin/pg_dump/pg_dump.c
Avoid using unsafe search_path settings during dump and restore.
commit : 9f6e5296a15f541b04ecdfc077957ccaf2f6e49a
author : Tom Lane <[email protected]>
date : Mon, 26 Feb 2018 10:18:22 -0500
committer: Tom Lane <[email protected]>
date : Mon, 26 Feb 2018 10:18:22 -0500
Historically, pg_dump has "set search_path = foo, pg_catalog" when
dumping an object in schema "foo", and has also caused that setting
to be used while restoring the object. This is problematic because
functions and operators in schema "foo" could capture references meant
to refer to pg_catalog entries, both in the queries issued by pg_dump
and those issued during the subsequent restore run. That could
result in dump/restore misbehavior, or in privilege escalation if a
nefarious user installs trojan-horse functions or operators.
This patch changes pg_dump so that it does not change the search_path
dynamically. The emitted restore script sets the search_path to what
was used at dump time, and then leaves it alone thereafter. Created
objects are placed in the correct schema, regardless of the active
search_path, by dint of schema-qualifying their names in the CREATE
commands, as well as in subsequent ALTER and ALTER-like commands.
Since this change requires a change in the behavior of pg_restore
when processing an archive file made according to this new convention,
bump the archive file version number; old versions of pg_restore will
therefore refuse to process files made with new versions of pg_dump.
Security: CVE-2018-1058
M src/backend/utils/adt/ruleutils.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_archiver.h
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dumpall.c
M src/test/regress/expected/collate.linux.utf8.out
M src/test/regress/expected/collate.out
M src/test/regress/expected/rules.out
M src/test/regress/expected/triggers.out
Translation updates
commit : fd090d0d6f719c83b5e28f58c3e72f52296951e6
author : Peter Eisentraut <[email protected]>
date : Mon, 26 Feb 2018 08:37:35 -0500
committer: Peter Eisentraut <[email protected]>
date : Mon, 26 Feb 2018 08:37:35 -0500
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: e859c0a3a8ac0fc7ae28150aff33153ec532ef04
M src/bin/psql/po/fr.po
M src/interfaces/ecpg/preproc/po/fr.po
M src/pl/plpgsql/src/po/ru.po
Release notes for 10.3, 9.6.8, 9.5.12, 9.4.17, 9.3.22.
commit : 548e849557b03f86e6214bc6608a20e724329915
author : Tom Lane <[email protected]>
date : Sun, 25 Feb 2018 14:52:51 -0500
committer: Tom Lane <[email protected]>
date : Sun, 25 Feb 2018 14:52:51 -0500
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
Allow auto_explain.log_min_duration to go up to INT_MAX.
commit : 3ba503bde9aede23db6d35c00706daab15015f35
author : Tom Lane <[email protected]>
date : Fri, 23 Feb 2018 14:38:19 -0500
committer: Tom Lane <[email protected]>
date : Fri, 23 Feb 2018 14:38:19 -0500
The previous limit of INT_MAX / 1000 seems to have been cargo-culted in
from somewhere else. Or possibly the value was converted to microseconds
at some point; but in all supported releases, it's just compared to other
values, so there's no need for the restriction. This change raises the
effective limit from ~35 minutes to ~24 days, which conceivably is useful
to somebody, and anyway it's more consistent with the range of the core
log_min_duration_statement GUC.
Per complaint from Kevin Bloch. Back-patch to all supported releases.
Discussion: https://postgr.es/m/[email protected]
M contrib/auto_explain/auto_explain.c
Synchronize doc/ copies of src/test/examples/.
commit : da27155c6b79e84f29bd71eab662b23f3da970e8
author : Noah Misch <[email protected]>
date : Fri, 23 Feb 2018 11:24:04 -0800
committer: Noah Misch <[email protected]>
date : Fri, 23 Feb 2018 11:24:04 -0800
This is mostly cosmetic, but it might fix build failures, on some
platform, when copying from the documentation.
Back-patch to 9.3 (all supported versions).
M doc/src/sgml/libpq.sgml
M src/test/examples/testlibpq2.sql
Fix planner failures with overlapping mergejoin clauses in an outer join.
commit : f6dd08489c8023fdaf1cb191392d5b0785c8e0ec
author : Tom Lane <[email protected]>
date : Fri, 23 Feb 2018 13:47:33 -0500
committer: Tom Lane <[email protected]>
date : Fri, 23 Feb 2018 13:47:33 -0500
Given overlapping or partially redundant join clauses, for example
t1 JOIN t2 ON t1.a = t2.x AND t1.b = t2.x
the planner's EquivalenceClass machinery will ordinarily refactor the
clauses as "t1.a = t1.b AND t1.a = t2.x", so that join processing doesn't
see multiple references to the same EquivalenceClass in a list of join
equality clauses. However, if the join is outer, it's incorrect to derive
a restriction clause on the outer side from the join conditions, so the
clause refactoring does not happen and we end up with overlapping join
conditions. The code that attempted to deal with such cases had several
subtle bugs, which could result in "left and right pathkeys do not match in
mergejoin" or "outer pathkeys do not match mergeclauses" planner errors,
if the selected join plan type was a mergejoin. (It does not appear that
any actually incorrect plan could have been emitted.)
The core of the problem really was failure to recognize that the outer and
inner relations' pathkeys have different relationships to the mergeclause
list. A join's mergeclause list is constructed by reference to the outer
pathkeys, so it will always be ordered the same as the outer pathkeys, but
this cannot be presumed true for the inner pathkeys. If the inner sides of
the mergeclauses contain multiple references to the same EquivalenceClass
({t2.x} in the above example) then a simplistic rendering of the required
inner sort order is like "ORDER BY t2.x, t2.x", but the pathkey machinery
recognizes that the second sort column is redundant and throws it away.
The mergejoin planning code failed to account for that behavior properly.
One error was to try to generate cut-down versions of the mergeclause list
from cut-down versions of the inner pathkeys in the same way as the initial
construction of the mergeclause list from the outer pathkeys was done; this
could lead to choosing a mergeclause list that fails to match the outer
pathkeys. The other problem was that the pathkey cross-checking code in
create_mergejoin_plan treated the inner and outer pathkey lists
identically, whereas actually the expectations for them must be different.
That led to false "pathkeys do not match" failures in some cases, and in
principle could have led to failure to detect bogus plans in other cases,
though there is no indication that such bogus plans could be generated.
Reported by Alexander Kuzmenkov, who also reviewed this patch. This has
been broken for years (back to around 8.3 according to my testing), so
back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/path/joinpath.c
M src/backend/optimizer/path/pathkeys.c
M src/backend/optimizer/plan/createplan.c
M src/include/optimizer/paths.h
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Repair pg_upgrade's failure to preserve relfrozenxid for matviews.
commit : 2d12c559335e29536f558f07fe053574c142883d
author : Tom Lane <[email protected]>
date : Wed, 21 Feb 2018 18:40:24 -0500
committer: Tom Lane <[email protected]>
date : Wed, 21 Feb 2018 18:40:24 -0500
This oversight led to data corruption in matviews, manifesting as
"could not access status of transaction" before our most recent releases,
and "found xmin from before relfrozenxid" errors since then.
The proximate cause of the problem seems to have been confusion between
the task of preserving dropped-column status and the task of preserving
frozenxid status. Those are required for distinct sets of relkinds,
and the reasoning was entirely undocumented in the source code. In hopes
of forestalling future errors of the same kind, try to improve the
commentary in this area.
In passing, also improve the remarkably unhelpful comments around
pg_upgrade's set_frozenxids(). That's not actually buggy AFAICS,
but good luck figuring out what it does from the old comments.
Per report from Claudio Freire. It appears that bug #14852 from Alexey
Ermakov is an earlier report of the same issue, and there may be other
cases that we failed to identify at the time.
Patch by me based on analysis by Andres Freund. The bug dates back
to the introduction of matviews, so back-patch to all supported branches.
Discussion: https://postgr.es/m/CAGTBQpbrY9CdRGGhyBZ9yqY4jWaGC85rUF4X+R7d-aim=mBNsw@mail.gmail.com
Discussion: https://postgr.es/m/[email protected]
M contrib/pg_upgrade/pg_upgrade.c
M src/bin/pg_dump/pg_dump.c
Fix misbehavior of CTE-used-in-a-subplan during EPQ rechecks.
commit : e11b6488e5a70f870bc7069d7f08a9570ccd3fc2
author : Tom Lane <[email protected]>
date : Mon, 19 Feb 2018 16:00:18 -0500
committer: Tom Lane <[email protected]>
date : Mon, 19 Feb 2018 16:00:18 -0500
An updating query that reads a CTE within an InitPlan or SubPlan could get
incorrect results if it updates rows that are concurrently being modified.
This is caused by CteScanNext supposing that nothing inside its recursive
ExecProcNode call could change which read pointer is selected in the CTE's
shared tuplestore. While that's normally true because of scoping
considerations, it can break down if an EPQ plan tree gets built during the
call, because EvalPlanQualStart builds execution trees for all subplans
whether they're going to be used during the recheck or not. And it seems
like a pretty shaky assumption anyway, so let's just reselect our own read
pointer here.
Per bug #14870 from Andrei Gorita. This has been broken since CTEs were
implemented, so back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/executor/nodeCtescan.c
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/specs/eval-plan-qual.spec
Doc: fix minor bug in CREATE TABLE example.
commit : 1bb87c0fae5e242b49518a12348f41231f90d45d
author : Tom Lane <[email protected]>
date : Thu, 15 Feb 2018 13:56:38 -0500
committer: Tom Lane <[email protected]>
date : Thu, 15 Feb 2018 13:56:38 -0500
One example in create_table.sgml claimed to be showing table constraint
syntax, but it was really column constraint syntax due to the omission
of a comma. This is both wrong and confusing, so fix it in all
supported branches.
Per report from [email protected].
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/create_table.sgml
Fix broken logic for reporting PL/Python function names in errcontext.
commit : bd871863787bc09ababd7e81a189492a1cd08803
author : Tom Lane <[email protected]>
date : Wed, 14 Feb 2018 14:47:18 -0500
committer: Tom Lane <[email protected]>
date : Wed, 14 Feb 2018 14:47:18 -0500
plpython_error_callback() reported the name of the function associated
with the topmost PL/Python execution context. This was not merely
wrong if there were nested PL/Python contexts, but it risked a core
dump if the topmost one is an inline code block rather than a named
function. That will have proname = NULL, and so we were passing a NULL
pointer to snprintf("%s"). It seems that none of the PL/Python-testing
machines in the buildfarm will dump core for that, but some platforms do,
as reported by Marina Polyakova.
Investigation finds that there actually is an existing regression test
that used to prove that the behavior was wrong, though apparently no one
had noticed that it was printing the wrong function name. It stopped
showing the problem in 9.6 when we adjusted psql to not print CONTEXT
by default for NOTICE messages. The problem is masked (if your platform
avoids the core dump) in error cases, because PL/Python will throw away
the originally generated error info in favor of a new traceback produced
at the outer level.
Repair by using ErrorContextCallback.arg to pass the correct context to
the error callback. Add a regression test illustrating correct behavior.
Back-patch to all supported branches, since they're all broken this way.
Discussion: https://postgr.es/m/[email protected]
M src/pl/plpython/expected/plpython_error.out
M src/pl/plpython/expected/plpython_error_0.out
M src/pl/plpython/expected/plpython_error_5.out
M src/pl/plpython/expected/plpython_subtransaction.out
M src/pl/plpython/plpy_main.c
M src/pl/plpython/plpy_procedure.c
M src/pl/plpython/sql/plpython_error.sql
Change default git repo URL to https
commit : 581189327a1902381c71bf76894aabd4e6d8cf36
author : Magnus Hagander <[email protected]>
date : Wed, 7 Feb 2018 11:03:55 +0100
committer: Magnus Hagander <[email protected]>
date : Wed, 7 Feb 2018 11:03:55 +0100
Since we now support the server side handler for git over https (so
we're no longer using the "dumb protocol"), make https the primary
choice for cloning the repository, and the git protocol the secondary
choice.
In passing, also change the links to git-scm.com from http to https.
Reviewed by Stefan Kaltenbrunner and David G. Johnston
M doc/src/sgml/sourcerepo.sgml