However, this release corrects several errors in management
of GiST indexes. After installing this update, it is advisable
to REINDEX any GiST indexes that meet
one or more of the conditions described below.

Also, if you are upgrading from a version earlier than
9.2.2, see Section E.23.

A connection request containing a database name that
begins with "-" could be crafted to damage or
destroy files within the server's data directory, even if
the request is eventually rejected. (CVE-2013-1899)

This avoids a scenario wherein random numbers generated
by contrib/pgcrypto functions
might be relatively easy for another database user to
guess. The risk is only significant when the postmaster is
configured with ssl = on but most connections don't use SSL
encryption. (CVE-2013-1900)

An unprivileged database user could exploit this mistake
to call pg_start_backup() or
pg_stop_backup(), thus
possibly interfering with creation of routine backups.
(CVE-2013-1901)

Fix GiST indexes to not use "fuzzy" geometric comparisons when it's not
appropriate to do so (Alexander Korotkov)

The core geometric types perform comparisons using
"fuzzy" equality, but
gist_box_same must do exact
comparisons, else GiST indexes using it might become
inconsistent. After installing this update, users should
REINDEX any GiST indexes on
box, polygon,
circle, or point columns, since all of these use
gist_box_same.

Fix erroneous range-union and penalty logic in GiST
indexes that use contrib/btree_gist for variable-width data
types, that is text, bytea, bit, and
numeric columns (Tom Lane)

These errors could result in inconsistent indexes in
which some keys that are present would not be found by
searches, and also in useless index bloat. Users are
advised to REINDEX such indexes
after installing this update.

These errors could result in inconsistent indexes in
which some keys that are present would not be found by
searches, and also in indexes that are unnecessarily
inefficient to search. Users are advised to REINDEX multi-column GiST indexes after
installing this update.

Index scans on GiST indexes on point columns would sometimes yield results
different from a sequential scan, because gist_point_consistent disagreed with the
underlying operator code about whether to do comparisons
exactly or fuzzily.

Fix buffer leak in WAL replay (Heikki Linnakangas)

This bug could result in "incorrect
local pin count" errors during replay, making
recovery impossible.

Ensure we do crash recovery before entering archive
recovery, if the database was not stopped cleanly and a
recovery.conf file is present
(Heikki Linnakangas, Kyotaro Horiguchi, Mitsumasa
Kondo)

This is needed to ensure that the database is consistent
in certain scenarios, such as initializing a standby server
with a filesystem snapshot from a running server.

Under the right circumstances, DELETE RETURNING could attempt to fetch data
from a shared buffer that the current process no longer has
any pin on. If some other process changed the buffer
meanwhile, this would lead to garbage RETURNING output, or even a crash.

This message seems to have been added in expectation of
code that was never written, and probably never will be,
since GiST's default handling of secondary splits is
actually pretty good. So stop nagging end users about
it.

Dumping invalid indexes can cause problems at restore
time, for example if the reason the index creation failed
was because it tried to enforce a uniqueness condition not
satisfied by the table's data. Also, if the index creation
is in fact still in progress, it seems reasonable to
consider it to be an uncommitted DDL change, which
pg_dump wouldn't be
expected to dump anyway. pg_upgrade now also skips invalid
indexes rather than failing.

In pg_basebackup,
include only the current server version's subdirectory when
backing up a tablespace (Heikki Linnakangas)

Add a server version check in pg_basebackup and pg_receivexlog, so they fail cleanly
with version combinations that won't work (Heikki
Linnakangas)

Previously, if the remote server had different settings
of these parameters, ambiguous dates might be read
incorrectly. This fix ensures that datetime and interval
columns fetched by a dblink query
will be interpreted correctly. Note however that
inconsistent settings are still risky, since literal values
appearing in SQL commands sent to the remote server might
be interpreted differently than they would be locally.

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.