[ubuntu/oneiric-security] postgresql-9.1 9.1.8-0ubuntu11.10 (Accepted)

[Marc Deslauriers]

postgresql-9.1 (9.1.8-0ubuntu11.10) oneiric-security; urgency=low

  * New upstream security/bug fix release: (LP: #1116336)
    - Prevent execution of enum_recv from SQL
      The function was misdeclared, allowing a simple SQL command to crash the
      server.  In principle an attacker might be able to use it to examine the
      contents of server memory.  Our thanks to Sumit Soni (via Secunia SVCRP)
      for reporting this issue. (CVE-2013-0255)
    - See HISTORY/changelog.gz for the other bug fixes.

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.

postgresql-9.1 (9.1.6-0ubuntu11.10) oneiric-proposed; urgency=low

  * New upstream bug fix release: (LP: #1055944)
    - Fix persistence marking of shared buffers during WAL replay.
      This mistake can result in buffers not being written out during
      checkpoints, resulting in data corruption if the server later
      crashes without ever having written those buffers. Corruption can
      occur on any server following crash recovery, but it is
      significantly more likely to occur on standby slave servers since
      those perform much more WAL replay. There is a low probability of
      corruption of btree and GIN indexes. There is a much higher
      probability of corruption of table "visibility maps". Fortunately,
      visibility maps are non-critical data in 9.1, so the worst
      consequence of such corruption in 9.1 installations is transient
      inefficiency of vacuuming. Table data proper cannot be corrupted by
      this bug.
      While no index corruption due to this bug is known to have occurred
      in the field, as a precautionary measure it is recommended that
      production installations "REINDEX" all btree and GIN indexes at a
      convenient time after upgrading to 9.1.6.
      Also, if you intend to do an in-place upgrade to 9.2.X, before
      doing so it is recommended to perform a "VACUUM" of all tables
      while having vacuum_freeze_table_age set to zero. This will ensure
      that any lingering wrong data in the visibility maps is corrected
      before 9.2.X can depend on it. vacuum_cost_delay can be adjusted to
      reduce the performance impact of vacuuming, while causing it to
      take longer to finish.
    - See HISTORY/changelog.gz for the other bug fixes.

Date: 2013-02-07 16:40:18.005204+00:00
Changed-By: Martin Pitt <martin.pitt at ubuntu.com>
Signed-By: Marc Deslauriers <marc.deslauriers at canonical.com>
https://launchpad.net/ubuntu/oneiric/+source/postgresql-9.1/9.1.8-0ubuntu11.10
-------------- next part --------------
Sorry, changesfile not available.