The previous coding allowed the owner of a foreign server
object, or anyone he has granted server USAGE permission to, to see the options for all user
mappings associated with that server. This might well include
passwords for other users. Adjust the view definition to match the
behavior of information_schema.user_mapping_options, namely
that these options are visible to the user being mapped, or if the
mapping is for PUBLIC and the current user
is the server owner, or if the current user is a superuser.
(CVE-2017-7486)

By itself, this patch will only fix the behavior in newly
initdb'd databases. If you wish to apply this change in an existing
database, follow the corrected procedure shown in the changelog
entry for CVE-2017-7547, in Section
E.8.

Some selectivity estimation functions in the planner will apply
user-defined operators to values obtained from pg_statistic, such as most common values and
histogram entries. This occurs before table permissions are
checked, so a nefarious user could exploit the behavior to obtain
these values for table columns he does not have permission to read.
To fix, fall back to a default estimate if the operator's
implementation function is not certified leak-proof and the calling
user does not have permission to read the table column whose
statistics are needed. At least one of these criteria is satisfied
in most cases in practice. (CVE-2017-7484)

Processing of this environment variable was unintentionally
dropped in PostgreSQL 9.3, but its
documentation remained. This creates a security hazard, since users
might be relying on the environment variable to force SSL-encrypted
connections, but that would no longer be guaranteed. Restore
handling of the variable, but give it lower priority than
PGSSLMODE, to avoid breaking configurations
that work correctly with post-9.3 code. (CVE-2017-7485)

The initial snapshot created for a logical decoding replication
slot was potentially incorrect. This could cause third-party tools
that use logical decoding to copy incomplete/inconsistent initial
data. This was more likely to happen if the source server was busy
at the time of slot creation, or if another logical slot already
existed.

If you are using a replication tool that depends on logical
decoding, and it should have copied a nonempty data set at the
start of replication, it is advisable to recreate the replica after
installing this update, or to verify its contents against the
source server.

In most cases this turned out to have no visible ill effects,
but in corner cases it could result in circular references in
pg_subtrans, potentially causing
infinite loops in queries that examine rows modified by the
two-phase transaction.

Due to lack of a cache flush step between commands in an
extension script file, non-utility queries might not see the
effects of an immediately preceding catalog change, such as
ALTER TABLE ... RENAME.

The command failed if the calling user did not currently have
CREATE privilege for the tablespace
containing the index. That behavior seems unhelpful, so skip the
check, allowing the index to be rebuilt where it is.

Fix ALTER TABLE ... VALIDATE CONSTRAINT
to not recurse to child tables when the constraint is marked
NO INHERIT (Amit Langote)

This fix prevents unwanted "constraint does
not exist" failures when no matching constraint is present
in the child tables.

Avoid dangling pointer in COPY ... TO
when row-level security is active for the source table (Tom
Lane)

Usually this had no ill effects, but sometimes it would cause
unexpected errors or crashes.

Avoid accessing an already-closed relcache entry in CLUSTER and VACUUM FULL
(Tom Lane)

With some bad luck, this could lead to indexes on the target
relation getting rebuilt with the wrong persistence setting.

Fix VACUUM to account properly for
pages that could not be scanned due to conflicting page pins
(Andrew Gierth)

This tended to lead to underestimation of the number of tuples
in the table. In the worst case of a small heavily-contended table,
VACUUM could incorrectly report that the
table contained no tuples, leading to very bad planning
choices.

The comparison operators for type interval
could yield wrong answers for intervals larger than about 296000
years. Indexes on columns containing such large values should be
reindexed, since they may be corrupt.

In pg_dump, fix incorrect
schema and owner marking for comments and security labels of some
types of database objects (Giuseppe Broccolo, Tom Lane)

In simple cases this caused no ill effects; but for example, a
schema-selective restore might omit comments it should include,
because they were not marked as belonging to the schema of their
associated object.

Update time zone data files to tzdata release 2017b for DST law changes in
Chile, Haiti, and Mongolia, plus historical corrections for
Ecuador, Kazakhstan, Liberia, and Spain. Switch to numeric
abbreviations for numerous time zones in South America, the Pacific
and Indian oceans, and some Asian and Middle Eastern countries.

The IANA time zone database previously provided textual
abbreviations for all time zones, sometimes making up abbreviations
that have little or no currency among the local population. They
are in process of reversing that policy in favor of using numeric
UTC offsets in zones where there is no evidence of real-world use
of an English abbreviation. At least for the time being,
PostgreSQL will continue to accept
such removed abbreviations for timestamp input. But they will not
be shown in the pg_timezone_names view
nor used for output.

The Microsoft MSVC build scripts neglected to install the
posixrules file in the timezone directory
tree. This resulted in the timezone code falling back to its
built-in rule about what DST behavior to assume for a POSIX-style
time zone name. For historical reasons that still corresponds to
the DST rules the USA was using before 2007 (i.e., change on first
Sunday in April and last Sunday in October). With this fix, a
POSIX-style zone name will use the current and historical DST
transition dates of the US/Eastern zone.
If you don't want that, remove the posixrules file, or replace it with a copy of some
other zone file (see Section 8.5.3).
Note that due to caching, you may need to restart the server to get
such changes to take effect.

Submit correction

If you see anything in the documentation that is not correct, does not match
your experience with the particular feature or requires further clarification,
please use
this form
to report a documentation issue.