New bug fix releases: 9.1.7, 8.4.15, 8.3.22

Bug #1088393 reported by Martin Pitt on 2012-12-10
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
postgresql-8.3 (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
Unassigned
postgresql-8.4 (Ubuntu)
Undecided
Unassigned
Lucid
Undecided
Unassigned
Precise
Undecided
Unassigned
postgresql-9.1 (Ubuntu)
Undecided
Unassigned
Oneiric
Undecided
Unassigned
Precise
Undecided
Unassigned
Quantal
Undecided
Unassigned
Raring
Undecided
Unassigned

Bug Description

PostgreSQL announced new microreleases some days ago: http://www.postgresql.org/about/news/1430/

As per the standing SRU microrelease exception I would like to update our stable releases with the new versions.

Martin Pitt (pitti) wrote :

Synced 9.1.7-1 from Debian unstable into Raring.

summary: - 9.1.7, 8.4.15, 8.3.22
+ New bug fix releases: 9.1.7, 8.4.15, 8.3.22
no longer affects: postgresql-8.3 (Ubuntu Lucid)
no longer affects: postgresql-8.3 (Ubuntu Oneiric)
no longer affects: postgresql-8.3 (Ubuntu Precise)
no longer affects: postgresql-8.3 (Ubuntu Quantal)
no longer affects: postgresql-8.3 (Ubuntu Raring)
Changed in postgresql-8.3 (Ubuntu):
status: New → Invalid
no longer affects: postgresql-9.1 (Ubuntu Hardy)
no longer affects: postgresql-9.1 (Ubuntu Lucid)
Changed in postgresql-9.1 (Ubuntu Raring):
status: New → Fix Released
no longer affects: postgresql-8.4 (Ubuntu Hardy)
no longer affects: postgresql-8.4 (Ubuntu Raring)
no longer affects: postgresql-8.4 (Ubuntu Quantal)
no longer affects: postgresql-8.4 (Ubuntu Oneiric)
Changed in postgresql-8.4 (Ubuntu):
status: New → Invalid
Martin Pitt (pitti) wrote :

I uploaded the 9.1 updates to the -proposed SRU review queues.

Changed in postgresql-9.1 (Ubuntu Oneiric):
status: New → In Progress
Changed in postgresql-9.1 (Ubuntu Precise):
status: New → In Progress
Martin Pitt (pitti) on 2012-12-10
Changed in postgresql-9.1 (Ubuntu Quantal):
status: New → In Progress
Martin Pitt (pitti) wrote :

I uploaded the two 8.4 updates (lucid/precise) to the SRU review queue.

Changed in postgresql-8.4 (Ubuntu Lucid):
status: New → In Progress
Martin Pitt (pitti) wrote :

8.3/hardy update uploaded to SRU review queue, too.

Changed in postgresql-8.4 (Ubuntu Precise):
status: New → In Progress
Changed in postgresql-8.3 (Ubuntu Hardy):
status: New → In Progress

Hello Martin, or anyone else affected,

Accepted into quantal-proposed. The package will build now and be available in a few hours 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 change the bug tag from verification-needed to verification-done. If it does not, 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
tags: added: verification-needed
Martin Pitt (pitti) wrote :

I'm chasing the test case failure on i386/lpia which caused a build failure:

***************
*** 432,443 ****
  select * from numeric_table
    where num_col in (select float_col from float_table);
           num_col
! -------------------------
                         1
- 1.000000000000000000001
                         2
                         3
! (4 rows)

  --
  -- Test case for bug #4290: bogus calculation of subplan param sets
--- 432,442 ----
  select * from numeric_table
    where num_col in (select float_col from float_table);
   num_col
! ---------
         1
         2
         3
! (3 rows)

The 8.3.21 -> 8.3.22 diff does not touch this part, and indeed building the current hardy-updates version 8.3.21 on current hardy now fails in exactly the same way. This happens in a hardy i386 chroot on raring amd64. So this could be a buildd change or a regression from a hardy-updates package. I'll do some bisecting to see what caused this.

Martin Pitt (pitti) wrote :

precise 8.4 and 9.1 and lucid 8.4 -proposed versions verified with postgresql-common test suite.

tags: added: verification-done-precise verification-failed-hardy
Changed in postgresql-9.1 (Ubuntu Precise):
status: In Progress → Fix Committed
Changed in postgresql-8.4 (Ubuntu Lucid):
status: In Progress → Fix Committed
Changed in postgresql-8.4 (Ubuntu Precise):
status: In Progress → Fix Committed
tags: added: verification-done-lucid
Martin Pitt (pitti) on 2012-12-14
tags: added: verification-done-oneiric verification-done-quantal
tags: removed: verification-needed
Changed in postgresql-9.1 (Ubuntu Oneiric):
status: In Progress → Fix Committed
Martin Pitt (pitti) wrote :

I bisected the hardy failure on i386 and lpia down to this glibc upgrade:

  https://launchpad.net/ubuntu/+source/glibc/2.7-10ubuntu8.2

Both postgresql 8.3.21 and 8.3.22 build fine on hardy final, and fail the same way as in comment 9 on a fully upgraded hardy. Downgrading libc6, libc6-dev, and libc6-i686 from 2.7-10ubuntu8.2 to 2.7-10ubuntu8.1 fixes the bug.

For cross-checking I built 8.3.22 on current raring i386 successfully, so it's not a general i386 problem, but one with hardy specifically. Perhaps the backport of the security patches to hardy were faulty, or make assumptions that are not true on hardy?

Marc Deslauriers (mdeslaur) wrote :

I've located the glibc regression and will publish an update for it on monday.

Marc Deslauriers (mdeslaur) wrote :

(glibc issue tracked in bug #1090740)

Martin Pitt (pitti) wrote :

With hardy's glibc regression now being fixed in -security/-updates, the new postgresql update built fine on i386 and lpia. I ran the p-common regression tests successfully.

Changed in postgresql-8.3 (Ubuntu Hardy):
status: In Progress → Fix Committed
tags: added: verification-done
removed: verification-done-lucid verification-done-oneiric verification-done-precise verification-done-quantal verification-failed-hardy

The verification of this Stable Release Update 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-8.3 - 8.3.22-0ubuntu8.04

---------------
postgresql-8.3 (8.3.22-0ubuntu8.04) hardy-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 the other bug fixes.
 -- Martin Pitt <email address hidden> Mon, 10 Dec 2012 16:16:57 +0100

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

This bug was fixed in the package postgresql-8.4 - 8.4.15-0ubuntu10.04

---------------
postgresql-8.4 (8.4.15-0ubuntu10.04) lucid-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:53:42 +0100

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

This bug was fixed in the package postgresql-8.4 - 8.4.15-0ubuntu12.04

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

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

This bug was fixed in the package postgresql-9.1 - 9.1.7-0ubuntu12.10

---------------
postgresql-9.1 (9.1.7-0ubuntu12.10) quantal-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.
    - Fix buffer locking during WAL replay.
      The WAL replay code was insufficiently careful about locking
      buffers when replaying WAL records that affect more than one page.
      This could result in hot standby queries transiently seeing
      inconsistent states, resulting in wrong answers or unexpected
      failures.
    - See HISTORY/changelog.gz for the other bug fixes.
  * Drop 00git_ecpg_array_bounds.patch, fixed upstream.
 -- Martin Pitt <email address hidden> Mon, 10 Dec 2012 15:00:57 +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.7-0ubuntu11.10

---------------
postgresql-9.1 (9.1.7-0ubuntu11.10) oneiric-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.
    - Fix buffer locking during WAL replay.
      The WAL replay code was insufficiently careful about locking
      buffers when replaying WAL records that affect more than one page.
      This could result in hot standby queries transiently seeing
      inconsistent states, resulting in wrong answers or unexpected
      failures.
    - See HISTORY/changelog.gz for the other bug fixes.
 -- Martin Pitt <email address hidden> Mon, 10 Dec 2012 15:04:42 +0100

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

This bug was fixed in the package postgresql-9.1 - 9.1.7-0ubuntu12.04

---------------
postgresql-9.1 (9.1.7-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.
    - Fix buffer locking during WAL replay.
      The WAL replay code was insufficiently careful about locking
      buffers when replaying WAL records that affect more than one page.
      This could result in hot standby queries transiently seeing
      inconsistent states, resulting in wrong answers or unexpected
      failures.
    - See HISTORY/changelog.gz for the other bug fixes.
  * Drop 00git_ecpg_array_bounds.patch, fixed upstream.
 -- Martin Pitt <email address hidden> Mon, 10 Dec 2012 14:54:49 +0100

Changed in postgresql-9.1 (Ubuntu Precise):
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