* 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-0ubuntu11.10
--------------- 0ubuntu11. 10) oneiric-proposed; urgency=low
postgresql-9.1 (9.1.7-
* New upstream bug fix release: (LP: #1088393) created changelog. gz for the other bug fixes.
- 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-
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/
-- Martin Pitt <email address hidden> Mon, 10 Dec 2012 15:04:42 +0100