リリース日: 2011-01-31
このリリースは9.0.2に対し、各種の不具合を修正したものです。 9.0メジャーリリースにおける新機能についてはE.151を参照してください。
9.0.Xからの移行ではダンプ/リストアは不要です。
walreceiverの終了前に、受信したすべてのWALをディスクにfsyncされることを確実にしました。(Heikki Linnakangas)
こうしないとスタンバイサーバは一部の同期されていないWALを再生することがあり得、もしシステムがまさにその時点でクラッシュした場合おそらくデータ破損につながります。
walreceiverにおける余分なfsync実行を防止しました。(Heikki Linnakangas)
必要な場合にALTER TABLE
が一意性制約および排他制約を再検証するようにしました。(Noah Misch)
VACUUM FULL
およびCLUSTER
実行中の再検証を抑制することを目的とした変更が、意図せずALTER TABLE
にも影響したため、9.0でおかしくなりました。
継承ツリーのテーブルがすべて同一でない場合、その継承ツリーのUPDATE
に対するEvalPlanQualを修正しました。(Tom Lane)
テーブルの行型の(一部の子テーブルにのみ削除された列が存在するなど)何らかの変化はEvalPlanQualコードを混乱させ、誤動作、最悪はクラッシュを導きました。 EvalPlanQualは同一行に対する同時更新の間だけ実行されますので、この問題は散発的にしか発生しませんでした。
EXPLAIN
がCASE
式の簡易構文を表示しようとした時の失敗を防止します。(Tom Lane)
CASE
のテスト式が定数の場合、プランナはCASE
を式表示用コードを混乱させる形式に単純化してしまいました。
その結果「unexpected CASE WHEN clause」というエラーになりました。
過去に存在した添字範囲に対する部分配列代入を修正しました。(Tom Lane)
新しく追加される添字と過去に存在した添字の先頭との間に隙間があった場合、コードは古い配列のヌルビットマップからコピーしなければならない項目数を誤計算してしまい、データ破損またはクラッシュを導く可能性がありました。
プランナにおける、非常に時間が離れた日付値に対する想定外の変換オーバーフローを防止します。(Tom Lane)
date
型はtimestamp
型で表現可能な範囲よりもより広い日付範囲をサポートします。
しかしプランナは常に問題なくdateからtimestampへの変換が可能であることを仮定していました。
配列にNULL項目が含まれる場合のPL/Pythonのクラッシュを修正しました。(Alex Hunsaker)
配列の次元を定義する定数についてのecpgの固定の長さ制限を取り除きました。(Michael Meskes)
... & !(subexpression) | ...
を含むtsquery
値の間違った解析を修正しました。(Tom Lane)
こうした演算子の組み合わせを含む問い合わせは正しく実行されませんでした。
同じエラーがcontrib/intarray
のquery_int
型とcontrib/ltree
のltxtquery
型に存在しました。
query_int
型に対するcontrib/intarray
入力関数におけるバッファオーバーランを修正しました。(Apple)
この関数の返すアドレスが上書きされる可能性があるという点で、この不具合はセキュリティ問題です。 この問題を報告し修正版を提供していただいたApple Incのセキュリティチームに感謝します。(CVE-2010-4015)
contrib/seg
のGiST picksplitアルゴリズムにおける不具合を修正しました。(Alexander Korotkov)
これにより、seg
列上のGiSTインデックスにおいて実際に不正な結果になることはありませんが、非常に非効率的な結果になることがあり得ました。
こうしたインデックスがある場合、この更新版をインストールした後にREINDEX
処理を行うことを検討してください。
(これは過去の更新のcontrib/cube
で修正された不具合と同じです。)