However, this release corrects a number of potential data
corruption issues. See the first two changelog entries below to
find out whether your installation has been affected and what steps
you can take if so.

Also, if you are upgrading from a version earlier than 9.1.9,
see Section E.67.

Fix VACUUM's tests to see whether it
can update relfrozenxid (Andres
Freund)

In some cases VACUUM (either manual or
autovacuum) could incorrectly advance a table's relfrozenxid value, allowing tuples to escape
freezing, causing those rows to become invisible once 2^31
transactions have elapsed. The probability of data loss is fairly
low since multiple incorrect advancements would need to happen
before actual loss occurs, but it's not zero. Users upgrading from
releases 9.0.4 or 8.4.8 or earlier are not affected, but all later
versions contain the bug.

The issue can be ameliorated by, after upgrading, vacuuming all
tables in all databases while having vacuum_freeze_table_age set to zero. This will
fix any latent corruption but will not be able to fix all
pre-existing data errors. However, an installation can be presumed
safe after performing this vacuuming if it has executed fewer than
2^31 update transactions in its lifetime (check this with
SELECT txid_current() < 2^31).

This bug can cause data loss on standby servers at the moment
they start to accept hot-standby queries, by marking committed
transactions as uncommitted. The likelihood of such corruption is
small unless, at the time of standby startup, the primary server
has executed many updating transactions since its last checkpoint.
Symptoms include missing rows, rows that should have been deleted
being still visible, and obsolete versions of updated rows being
still visible alongside their newer versions.

This bug was introduced in versions 9.3.0, 9.2.5, 9.1.10, and
9.0.14. Standby servers that have only been running earlier
releases are not at risk. It's recommended that standby servers
that have ever run any of the buggy releases be re-cloned from the
primary (e.g., with a new base backup) after upgrading.

In some cases, the system would use the simple GMT offset value
when it should have used the regular timezone setting that had
prevailed before the simple offset was selected. This change also
causes the timeofday function to
honor the simple GMT offset zone.