Package "postgresql-8.4"

  postgresql-8.4 (8.4.19-0ubuntu0.12.04) precise-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 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

  postgresql-8.4 (8.4.18-0ubuntu12.04) precise-proposed; urgency=low

  * New upstream bug fix release (LP: #1237248). No security issues or
    critical issues this time; see HISTORY/changelog.gz for details about bug
    fixes.
 -- Martin Pitt <email address hidden> Wed, 09 Oct 2013 10:12:06 +0200

  postgresql-8.4 (8.4.15-0ubuntu12.04) precise-proposed; urgency=low

  * New upstream bug fix release: (LP: #1088393)
    - Fix multiple bugs associated with "CREATE INDEX CONCURRENTLY"
      Fix "CREATE INDEX CONCURRENTLY" to use in-place updates when
      changing the state of an index's pg_index row. This prevents race
      conditions that could cause concurrent sessions to miss updating
      the target index, thus resulting in corrupt concurrently-created
      indexes.
      Also, fix various other operations to ensure that they ignore
      invalid indexes resulting from a failed "CREATE INDEX CONCURRENTLY"
      command. The most important of these is "VACUUM", because an
      auto-vacuum could easily be launched on the table before corrective
      action can be taken to fix or remove the invalid index.
    - See HISTORY/changelog.gz for details about other bug fixes.
 -- Martin Pitt <email address hidden> Mon, 10 Dec 2012 15:38:48 +0100