E.9. Release 8.4.2

Release Date: 2009-12-14

This release contains a variety of fixes from 8.4.1. For information about new features in the 8.4 major release, see Section E.11.

E.9.1. Migration to Version 8.4.2

A dump/restore is not required for those running 8.4.X. However, if you have any hash indexes, you should REINDEX them after updating to 8.4.2, to repair possible damage.

E.9.2. Changes

E.9. Release 8.4.2

Release Date: 2009-12-14

This release contains a variety of fixes from 8.4.1. For information about new features in the 8.4 major release, see Section E.11.

E.9.1. Migration to Version 8.4.2

A dump/restore is not required for those running 8.4.X. However, if you have any hash indexes, you should REINDEX them after updating to 8.4.2, to repair possible damage.

E.9.2. Changes

  • Protect against indirect security threats caused by index functions changing session-local state (Gurjeet Singh, Tom)

    This change prevents allegedly-immutable index functions from possibly subverting a superuser's session (CVE-2009-4136).

  • Reject SSL certificates containing an embedded null byte in the common name (CN) field (Magnus)

    This prevents unintended matching of a certificate to a server or client name during SSL validation (CVE-2009-4034).

  • Fix hash index corruption (Tom)

    The 8.4 change that made hash indexes keep entries sorted by hash value failed to update the bucket splitting and compaction routines to preserve the ordering. So application of either of those operations could lead to permanent corruption of an index, in the sense that searches might fail to find entries that are present. To deal with this, it is recommended to REINDEX any hash indexes you may have after installing this update.

  • Fix possible crash during backend-startup-time cache initialization (Tom)

  • Avoid crash on empty thesaurus dictionary (Tom)

  • Prevent signals from interrupting VACUUM at unsafe times (Alvaro)

    This fix prevents a PANIC if a VACUUM FULL is canceled after it's already committed its tuple movements, as well as transient errors if a plain VACUUM is interrupted after having truncated the table.

  • Fix possible crash due to integer overflow in hash table size calculation (Tom)

    This could occur with extremely large planner estimates for the size of a hashjoin's result.

  • Fix crash if a DROP is attempted on an internally-dependent object (Tom)

  • Fix very rare crash in inet/cidr comparisons (Chris Mikkelson)

  • Ensure that shared tuple-level locks held by prepared transactions are not ignored (Heikki)

  • Fix premature drop of temporary files used for a cursor that is accessed within a subtransaction (Heikki)

  • Fix memory leak in syslogger process when rotating to a new CSV logfile (Tom)

  • Fix memory leak in postmaster when re-parsing pg_hba.conf (Tom)

  • Fix Windows permission-downgrade logic (Jesse Morris)

    This fixes some cases where the database failed to start on Windows, often with misleading error messages such as "could not locate matching postgres executable".

  • Make FOR UPDATE/SHARE in the primary query not propagate into WITH queries (Tom)

    For example, in

    WITH w AS (SELECT * FROM foo) SELECT * FROM w, bar ... FOR UPDATE

    the FOR UPDATE will now affect bar but not foo. This is more useful and consistent than the original 8.4 behavior, which tried to propagate FOR UPDATE into the WITH query but always failed due to assorted implementation restrictions. It also follows the design rule that WITH queries are executed as if independent of the main query.

  • Fix bug with a WITH RECURSIVE query immediately inside another one (Tom)

  • Fix concurrency bug in hash indexes (Tom)

    Concurrent insertions could cause index scans to transiently report wrong results.

  • Fix incorrect logic for GiST index page splits, when the split depends on a non-first column of the index (Paul Ramsey)

  • Fix wrong search results for a multi-column GIN index with fastupdate enabled (Teodor)

  • Fix bugs in WAL entry creation for GIN indexes (Tom)

    These bugs were masked when full_page_writes was on, but with it off a WAL replay failure was certain if a crash occurred before the next checkpoint.

  • Don't error out if recycling or removing an old WAL file fails at the end of checkpoint (Heikki)

    It's better to treat the problem as non-fatal and allow the checkpoint to complete. Future checkpoints will retry the removal. Such problems are not expected in normal operation, but have been