However, several of the issues corrected in this release could
have resulted in corruption of foreign-key constraints; that is,
there might now be referencing rows for which there is no matching
row in the referenced table. It may be worthwhile to recheck such
constraints after installing this update. The simplest way to do
that is to drop and recreate each suspect constraint; however, that
will require taking an exclusive lock on both tables, so it is
unlikely to be acceptable in production databases. Alternatively,
you can do a manual join query between the two tables to look for
unmatched rows.

Note also the requirement for replication standby servers to be
upgraded before their master server is upgraded.

Also, if you are upgrading from a version earlier than 9.3.2,
see Section E.24.

Granting a role without ADMIN OPTION is
supposed to prevent the grantee from adding or removing members
from the granted role, but this restriction was easily bypassed by
doing SET ROLE first. The security impact
is mostly that a role member can revoke the access of others,
contrary to the wishes of his grantor. Unapproved role member
additions are a lesser concern, since an uncooperative role member
could provide most of his rights to others anyway by creating views
or SECURITY DEFINER functions.
(CVE-2014-0060)

The primary role of PL validator functions is to be called
implicitly during CREATE FUNCTION, but
they are also normal SQL functions that a user can call explicitly.
Calling a validator on a function actually written in some other
language was not checked for and could be exploited for
privilege-escalation purposes. The fix involves adding a call to a
privilege-checking function in each validator function. Non-core
procedural languages will also need to make this change to their
own validator functions, if any. (CVE-2014-0061)

If the name lookups come to different conclusions due to
concurrent activity, we might perform some parts of the DDL on a
different table than other parts. At least in the case of
CREATE INDEX, this can be used to cause
the permissions checks to be performed against a different table
than the index creation, allowing for a privilege escalation
attack. (CVE-2014-0062)

Prevent buffer overrun with long datetime strings (Noah
Misch)

The MAXDATELEN constant was too small
for the longest possible value of type interval, allowing a buffer overrun in interval_out(). Although the datetime input
functions were more careful about avoiding buffer overrun, the
limit was short enough to cause them to reject some valid inputs,
such as input containing a very long timezone name. The
ecpg library contained these
vulnerabilities along with some of its own. (CVE-2014-0063)

Several functions, mostly type input functions, calculated an
allocation size without checking for overflow. If overflow did
occur, a too-small buffer would be allocated and then written past.
(CVE-2014-0064)

Use strlcpy() and related
functions to provide a clear guarantee that fixed-size buffers are
not overrun. Unlike the preceding items, it is unclear whether
these cases really represent live issues, since in most cases there
appear to be previous constraints on the size of the input string.
Nonetheless it seems prudent to silence all Coverity warnings of
this type. (CVE-2014-0065)

Avoid crashing if crypt() returns
NULL (Honza Horak, Bruce Momjian)

There are relatively few scenarios in which crypt() could return NULL, but contrib/chkpass would crash if it did. One
practical case in which this could be an issue is if libc is configured to refuse to execute
unapproved hashing algorithms (e.g., "FIPS
mode"). (CVE-2014-0066)

Since the temporary server started by make
check uses "trust" authentication,
another user on the same machine could connect to it as database
superuser, and then potentially exploit the privileges of the
operating-system user who started the tests. A future release will
probably incorporate changes in the testing procedure to prevent
this risk, but some public discussion is needed first. So for the
moment, just warn people against using make
check when there are untrusted users on the same machine.
(CVE-2014-0067)

Rework tuple freezing protocol (Álvaro Herrera, Andres
Freund)

The logic for tuple freezing was unable to handle some cases
involving freezing of multixact IDs, with the practical effect that
shared row-level locks might be forgotten once old enough.

Fixing this required changing the WAL record format for tuple
freezing. While this is no issue for standalone servers, when using
replication it means that standby servers must be upgraded to 9.3.3 or
later before their masters are. An older standby will be
unable to interpret freeze records generated by a newer master, and
will fail with a PANIC message. (In such a case, upgrading the
standby should be sufficient to let it resume execution.)

9.3 requires multixact tuple labels to be frozen before they
grow too old, in the same fashion as plain transaction ID labels
have been frozen for some time. Previously, the transaction ID
freezing parameters were used for multixact IDs too; but since the
consumption rates of transaction IDs and multixact IDs can be quite
different, this did not work very well. Introduce new settings
vacuum_multixact_freeze_min_age,
vacuum_multixact_freeze_table_age,
and
autovacuum_multixact_freeze_max_age to control when to freeze
multixacts.

If a row was locked by transaction A, and transaction B updated
it, the new version of the row created by B would be locked by A,
yet visible only to B. If transaction B then again updated the row,
A's lock wouldn't get checked, thus possibly allowing B to complete
when it shouldn't. This case is new in 9.3 since prior versions did
not have any types of row locking that would permit another
transaction to update the row at all.

This oversight could allow referential integrity checks to give
false positives (for instance, allow deletes that should have been
rejected). Applications using the new commands SELECT FOR KEY SHARE and SELECT
FOR NO KEY UPDATE might also have suffered locking failures of
this kind.

Prevent "forgetting" valid row locks
when one of several holders of a row lock aborts (Álvaro
Herrera)

This was yet another mechanism by which a shared row lock could
be lost, thus possibly allowing updates that should have been
prevented by foreign-key constraints.

Fix incorrect logic during update chain locking (Álvaro
Herrera)

This mistake could result in spurious "could
not serialize access due to concurrent update" errors in
REPEATABLE READ and SERIALIZABLE transaction isolation modes.

This fixes a performance regression from pre-9.3 versions when
doing SELECT FOR UPDATE followed by
UPDATE/DELETE.

During archive recovery, prefer highest timeline number when WAL
segments with the same ID are present in both the archive and
pg_xlog/ (Kyotaro Horiguchi)

Previously, not-yet-archived segments could get ignored during
recovery. This reverts an undesirable behavioral change in 9.3.0
back to the way things worked pre-9.3.

Fix possible mis-replay of WAL records when some segments of a
relation aren't full size (Greg Stark, Tom Lane)

The WAL update could be applied to the wrong page, potentially
many pages past where it should have been. Aside from corrupting
data, this error has been observed to result in significant
"bloat" of standby servers compared to
their masters, due to updates being applied far beyond where the
end-of-file should have been. This failure mode does not appear to
be a significant risk during crash recovery, only when initially
synchronizing a standby created from a base backup taken from a
quickly-changing master.

In some cases WAL replay would mistakenly conclude that the
database was already consistent at the start of replay, thus
possibly allowing hot-standby queries before the database was
really consistent. Other symptoms such as "PANIC: WAL contains references to invalid pages"
were also possible.

This is a serious issue for any application making use of
statement timeouts, as it could cause all manner of strange
failures after a timeout occurred. We have seen reports of
"stuck" spinlocks, ERRORs being
unexpectedly promoted to PANICs, unkillable backends, and other
misbehaviors.

Fix race conditions during server process exit (Robert Haas)

Ensure that signal handlers don't attempt to use the process's
MyProc pointer after it's no longer
valid.

Fix possible crash due to invalid plan for nested sub-selects,
such as WHERE (... x IN (SELECT ...) ...) IN
(SELECT ...) (Tom Lane)

Fix mishandling of WHERE conditions
pulled up from a LATERAL subquery (Tom
Lane)

The typical symptom of this bug was a "JOIN
qualification cannot refer to other relations" error, though
subtle logic errors in created plans seem possible as well.

Disallow LATERAL references to the
target table of an UPDATE/DELETE (Tom
Lane)

While this might be allowed in some future release, it was
unintentional in 9.3, and didn't work quite right anyway.

Fix UPDATE/DELETE of an inherited
target table that has UNION ALL subqueries
(Tom Lane)

Without this fix, UNION ALL subqueries
aren't correctly inserted into the update plans for inheritance
child tables after the first one, typically resulting in no update
happening for those child table(s).

Fix ANALYZE to not fail on a column
that's a domain over a range type (Tom Lane)

Ensure that ANALYZE creates statistics
for a table column even when all the values in it are "too wide" (Tom Lane)

ANALYZE intentionally omits very wide
values from its histogram and most-common-values calculations, but
it neglected to do something sane in the case that all the sampled
entries are too wide.

In ALTER TABLE ... SET TABLESPACE,
allow the database's default tablespace to be used without a
permissions check (Stephen Frost)

CREATE TABLE has always allowed such
usage, but ALTER TABLE didn't get the
memo.

Fix support for extensions containing event triggers (Tom
Lane)

Fix "cannot accept a set" error when
some arms of a CASE return a set and
others don't (Tom Lane)

The previous coding might attempt to do catalog access when it
shouldn't.

Accept SHIFT_JIS as an encoding name
for locale checking purposes (Tatsuo Ishii)

Fix *-qualification of named parameters
in SQL-language functions (Tom Lane)

Given a composite-type parameter named foo, $1.* worked fine, but
foo.* not so much.

Fix misbehavior of PQhost() on
Windows (Fujii Masao)

It should return localhost if no host
has been specified.

Improve error handling in libpq
and psql for failures during
COPY TO STDOUT/FROM STDIN (Tom Lane)

In particular this fixes an infinite loop that could occur in
9.2 and up if the server connection was lost during COPY FROM STDIN. Variants of that scenario might be
possible in older versions, or with other client applications.

These text files duplicated the main HTML and PDF documentation
formats. The trouble involved in maintaining them greatly outweighs
the likely audience for plain-text format. Distribution tarballs
will still contain files by these names, but they'll just be stubs
directing the reader to consult the main documentation. The
plain-text INSTALL file will still be
maintained, as there is arguably a use-case for that.

Update time zone data files to tzdata release 2013i for DST law changes in
Jordan and historical changes in Cuba.

In addition, the zones Asia/Riyadh87,
Asia/Riyadh88, and Asia/Riyadh89 have been removed, as they are no
longer maintained by IANA, and never represented actual civil
timekeeping practice.