New upstream microreleases 9.1.11, 8.4.19

Bug #1257211 reported by Martin Pitt on 2013-12-03
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
postgresql-8.4 (Ubuntu)
Undecided
Unassigned
Lucid
High
Martin Pitt
Precise
High
Martin Pitt
postgresql-9.1 (Ubuntu)
High
Martin Pitt
Precise
High
Unassigned
Quantal
High
Martin Pitt
Raring
High
Martin Pitt
Saucy
High
Martin Pitt
Trusty
High
Martin Pitt

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/

Martin Pitt (pitti) wrote :

As usual, 9.1.11 will get into trusty through Debian sid from syncs.

no longer affects: postgresql-8.4 (Ubuntu Quantal)
no longer affects: postgresql-8.4 (Ubuntu Raring)
no longer affects: postgresql-8.4 (Ubuntu Saucy)
no longer affects: postgresql-8.4 (Ubuntu Trusty)
Changed in postgresql-8.4 (Ubuntu):
status: New → Invalid
Changed in postgresql-9.1 (Ubuntu Trusty):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → High
status: New → In Progress
no longer affects: postgresql-9.1 (Ubuntu Lucid)
Martin Pitt (pitti) on 2013-12-03
Changed in postgresql-9.1 (Ubuntu Saucy):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → High
status: New → In Progress
Changed in postgresql-9.1 (Ubuntu Raring):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → High
status: New → In Progress
Martin Pitt (pitti) on 2013-12-03
Changed in postgresql-9.1 (Ubuntu Quantal):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → High
status: New → In Progress
Martin Pitt (pitti) on 2013-12-03
Changed in postgresql-9.1 (Ubuntu Precise):
importance: Undecided → High
status: New → In Progress
Martin Pitt (pitti) on 2013-12-03
Changed in postgresql-8.4 (Ubuntu Precise):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → High
status: New → In Progress
Martin Pitt (pitti) wrote :

All prepared, tested, ready for upload. Waiting on upstream announcement.

Changed in postgresql-8.4 (Ubuntu Lucid):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → High
status: New → In Progress
Martin Pitt (pitti) on 2013-12-05
description: updated
Martin Pitt (pitti) wrote :

Upstream announcement is out. All uploaded, waiting for SRU team now.

Martin Pitt (pitti) wrote :

9.1.11-1 is being uploaded to Debian unstable as we speak, will autosync in a few hours.

Changed in postgresql-9.1 (Ubuntu Trusty):
status: In Progress → Fix Committed
Martin Pitt (pitti) wrote :

postgresql-9.1 | 9.1.11-1 | trusty | source, amd64, arm64, armhf, i386, powerpc

Changed in postgresql-9.1 (Ubuntu Trusty):
status: Fix Committed → Fix Released

Hello Martin, or anyone else affected,

Accepted postgresql-8.4 into lucid-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/postgresql-8.4/8.4.19-0ubuntu010.04 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in postgresql-8.4 (Ubuntu Lucid):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in postgresql-8.4 (Ubuntu Precise):
status: In Progress → Fix Committed
Adam Conrad (adconrad) wrote :

Hello Martin, or anyone else affected,

Accepted postgresql-8.4 into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/postgresql-8.4/8.4.19-0ubuntu0.12.04 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in postgresql-9.1 (Ubuntu Precise):
status: In Progress → Fix Committed
Adam Conrad (adconrad) wrote :

Hello Martin, or anyone else affected,

Accepted postgresql-9.1 into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/postgresql-9.1/9.1.11-0ubuntu0.12.04 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in postgresql-9.1 (Ubuntu Quantal):
status: In Progress → Fix Committed
Adam Conrad (adconrad) wrote :

Hello Martin, or anyone else affected,

Accepted postgresql-9.1 into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/postgresql-9.1/9.1.11-0ubuntu0.12.10 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in postgresql-9.1 (Ubuntu Raring):
status: In Progress → Fix Committed
Adam Conrad (adconrad) wrote :

Hello Martin, or anyone else affected,

Accepted postgresql-9.1 into raring-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/postgresql-9.1/9.1.11-0ubuntu0.13.04 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in postgresql-9.1 (Ubuntu Saucy):
status: In Progress → Fix Committed
Adam Conrad (adconrad) wrote :

Hello Martin, or anyone else affected,

Accepted postgresql-9.1 into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/postgresql-9.1/9.1.11-0ubuntu0.13.10 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Martin Pitt (pitti) wrote :

I ran the postgresql-common integration tests on all -proposed packages for all releases, no regressions.

tags: added: verification-done
removed: verification-needed
Grant Slater (firefishy) wrote :

Quote: 'urgent "potential data loss" bug fixes'

Launchpad Janitor (janitor) wrote :

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

---------------
postgresql-9.1 (9.1.11-0ubuntu0.13.10) saucy-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 address hidden> Tue, 03 Dec 2013 10:16:56 +0100

Changed in postgresql-9.1 (Ubuntu Saucy):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for postgresql-9.1 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Launchpad Janitor (janitor) wrote :

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 address hidden> Tue, 03 Dec 2013 10:22:12 +0100

Changed in postgresql-9.1 (Ubuntu Raring):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

---------------
postgresql-9.1 (9.1.11-0ubuntu0.12.10) quantal-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 address hidden> Tue, 03 Dec 2013 10:30:25 +0100

Changed in postgresql-9.1 (Ubuntu Quantal):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

---------------
postgresql-9.1 (9.1.11-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 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 address hidden> Tue, 03 Dec 2013 10:37:18 +0100

Changed in postgresql-9.1 (Ubuntu Precise):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package postgresql-8.4 - 8.4.19-0ubuntu0.12.04

---------------
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

Changed in postgresql-8.4 (Ubuntu Precise):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package postgresql-8.4 - 8.4.19-0ubuntu010.04

---------------
postgresql-8.4 (8.4.19-0ubuntu010.04) lucid-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 11:02:52 +0100

Changed in postgresql-8.4 (Ubuntu Lucid):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers