This bug was fixed in the package postgresql-9.1 - 9.1.11-0ubuntu0.13.04

---------------
postgresql-9.1 (9.1.11-0ubuntu0.13.04) raring-proposed; urgency=low

  * 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 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).
    - Fix initialization of "pg_clog" and "pg_subtrans" during hot
      standby startup.
      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.
    - See HISTORY/changelog.gz for details about other bug fixes.
 -- Martin Pitt <[email protected]>   Tue, 03 Dec 2013 10:22:12 +0100

** Changed in: postgresql-9.1 (Ubuntu Raring)
       Status: Fix Committed => Fix Released

** Changed in: postgresql-9.1 (Ubuntu Quantal)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to postgresql-9.1 in Ubuntu.
https://bugs.launchpad.net/bugs/1257211

Title:
  New upstream microreleases 9.1.11, 8.4.19

Status in “postgresql-8.4” package in Ubuntu:
  Invalid
Status in “postgresql-9.1” package in Ubuntu:
  Fix Released
Status in “postgresql-8.4” source package in Lucid:
  Fix Released
Status in “postgresql-8.4” source package in Precise:
  Fix Released
Status in “postgresql-9.1” source package in Precise:
  Fix Released
Status in “postgresql-9.1” source package in Quantal:
  Fix Released
Status in “postgresql-9.1” source package in Raring:
  Fix Released
Status in “postgresql-9.1” source package in Saucy:
  Fix Released
Status in “postgresql-9.1” source package in Trusty:
  Fix Released

Bug description:
  PostgreSQL will announce new upstream microreleases on Thursday. No
  security issues, but this contains urgent "potential data loss" bug
  fixes, the worst of which has been introduced in 9.1.10/8.4.18.

  I'll update the description with the official annoucement once it goes
  public.

  UPDATE: Announcement: http://www.postgresql.org/about/news/1492/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-8.4/+bug/1257211/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to