The PostgreSQL Global Development Group has released an update to all current versions of the PostgreSQL database system, including versions 9.2.2, 9.1.7, 9.0.11, 8.4.15, and 8.3.22. Users of PostgreSQL Hot Standby replication should update at the next possible opportunity. Other users should update at their next maintenance window.
This release fixes a significant page ordering issue with Hot Standby which could cause index corruption on the standby under some circumstances. In addition, this update patches timing issues with checkpoint and transaction ID wraparound which could cause data corruption in some cases. Today's update also fixes multiple issues with CREATE INDEX CONCURRENTLY and DROP INDEX CONCURRENTLY, which can cause those commands to fail or produce corrupt indexes. Users who use this feature may want to REINDEX or recreate affected indexes (see below).
This update release also contains fixes for many minor issues discovered and patched by the PostgreSQL community in the last month, including several fixes which are specific to version 9.2. These include:
PostgreSQL 8.3 will be End-Of-Life (EOL) in February 2013. As such, this update is likely to be the next-to-last update for that version. We urge users of version 8.3 to begin planning a full upgrade to a more current version of PostgreSQL now. For more information, see our Versioning Policy.
As with other minor releases, users are not required to dump and reload their database or use pg_upgrade in order to apply this update release; you may simply shut down PostgreSQL and update its binaries. Users who have skipped multiple update releases may need to perform additional, post-update steps; see the Release Notes for details.
Users who have used CREATE INDEX CONCURRENTLY extensively may want to REINDEX, or drop and re-create, indexes which were created using CREATE INDEX CONCURRENTLY after applying the update in order to be sure of their integrity. Unfortunately, indexes created concurrently are indistinguishable from indexes created non-concurrently, so users will need to rely on DBA knowledge. Once the update is applied, users can create the new index concurrently and then drop the old index concurrently to avoid downtime.