* New upstream bug fix release (LP: #1257211)
- Fix "VACUUM"'s tests to see whether it can update relfrozenxid.
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 release 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).
- See HISTORY/changelog.gz for details about bug fixes.
-- Martin Pitt <email address hidden> Tue, 03 Dec 2013 10:44:58 +0100
This bug was fixed in the package postgresql-8.4 - 8.4.19- 0ubuntu0. 12.04
--------------- 0ubuntu0. 12.04) precise-proposed; urgency=low
postgresql-8.4 (8.4.19-
* New upstream bug fix release (LP: #1257211) freeze_ table_age set to changelog. gz for details about bug fixes.
- Fix "VACUUM"'s tests to see whether it can update relfrozenxid.
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 release 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_
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).
- See HISTORY/
-- Martin Pitt <email address hidden> Tue, 03 Dec 2013 10:44:58 +0100