Ubuntu
postgresql-9.1 package

  1. Bug #1055944
  2. Comment #21

Comment 21 for bug 1055944

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package postgresql-8.4 - 8.4.14-0ubuntu12.04.1

---------------
postgresql-8.4 (8.4.14-0ubuntu12.04.1) precise-proposed; urgency=low

  * debian/postgresql-8.4.preinst: Do not only clean up the old -8.4 specific
    init script when upgrading from << 8.4.4-2, as we have newer upstream
    versions in lucid-updates. Instead, remove the version specific init
    script if we have the versionless one from postgresql-common. This fixes
    postgresql-8.4 not restarting after the upgrade. (LP: #1058218)

postgresql-8.4 (8.4.14-0ubuntu12.04) precise-proposed; urgency=low

  * New upstream bug fix release: (LP: #1058218, #1055944)
    - Fix planner's assignment of executor parameters, and fix executor's
      rescan logic for CTE plan nodes.
      These errors could result in wrong answers from queries that scan
      the same WITH subquery multiple times.
    - Improve page-splitting decisions in GiST indexes.
      Multi-column GiST indexes might suffer unexpected bloat due to this
      error.
    - Fix cascading privilege revoke to stop if privileges are still held.
      If we revoke a grant option from some role "X", but "X" still holds
      that option via a grant from someone else, we should not
      recursively revoke the corresponding privilege from role(s) "Y"
      that "X" had granted it to.
    - Fix handling of SIGFPE when PL/Perl is in use.
      Perl resets the process's SIGFPE handler to SIG_IGN, which could
      result in crashes later on. Restore the normal Postgres signal
      handler after initializing PL/Perl.
    - Prevent PL/Perl from crashing if a recursive PL/Perl function is
      redefined while being executed.
    - Work around possible misoptimization in PL/Perl.
      Some Linux distributions contain an incorrect version of
      "pthread.h" that results in incorrect compiled code in PL/Perl,
      leading to crashes if a PL/Perl function calls another one that
      throws an error.
 -- Martin Pitt <email address hidden> Thu, 04 Oct 2012 08:47:19 +0200