PostgreSQL 8.4.19 に関する技術情報

このリリースは 8.4.18 からの修正リリース(2013/12/5リリース)です。
9.2.x からのアップデートではダンプ、リストアは不要です。

また、8.4.17 より前のバージョンからアップデートを行う場合は 8.4.17 に関する技術情報を参照してください。

PostgreSQL 8.4.18 から 8.4.19 への変更点

9.3.2、9.2.6、9.1.11、9.0.15、8.4.19 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。

VACUUM 処理における relfrozenxid の更新をするかどうかの判定が修正されました。 (Andres Freund) (9.3)(9.2)(9.1)(9.0)(8.4)

relfrozenxid はテーブルごとに凍結済みトランザクションID 位置を保持するpg_class システムテーブルのカラムです。
詳しくはマニュアル「23.1.5.トランザクションIDの周回エラーの防止」を参照ください。

一部のケースで、VACUUM (自動VACUUM) が不適切にテーブルの relfrozenxid 値を前進させることがあり、
一部の行が凍結されないままとなる可能性がありました。
これらの行は 2^31 (約21億) トランザクションが経過すると、消えて（見えなく）なってしまうことになります。

実際の消失が起こる前に複数の誤った relfrozenxid 値の前進が起こる必要があるので、データ損失の可能性はかなり低いです。

9.2.0 以降ではデータ損失の可能性がより高く、また、本障害により「ERROR: could not access status of transaction ...」エラーが出る可能性もあります。
9.0.4 以前、8.4.8 以前のバージョンでは本障害は該当しません。

アップグレード後、全テーブルに VACUUM FREEZE を行ってください。
VACUUM FREEZE コマンドを実行するか、SET vacuum_freeze_table_age TO 0 と設定したうえで VACUUM を行います。
これにより、既に不正な状態となっているテーブルを修復します。

データベースクラスタがこれまで 2^31 に満たない更新トランザクションしか実行してないのであれば、
VACUUM FREEZE を行うだけで当面は安全になります。

行ロック制御に使われる MultiXactId の凍結に関する障害が修正されました。 (Andres Freund, Álvaro Herrera) (9.3)

本障害は、「ERROR: counld not access status of transaction ...」エラー、あるいは、行の重複や消失をひき起こす可能性があります。

アップグレード後に全テーブルに VACUUM FREEZE を行って、既に生じてしまった不正なデータ状態を修復してください。

別の問題として、本障害はスタンバイサーバにも生じ、データ不一致をひき起こします。
したがって、9.3.0、9.3.1 のスタンバイサーバはバージョンアップ後、ベースバックアップを取り直すようにしてください。

ホットスタンバイの起動における pg_clog と pg_subtrans の初期化について修正されました。 (Andres Freund, Heikki Linnakangas) (9.3)(9.2)(9.1)(9.0)

pg_clog、pg_subtrans はトランザクション状態を管理する内部データです。

本障害は、ホットスタンバイサーバが起動して、クエリを受け付けるとき、
コミット済トランザクションを未コミットとマークしてしまうことで、スタンバイ側にデータ破損を発生させます。
行が消失してしまう、削除済み行が現れてしまう、更新前の行データが更新後の行データとともに残ってしまうといったことが起こり得ます。

このデータ破損が生じる可能性は、スタンバイの起動時に、
プライマリでチェックポイント以降に多数の更新トランザクションを実行している場合でないかぎり、低いといえます。

本障害は、9.3.0、9.2.5、9.1.10、9.0.14 の各バージョンで導入されてしまいました。
これらより手前バージョンは該当しません。

アップグレード後、ベースバックアップの取り直しをしてスタンバイサーバの再構成することが推奨されます。

更新連鎖の横断処理に関するいくつかの障害が修正されました (Andres Freund, Álvaro Herrera) (9.3)

行ロックなどある行の複数行バージョンに対する横断的処理について修正されました。

本障害では、同時更新処理において、誤った行のロックや更新が生じる可能性がありました。
また「ERROR: unable to fetch updated version of tuple」エラーが誤って出ることもありえます。

Fast Path Locking における不正なポインタの問題が修正されました (Tom Lane) (9.3)(9.2)

Fast Path Locking とは、比較的弱いテーブルロック等の実装に使われている仕組みです。

本障害は、共有メモリ上のロックデータ構造の破損をひきおこし、誤った振る舞いを生じさせる原因となります。

タイムアウト制御における競合状態が修正されました (Tom Lane) (9.3)

本障害により、SIGALRM または SIGINT シグナルがブロックされることで、サーバプロセスの無応答が生じる可能性がありました。

WALリプレイの中で pg_multixact/ のデータを切り詰めるようになりました (Andres Freund) (9.3)(9.2)(9.1)(9.0)

pg_multixact はデータベースクラスタディレクトリ内のディレクトリで、行ロック制御のためのファイルが格納されます。

8.2.x 時代に切り詰めを行わないようにされましたが、
ホットスタンバイのように長期にリカバリ（WALリプレイ）を続けるケースでは、ファイルが増え続けることの方が問題となります。

XID 周回対策の VACUUM 処理で、凍結が必要な行が無いと確認するだけだった場合に、
走査したページを確実にカウントするように修正されました (Sergey Burladyan, Jeff Janes) (9.3)(9.2)

本障害により relfrozenxid 値の前進に失敗することがあり、XID 周回防止 VACUUM がまだ必要であると見なされてしまいます。
最悪のケースではデータベースサーバプロセスが XID周回防止のために動作を停止してしまいます。

MultiXactId によりテーブル全体VACUUM を要求する仕組みが修正されました (Andres Freund) (9.3)

本障害により自動VACUUM の無用な活動が多数生じる可能性がありました。

GIN インデックスの木ページの削除における競合が修正されました (Heikki Linnakangas) (9.3)(9.2)(9.1)(9.0)(8.4)

本障害は一時的な誤った応答や SQL実行失敗をひきおこす可能性があります。

SP-GiST インデックス作成で「ERROR: unexpected spgdoinsert() failure」が生じるケースが修正されました (Teodor Sigaev) (9.3)(9.2)

当該ケースにおいては内部的にリトライするようになります。

マテリアライズドビューについて雑多な修正が行われました (Kevin Grittner, Andres Freund) (9.3)

以下のような記法でのカラム指定が動作するようになりました。

=# CREATE TABLE t ( i int );
=# CREATE MATERIALIZED VIEW mv_t(ii) AS SELECT * FROM t;

マテリアライズドビューのリフレッシュ処理で内部的なクローズ処理位置の誤りが修正されました。

結合時には別エイリアスを使っている重複したテーブルのエイリアスを再び認めるようになりました (Tom Lane) (9.3)

PostgreSQL では歴史的に以下のような SQL を受け入れていましたが、SQL標準を厳密に読むとエイリアス x を重複して使うのは禁止されています。

SELECT ... FROM tab1 x CROSS JOIN (tab2 x CROSS JOIN tab3 y) z

9.3.0 でこれを拒否するようにしましたが、元の振る舞いに戻されました。

外部結合内で入れ子になった単純な値ではないサブクエリについてプランナ処理が修正されました (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)

本障害により、JOIN 構文内に複数レベルのサブクエリをもつ SQL に対して、誤ったプランを作るおそれがありました。

複数の WHERE と OUTER JOIN の結合条件とに STRICT でない同一の式が現れたときの誤ったプラン作成が修正されました (Tom Lane) (9.3)(9.2)
サブクエリの行全体を参照するときプランナが処理に失敗するのが修正されました (Tom Lane) (9.3)(9.2)

以下 SQL でエラーとなる例が報告されています。

=# SELECT q1.* FROM (select 'a'::text) q1(c) WHERE NOT EXISTS
   (SELECT * FROM (SELECT 'A'::text) q2(c) WHERE q2 = q1);
ERROR: subquery q2 does not have attribute 0

継承ツリーへの min()、max() 関数に対する最適化プラン生成の誤りが修正されました (Tom Lane) (9.3)(9.2)(9.1)

min()、max() に対してシンプルなカラム指定でなく、式を与えると、プラン内が失敗することがありました。

修正前バージョンでは、プラン表示にて以下のようにエラーが出てしまいます。SQL実行自体は可能ですが Limit 計画タイプを使った min()、max() に特化した最適化がされない動作となっていました。

=# CREATE TABLE matest0 (id serial PRIMARY KEY, name text);
=# CREATE TABLE matest1 (id int PRIMARY KEY) INHERITS (matest0);
=# CREATE TABLE matest2 (id int PRIMARY KEY) INHERITS (matest0);
=# CREATE TABLE matest3 (id int PRIMARY KEY) INHERITS (matest0);
=# CREATE INDEX matest0i ON matest0 ((1-id));
=# CREATE INDEX matest1i ON matest1 ((1-id));
=# CREATE INDEX matest3i ON matest3 ((1-id));

=# EXPLAIN SELECT min(1-id) FROM matest0;
ERROR:  no tlist entry for key 2

一時ファイルの早すぎる削除が修正されました (Andres Freund) (9.3)(9.2)(9.1)(9.0)(8.4)

サブトランザクション（SAVEPOINT や手続き言語の例外ブロック）の終了時などにエラーやクラッシュを招く可能性がありました。

範囲型値の出力に伴うトランザクション内でのメモリリークが修正されました (Tom Lane) (9.3)(9.2)

本修正では実際にはあらゆるデータ型の出力関数を直しますが、特に範囲データ型において１回につき数キロバイト単位という著しいリークが出ていました。

設定ファイルをリロードする際のメモリリークが修正されました (Heikki Linnakangas, Hari Babu) (9.3)
NOT NULL や CHECK による制約違反メッセージで誤って削除済みのカラムが表示される問題が修正されました (Michael Paquier and Tom Lane) (9.3)(9.2)

以下のエラー例が報告されていました。２カラムのテーブルにもかかわらず、エラーメッセージでは３カラムになっています。

=> CREATE TABLE t22 (id serial primary key, v int check(v < 10));
=> ALTER TABLE t22 DROP COLUMN v;
=> ALTER TABLE t22 ADD COLUMN "v" int CHECK (v < 10);
=> INSERT INTO t22 (v) VALUES (100);
ERROR:  new row for relation "t22" violates check constraint
"t22_v_check"
DETAIL:  Failing row contains (1, null, 100).

ウィンドウ関数の記法でデフォルト引数値と名前付き引数指定に対応しました (Tom Lane) (9.3)(9.2)

以下のような関数の呼び出し方法が動作するようになります。

CREATE FUNCTION nth_value_def(val anyelement, n int = 1)
 RETURNS anyelement LANGUAGE internal WINDOW IMMUTABLE STRICT
 AS 'window_nth_value';

SELECT nth_value_def(n := 2, val := ten) OVER (PARTITION BY cf), ct, cf
 FROM (SELECT * FROM t1 WHERE cu < 10 ORDER BY cf, ct) s;

SELECT nth_value_def(ct) OVER (PARTITION BY cf), ct, cf
 FROM (SELECT * FROM t1 WHERE cu < 10 ORDER BY cf, ct) s;

これまで名前付き引数を使った場合には「ERROR: window functions cannot use named arguments」が出ていました。
また、デフォルト引数を使った場合、クラッシュをひき起こしていました。

ルールとビューの整形表示にて行末の空白を削除するようになりました (Tom Lane) (9.3)

9.3.0 は過去バージョンと比べて空白を出力するケースが多くありました。想定外の振る舞い変化を減らすため、不要な空白だけを削除しています。

int2vector型、oidvector型について、配列切り出し処理が修正されました (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)

これらはシステムテーブルで使われるデータ型です。以下の SQL でバックエンドプロセスのクラッシュが生じていました。

SELECT a.indkey[1:3], a.indkey[1:2] FROM pg_index AS a;

int2[] 型（smallint[]型）や oid[] 型であれば本障害に該当しません。

空の htsore型データを変換した場合にも有効な JSONデータが返るように修正されました (Oskari Saarenmaa) (9.3)

以前は以下を実行すると「{}」ではなく、空文字列データが返っていました。空文字列は JSON 型のデータとして投入不能であるため、望ましくない振る舞いでした。

=# SELECT (''::hstore)::json;
 json
------
 {}
(1 row)

SQL標準の GMTオフセットのタイムゾーン表記を使ったときの誤った振る舞いが修正されました (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)

「-5.0」などの GMTオフセット表記の場合に問題が生じていました。以下例では「2012-12-11 22:00:00-05」が返らなければいけません。

(障害動作例)
=# SET TIME ZONE '-5.0';
=# SELECT '2012-12-12 12:00 Japan'::timestamptz;
      timestamptz
------------------------
 2012-12-12 12:00:00-05

Windows エラーコードを変換してログ出力する際の誤りが修正されました (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)

DEBUGレベルログに誤った内容が出力されていました。

Windows のサービスからコマンド起動する際に適切にダブルクオートを付加するようになりました (Naoya Anzai and Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)

このほか、Windows むけにいくつか修正が行われています。

サービス定義を読み取るサードパーティツールでの問題に対応して、スラッシュでパス区切りしている場合にバックスラッシュで置き換えます。また、非常に長いパス名に対してバッファオーバーランが起きないように修正されました。

pg_dumpall が対象データベースに default_transaction_read_only = onと ALTER DATABASE 命令で設定されていた場合にも動作するように修正されました。 (Kevin Grittner) (9.3)(9.2)(9.1)(9.0)(8.4)

これまではリストア時に以下のようなエラーが生じていました。

psql:all.dump:56: ERROR:  cannot execute COMMENT in a read-only transaction
psql:all.dump:72: ERROR:  cannot execute CREATE TABLE in a read-only transaction
psql:all.dump:75: ERROR:  cannot execute ALTER TABLE in a read-only transaction

pg_isready の -d オプションについて修正されました (Fabrízio de Royes Mello and Fujii Masao) (9.3)

これまで以下のようなエラーが生じ、正しく動作していませんでした。

$ pg_isready -h localhost -p 5432 -U postgres -d db1
pg_isready: missing "=" after "db1" in connection info string

pg_receivexlog で WALファイル名の読み取り処理が修正されました (Heikki Linnakangas) (9.3)

本誤りにより、4GB 以上（256ファイル以上）WAL が書かれた後で、以下エラーが出て、ストリーミングの停止後の再開ができませんでした。「pg_receivexlog: could not parse transaction log file name」

pg_upgrade が適切にディスクスペース不足を報告するように修正されました (Peter Eisentraut) (9.3)

contrib/pg_upgrade は、PostgreSQL バージョンアップに対応して、データベースクラスタディレクトリを書き換えるツールです。これまでディスク不足で失敗するときにエラーメッセージの原因を示す箇所が「Success」となってしまっていました。

ecpg でクオートされたカーソル名で大文字小文字の区別をするように修正されました (Zoltán Böszörményi) (9.3)(9.2)(9.1)

これまで " でクオートしていても大文字小文字を同一視していました。

ecpg における varchar型で宣言された変数リストの処理が修正されました
(Zoltán Böszörményi) (9.3)(9.2)(9.1)(9.0)(8.4)

以下のコードが、

EXEC SQL BEGIN DECLARE SECTION;
varchar a[50], b[50];
EXEC SQL END DECLARE SECTION;

ecpgプリプロセッサにより、以下のように変換されてしまいました。

struct varchar_1  { int len; char arr[ 50 ]; }  a , struct varchar_2  { int len; char arr[ 50 ]; }  b ;

これは C言語の文法エラーを引き起こします。上記「,」は「;」でなければいけません。

contrib/lo が誤ったトリガ定義から保護されるように修正されました (Marc Cousin) (9.3)(9.2)(9.1)(9.0)(8.4)

contrib/lo はラージオブジェクトを自動削除するトリガ関数 lo_manage() とloドメイン型を提供する拡張モジュールです。これまで lo_manage() 関数を誤って文レベルトリガとして使用されるとクラッシュを引き起こしていましたが、修正によりエラー終了するようになりました。

タイムゾーンデータが tzdata release 2013h に更新されました (9.3)(9.2)(9.1)(9.0)(8.4)

アルゼンチン、ブラジル、ヨルダン、リビア、リヒテンシュタイン、モロッコ、パレスチナの夏時間法の変更が適用されています。また、新たなタイムゾーン略記法 WIB、WIT、WITA（いずれもインドネシ
アのタイムゾーン）が追加されました。

SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

PostgreSQL 8.4.19 に関する技術情報

PostgreSQL 8.4.18 から 8.4.19 への変更点

最近の投稿

カテゴリー

PostgreSQL 8.4.18 から 8.4.19 への変更点

関連記事:

最近の投稿

カテゴリー

タグ