New bug fix releases: 9.1.7, 8.4.15, 8.3.22

Synced 9.1.7-1 from Debian unstable into Raring.

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

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

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

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!

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.

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

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?

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

(glibc issue tracked in bug #1090740)

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.

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.

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

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

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

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

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

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