E.1. リリース9.0.3

E.1.1. バージョン9.0.3への移行

9.0.Xからの移行ではダンプ/リストアは不要です。

E.1.2. 変更点

• 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で修正された不具合と同じです。）