このリリースは 8.2.19 からの修正リリース(2011/01/31リリース)です。
8.2.x からのアップデートではダンプ、リストアは不要です。
また、8.2.14 より前のバージョンからアップデートを行う場合は 8.2.14 に関する技術情報を参照してください。
PostgreSQL 8.2.19 から 8.2.20 への変更点
9.0.3、8.4.7、8.3.14、8.2.20 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。
-
pg_restore のラージオブジェクトに関するテキスト出力が、元データベースで standard_conforming_strings = on であった場合について修正されました。(Tom Lane) (8.2、8.3、8.4)
$ pg_restore -O backup.dat | psql
のような pg_restore からパイプ出力をする使い方で、文字列エスケープが不適切になります。
データベースに直接リストアするケースでは正しく動作します。 -
walreceiver が終了する前に受け取った WALを確実にディスクに fsyncで書き込むようになりました。(Heikki Linnakangas) (9.0)
本修正なしでは、システムクラッシュのタイミングによっては、スタンバイサーバが同期が行われていない WAL を再生して、データ破損を招くことが考えられます。
- walreceiver が fsync を過剰に発行していたものが修正されました。(Heikki Linnakangas) (9.0)
-
ALTER TABLE によってテーブル定義を変更した場合に、制約を再確認するようになりました。(Noah Misch) (9.0)
以下のようなケースで制約違反が見逃されていました。
=# INSERT INTO t (1.1),(1.2); =# ALTER TABLE t ALTER c TYPE INT; =# SELECT * FROM t; c --- 1 ユニーク制約違反 1 -
継承ツリーのテーブルがすべて同一でない場合の、継承ツリーの UPDATE に対する EvalPlanQual が修正されました。(Tom Lane)(9.0)
テーブル行型の（一部の子テーブルにのみ削除された列が存在するなど）何らかの変化は EvalPlanQual コードを混乱させ、誤動作、最悪はクラッシュを導きました。EvalPlanQual は同一行に対する同時更新のときだけ実行されますので、この問題は散発的にしか発生しませんでした。
-
EXPLAINがCASE式の簡易構文の表示に失敗するのを防止するようになりました。(Tom Lane)(9.0)(8.4)(8.3)(8.2)
CASE のテスト式が定数の場合、プランナは CASE を式表示用コードを混乱させる形式に単純化してしまいました。その結果 EXPLAIN で以下のようなエラーが生じていました。
ERROR: unexpected CASE WHEN clause: 314
-
部分代入済みの配列に対する部分代入が修正されました。(Tom Lane)(9.0)(8.4)(8.3)(8.2)
新しく追加される添字と過去に存在した添字の先頭との間に隙間があった場合、コードは古い配列のヌルビットマップからコピーしなければならない項目数を誤計算してしまい、データ破損またはクラッシュを導く可能性がありました。以下のような初期化で不正なデータが混入するケースが報告されていました。
CREATE TABLE test_array (my_array BIGINT[]); INSERT INTO test_array (my_array) VALUES ('[40:41]={40,41}'); UPDATE test_array SET my_array[1:2]='{1,2}'; SELECT * FROM test_array; -
プランナにおける、非常に時間が離れた日付値に対する想定外の変換オーバーフローが修正されました。(Tom Lane)(9.0)(8.4)(8.3)(8.2)
date 型は timestamp 型で表現可能な範囲よりもより広い日付範囲をサポートします。
しかしプランナは常に問題なく date から timestamp への変換が可能であることを仮定していました。 - 配列に NULL 項目が含まれる場合の PL/Python のクラッシュが修正されました。(Alex Hunsaker) (9.0)
- ecpg で、配列次元を定義する定数の固定長の制限が取り除かれました。(Michael Meskes) (9.0)
-
... & !(subexpression) | ... を含む tsquery 値の間違った解析が修正されました。(Tom Lane)(9.0)(8.4)(8.3)(8.2)
こうした演算子の組み合わせを含む問い合わせは正しく実行されませんでした。同じエラーが contrib/intarray の query_int 型と contrib/ltree の ltxtquery 型に存在しました。
-
query_int 型に対する contrib/intarray 入力関数におけるバッファオーバーランが修正されました。(Apple)(9.0)(8.4)(8.3)(8.2)
この関数の返すアドレスが上書きされる可能性があるという点で、この不具合はセキュリティ問題です。
Apple, Inc. のセキュリティチームにより報告され、修正版が提供されました。(CVE-2010-4015) -
contrib/seg の GiST picksplit アルゴリズムにおける不具合が修正されました。(Alexander Korotkov)(9.0)(8.4)(8.3)(8.2)
この不具合により、seg 列上の GiST インデックスにおいて実際に不正な結果になることはありませんが、非常に非効率的な結果になることがあり得ました。こうしたインデックスがある場合、この更新版をインストールした後に REINDEX 処理を行うことを検討してください。