enum_recv 関数の引数が誤って宣言されているため、enum_recv 関数を SQL コマンドから呼び出すことによりサーバをクラッシュさせることができました。

原理上、攻撃者はそれを悪用してサーバメモリの内容を調査できる可能性があります。この問題は、Sumit Soni 氏 (Secunia SVCRP) によって報告されました (CVE-2013-0255)。

以前は、この誤りによって、不正に「WAL ends before end of online backup」エラーが発生することがありました。

以前は、タイムラインの初期の時点でリカバリを停止する際に、必要なデータを破棄しており、以下のようなエラーが発生することがありました。

WARNING:  page 0 of relation base/xxxxx/xxxxx does not exist
PANIC:  WAL contains references to invalid pages

競合するホットスタンバイ問い合わせをキャンセルするはずが、時々失敗して、一貫性のないデータが見えていました。

以前は、以下のようにエラーが発生しました。

=# select ((select array[1,2]))[1];
ERROR:  syntax error at or near "["
LINE 1: select ((select array[1,2]))[1];

テーブルの末尾で空のページを切り詰めるには、排他ロックが必要ですが、自動バキュームは、ロック要求が競合したときに失敗（かつ、テーブルロックを解放）するコードになっていました。そのため、高負荷な状況下で切り詰めが行われないことはよくあり、テーブルの無駄な膨張を招きました。

今回、自動バキュームは、テーブルを部分的に切り詰め、ロックを解放し、ロックの再獲得を試みて処理を継続するように修正されました。この修正は、競合する要求が届いた後、自動バキュームがロックを解放するまでの平均時間も大幅に削減します。

計画キャッシング機構の改訂結果として 9.2 で加えられたいくつかのデータコピーによるオーバーヘッドが取り除かれました。これは、特に多くの SQL 文を含むクエリ文字列を実行したときの 9.1 と比較した性能劣化を防ぎ、メモリの消費も抑えます。

この修正によって、マルチステートメント問い合わせ文字列は、現在、完全に直列に処理されます。つまり、後に続く文の解析と計画立案の前に、始めの文の実行が完了します。

コスト見積もり時の調整用係数 (fudge factor) が、非常に大きなインデックスを使用する望ましくない高いコスト見積もりにつながっていました。

以前のコードは、無限ループに陥ることがありました。

以前は、CREATE DATABASE と DROP DATABASE が、pg_tablespace のエントリを同時に更新すると、不正な結果になることがありました。

安全上、それらのオブジェクトの所有権は削除ではなく、再割り当てする必要がありました。

この不具合は、9.2.2 の修正で混入しました。

=# create user testuser;
=# create database testdb owner testuser;
=# drop owned by testuser;
ERROR:  unrecognized object class: 1262

デフォルト設定では、vacuum_freeze_table_age は vacuum_freeze_min_age よりトランザクション数が多いですが、この間違いによって、自動バキュームによる部分的なテーブルスキャンが妨げられ、代わりに全テーブルスキャンが常に行われていました。

この不正な処理は、以下のように CREATE TABLE LIKE INCLUDING INDEXES 文などで表面化しました。

=# CREATE TYPE my_type AS (x int, y int);
=# CREATE TABLE t1 (a int, b int);
=# CREATE INDEX t1_idx ON t1 (((a, b)::my_type));
=# CREATE TABLE t2 (LIKE t1 INCLUDING INDEXES);
ERROR:  column "" has pseudo-type record

型のデフォルトのアクセス権限にいくつか問題があり、アクセス権限のダンプに失敗していました。

以前は、以下のようにデータ型に対してデフォルトのアクセス権限を定義すると、pg_dump に失敗します。

=# ALTER DEFAULT PRIVILEGES IN SCHEMA PUBLIC GRANT ALL ON TYPES TO my_group;
$ pg_dump db
pg_dump: unknown object type (84) in default privileges

クラッシュリカバリで一時テーブルの削除を行いますが、システムテーブルについては起動時すぐには削除しない設計となっています。このため、残骸の一時テーブルは無視するように作られていましたが、以前の修正で問題が混入してしまいました。

log_rotation_size で指定したサイズを超過してもローテーションしないことがありました。

以下のような SQL は「ERROR: date out of range ...」となります。

(従来の動作)
=# SELECT to_date('32 Dec 2012', 'DD Mon YYYY');
  to_date
------------
 2013-01-01

pg_extension_config_dump() 関数は、拡張モジュールにおける一部の（例えば設定を書き込むための）テーブルのデータを pg_dump/pg_dumpall の対象に含めるように指定するものです。

拡張モジュールの更新スクリプトの中で本関数を呼び出すことで、対象テーブルに対する既存の指定を置き換えることができるようになりました。以前は指定を追加するたけで置き換えがされませんでした。

以下のように実行すると、１回目の関数実行ではエラーが短く出ます。

=# CREATE FUNCTION fail() RETURNS int LANGUAGE plpgsql
     AS $$ BEGIN RETURN 1/0; END $$;
CREATE FUNCTION
=# SELECT fail();
ERROR:  division by zero
CONTEXT:  PL/pgSQL function fail() line 1 at RETURN
=# SELECT fail();
ERROR:  division by zero
CONTEXT:  SQL statement "SELECT 1/0"
PL/pgSQL function fail() line 1 at RETURN

同じ関数を異なるテーブルのトリガ関数として使う場合に問題がありました。異なるテーブルのトリガ関数が同じキャッシュエントリに格納されていたため、一方のテーブルについて削除した後、残るテーブルのトリガを起動したとき、「ERROR: cache lookup failed for relation 12345」というエラーがでました。

psql などの付属クラアントツールで表示が乱れ、エラーが出ることがありました。

以前は、タイムラインを跨って取得することができませんでした。pg_receivexlog にも同様の変更が適用されています。

UNLOGGEDテーブルはスタンバイサーバにデータが伝搬しませんので、いずれにせよスタンバイサーバから有効なバックアップは取れません。--no-unlogged-table-data オプションが自動で付加されるようになったともいえます。

これまで壊れたインデックスが生じているかチェックされませんでした。

pg_ctl にスペース空けがない形でパラメータが渡ってしまう問題がありました。

この古い関数は PostgreSQL 自身の中ではどこでも使われていません。しかし、一部のクライアントプログラムのコードで未だ使われている可能性があります。

現在いくつかの東ヨーロッパのタイムゾーンで使われています。

障害の一つは DROP INDEX CONCURRENTLY が導入された際に混入したもので、CREATE INDEX CONCURRENTLY にて壊れたインデックスを生成してしまうことがありました。

本マイナーアップ後に REINDEX を行うことが推奨されます。

DROP INDEX CONCURRENTLY で対象インデックス使用中のクエリが終わるまでそのインデックスへの挿入ができなくなってしまう問題が修正されました。

DROP INDEX CONCURRENTLY がキャンセルされた場合の誤った振る舞いが修正されました。以前は、裏に DROP できないインデックスが残ってしまうことがありました。

以下２点は 9.1〜8.3 の各バージョン系列でも共通に修正されています。

pg_index の行を更新する際に in-place updates を使うように修正されました。同時更新による競合で、更新が失敗し、壊れたインデックスが生じるのを防ぎます。

いくつかの DDL命令および VACUUM で、誤ったインデックス検索結果を無視するように修正されました。

修正前は、SSI（直列化スナップショット隔離）の述語ロックが誤ったタイミングで処理されていました。これは DROP と並行してシリアライザブルトランザクションを実行した際に誤った振る舞いを引き起こすおそれがありました。

WALリプレイが複数ページに影響を及ぼす場合にバッファロックが不十分でした。ホットスタンバイ問い合わせで一時的に一貫性のない状態が見えてしまい、誤った結果や予想外のエラーを引き起こす可能性がありました。

この誤りは WALページ分割失敗のときにインデックス破損を引き起こします。

この誤りは、クラッシュ後またはスタンバイサーバにてインデックス破損を引き起こします。

この誤りにより、ホットスタンバイモードでデータベースが一貫性のある状態に達する前に起動してしまいます。

この誤りは、以降の CREATE INDEX CONCURRENTLY などいくつかの操作を妨げていました。

この障害により、シャットダウン処理が長くなる、あるいは、追加的なユーザ操作なしにはずっと終わらない可能性がありました。

"FATAL: XX000: poll() failed: Invalid argument" というメッセージが出るケースが報告されていました。

修正前は割り込みが殺到することで際限なく待たされる可能性がありました。この動作は autovacuum lancherプロセスにおいて問題となっており、その他、同様の問題を引き起こしていたものと考えられます。

内部関数 WaitLatch() は タイムアウトや何らかのイベントが起きるまで処理を休止する動作をさせるもので PostgreSQLの様々な箇所で使われています。

多くの場合、予期せぬエラーで処理が失敗するだけで済みますが、relcache など長期に利用するシステムキャッシュが破壊された場合、テーブルデータが壊れる可能性があります。

この修正は DROP済みのテーブルが長期にディスクを占有してしまう問題を軽減します。

新プロセス生成は失敗しますが、全体を強制再起動する理由に乏しいため、そのようにしないものとされました。この改良は OS がファイルディスクリプタ数の上限に近付いているときの動作を頑健にします。

以下のような SQL でクラッシュが生じるケースが報告されていました。

EXPLAIN
  SELECT * FROM t1 LEFT OUTER JOIN (
    SELECT DISTINCT t2.id FROM t2 WHERE t2.id > 100
    ) AS _t ON _t.id = t1.id
  WHERE t1.id > 100 OR (t1.id < 100 AND _t.id IS NOT NULL);

該当する SQL に対してプランナが条件句から誤った制約を導出することがありました。COALESCE や CASE に外部結合によって null になりうるカラムが指定されていて、それが選択条件に使われている場合に該当します。各バージョンに問題がありますが、特に 9.2.x で良く出やすくなっています。

障害例を示します。実行プラン末行に奇妙な条件式があらわれています。

=# CREATE TABLE ta (q1 int PRIMARY KEY);
=# CREATE TABLE tb (u1 int UNIQUE, c1 int, c2 int);
=# EXPLAIN (COSTS OFF)
   SELECT q1, u1, c1, c2 FROM ta LEFT JOIN tb ON q1 = u1
   WHERE coalesce (c1, 123) = q1 AND coalesce (c2, 123) = q1;
                                  QUERY PLAN
-------------------------------------------------------------------------------
 Hash Left Join
   Hash Cond: (ta.q1 = tb.u1)
   Filter: (ta.q1 = COALESCE(tb.c1, 123))
   ->  Seq Scan on ta
   ->  Hash
         ->  Seq Scan on tb
               Filter: (COALESCE(c1, 123) = COALESCE(c2, 123))

障害例を示します。以下のエラーが発生します。

=# CREATE TABLE tp (id int, f1 int);
=# CREATE TABLE tc1 (UNIQUE(f1)) INHERITS (tp);
=# CREATE TABLE tc2 (UNIQUE(f1)) INHERITS (tp);
=# CREATE TABLE tc3 (UNIQUE(f1)) INHERITS (tp);

=# SELECT DISTINCT min(f1), max(f1) FROM tp;
ERROR:  failed to re-find MinMaxAggInfo record

従来は検索条件節（WHERE句）のみを見ていました。

以下パターンで処理が長時間戻らないことが報告されています。プラン検討対象リレーション数の上限が内部的に設けられました。

=# CREATE TABLE tx (id int PRIMARY KEY);

=# EXPLAIN  SELECT 1 FROM tx AS a
    JOIN (SELECT 2 as aid) AS ag1 ON (ag1.aid = a.id)
    JOIN (SELECT 3 as aid) AS ag2 ON (ag2.aid = a.id)
    JOIN (SELECT 4 as aid) AS ag3 ON (ag3.aid = a.id)
    JOIN (SELECT 5 as aid) AS ag4 ON (ag4.aid = a.id)
      : 中略
    JOIN (SELECT 22 as aid) AS ag22 ON (ag22.aid = a.id)
    JOIN (SELECT 23 as aid) AS ag23 ON (ag23.aid = a.id)
    JOIN (SELECT 24 as aid) AS ag24 ON (ag24.aid = a.id)
    JOIN (SELECT 25 as aid) AS ag25 ON (ag25.aid = a.id);

 ... WHERE (a, b) NOT IN (SELECT x, y FROM ...)

という形の問い合わせで、b と y がそれぞれ int4 と int8 であるなど、型が異なる場合に該当します。

本障害では、特定の型を含む場合に、誤った結果が返ったり、クラッシュが生じたりする可能性がありました。

本障害により、内側のインデックススキャンが「インデックスカラム = ANY(配列)」という条件であるようなマージJOIN で誤った結果が返る可能性があります。

9.2 の問い合わせ実行中のスナップショット取得数を減らす変更は、問い合わせで使われるテーブルをロックする前にスナップショット取得を伴う処理が実行されることによって、以前には無かった望ましくない振る舞いを引き起こしました。

例えば、ある問い合わせで、先立つトランザクションによってコミットされた更新データが見えることが排他ロックを取得していたとしても保証されません。

ごく稀な状況でこの誤りは、トリガの WHEN条件、または、外部キー制約トリガの事前チェックロジックに不正なデータを渡してしまい、クラッシュやトリガ誤動作を引き起こします。

8.4 以降バージョンで問題がおきていました。

キャッシュされた SQL が再実行される場合にエラーを引き起こしていました。

ビューはシステムカラムをもたないため、もともと不要なデータでした。

この障害は PostgreSQL自体には大きな影響はありませんが、txid_current() 関数や関連の関数に依存したアプリケーションでは TXID 値が逆行したように見えてしまいます。

管理者ユーザで実行する場合には正しく動作していました。

ERROR: Non-recoverable failure in name resolution

などが出ていました。

トランザクションが多数の排他ロックを保持している場合に、不要な処理が大きな負担となる可能性がありました。

これまで処理競合によりファイルディスクプリタがリークする可能性がありました。

--section=data、pg_dump --section=pre-data といったオプションを指定した際の振る舞いが変ります。以前は、値の設定が pre-data セクションに含まれていました。以前から --data-only を指定した場合には、シーケンスに対する値の設定は含まれていました。

また、シーケンスが拡張モジュール設定テーブルとして指定されている場合のダンプ出力が改善されました。

仕様変更を伴う修正となります。

pg_dump で --clean と --create を合わせた指定が可能になりました。対象データベースに接続する前に DROP DATABASE を行い、次に CREATE DATABASE を行うという手順を出力します。以前は両指定を同時に与えることができませんでした。

--create を指定せずに --clean を指定した場合、データベース削除は行わないようになりました。9.2.0 から pg_dump --clean は DROP DATABASE を発行するようになりましたが、これは役に立たずで時に危険でした。

VIEW に循環参照があって、オプション指定（WITH〜）が無い場合に pg_dump にて誤った構文のALTER VIEW が出力されていました。

テーブル名に大文字が含まれている場合に、それらが小文字に変っていて正しく動作しない内容を出力してしまいます。

また、--insert モードのときにも 通常の COPYモード同様にリストアできるようになりました。

pg_dump の tar 出力モードは POSIX標準に完全に準拠した tarファイルを出力するわけではありませんでした（これは 9.3 バージョンで修正されます）。本修正により、これまでの形式も、POSIX準拠の tar形式も読み込めるようになります。

本障害によりデータディレクトリを使用中の postmaster がいるのを見落とす可能性がありました。

本障害のために information_schema が削除され再作成されるときにエラーが生じていました。そのほかの失敗の可能性もありました。

新たなデータベースクラスタには synchronous_commit = off とします。

これらの関数にいくつかのプラットフォームは NULL を返しますが、out-of-memory と誤認する恐れがありました。

これまでソースツリー外でのビルドはサポートされていませんでした。

キューバ、イスラエル、ヨルダン、リビア、パレスチナ、西サモア、ブラジルの夏時間法の変更を含みます。

本障害により、クラッシュリカバリとレプリケーションのスタンバイサーバにおいてデータ破損が起きる可能性があります。

最も高い可能性で起きるのはテーブルのビジビリティマップの破損です。これにより 9.2.x の index-only scan において誤ったデータが返ることになります。9.1.x ではビジビリティマップ破損により一時的に VACUUM が効果的に行われなくなるだけです。

可能性は低いですが Btree、GINインデックスが破損するケースもあります。テーブルデータ本体は本障害では破損しません。

マイナーバージョンアップをした後で、全ての Btree、GINインデックスを REINDEX することが推奨されます。また、全てのテーブルについて、vacuum_freeze_table_age を 0 にして VACUUM を実行することが推奨されます（単に vacuumdb -aF コマンドを実行してもよいでしょう）。

また、9.1、9.0、8.4系列ではエグゼキュータのCTEプランノードの再スキャンロジックが修正されました。

本障害で WITH 節のサブクエリを複数スキャンすることで、誤った応答が返る可能性がありました。

新たなロック取得を必要としないコマンドでは、当トランザクション開始後から当コマンド実行前に、並行して別トランザクションでコミットされた GRANT または REVOKE の結果を反映しない動作をする可能性がありました。

9.2.0 では ANALYZE に対して以下のようなエラーがでていました。

ERROR:  array_typanalyze was invoked for non-array type 16824

一部の Linuxディストリビューションには不適切なバージョンの pthread.h が含まれており、コンパイルされた PL/Perl コードも不適切なものとなっていました。PL/Perl 関数が他の関数を呼び出してエラーになった場合に、クラッシュ（segmentation fault）が引き起こされます。

pg_config コマンドをインストールしていないケースもあるための対応となります。

フィジーにおける夏時間法の変更に対応しています。

Windows においてプロセス開始時にクラッシュすることがあり、また、ホットスタンバイの動作でクラッシュすることがありました。

本修正前には複数列GiSTインデックスが想定外に膨張することがありました。

例を示します。以下のようにテーブルに権限設定がされていたとして、そこで user2 で user4 から権限を剥奪する REVOKE ... CASCADE を行うものとします。

=# dp dep_priv_test
 Schema | Name | Type  |  Access privileges  | Column privileges
--------+------+-------+---------------------+------------------
 public | test | table | user1=arwdDxt/user1+|
        |      |       | user2=r*/user1     +|
        |      |       | user3=r*/user1     +|
        |      |       | user4=r*/user2     +|
        |      |       | user4=r*/user3     +|
        |      |       | user5=r/user4       |

=# SET SESSION ROLE user2;
=> REVOKE SELECT ON test FROM user4 CASCADE;

修正前は以下の状態になります。

=> dp test
 Schema | Name | Type  |  Access privileges  | Column privileges
--------+------+-------+---------------------+------------------
 public | test | table | user1=arwdDxt/user1+|
        |      |       | user2=r*/user1     +|
        |      |       | user3=r*/user1     +|
        |      |       | user4=r*/user3      |

修正後は以下の状態となります。user2 を経由せず、user3 → user4 → user5 のルートで user5 の権限が与えられたケースが尊重されます。

=> dp test
 Schema | Name | Type  |  Access privileges  | Column privileges
--------+------+-------+---------------------+------------------
 public | test | table | user1=arwdDxt/user1+|
        |      |       | user2=r*/user1     +|
        |      |       | user3=r*/user1     +|
        |      |       | user4=r*/user3     +|
        |      |       | user5=r/user4       |

この状況は、pg_dump や他の機能で、循環依存を生んでしまいます。人為的にも修正するのが難しいため認めないものとなりました。

パラメータ名が「max_prepared_xacts」と表示されていたものが、正しく「max_prepared_transactions」となります。また、より適切な SQLSTATE を出力するようになりました。

AIX のいくつかのバージョンで発生するビルド失敗に対応したものです。

Perl はプロセスの SIGFPEハンドラ SIG_IGN にリセットします。これは後にクラッシュを引き起こします。PL/Perl 初期化後に通常の PostgreSQL のシグナルハンドラに戻すようにしました。

LIKE句にエスケープ文字が含まれていると、トリグラムインデックスを使った LIKE句を含む SQL は、誤った結果を返していました。

これまで、pg_upgrade は、関数定義などさまざまな箇所で、行末のキャリッジリターンを追加/削除してしまう可能性がありました。

定義済みエンティティを持つドキュメント型定義 (DTD) を使用している XML文書では、&entityName; という構文でエンティティを参照できます。

xmlparse() 関数は XMLデータ内のエンティティ参照を解決するために、外部のファイルや URL からデータ取得しようとします。このように権限のないデータベースユーザが OS におけるデータベースサーバプロセスのユーザ権限でデータを取得できてしまいます。

本セキュリティ問題は CVE-2012-3489 として登録されています。

pg_hba.conf に以下の行があったとして、

host    all     all   10.1.2.3/32  trust # <-- this is a trust machine

以下の SQL を一般DBユーザで実行すると、エラーメッセージを通じてファイル内容が見えてしまいます。また、ファイル内容は出ない場合でも、ファイルの存在確認はできてしまいます。

foo=> SELECT XMLPARSE (DOCUMENT '<?xml version="1.0"?>
foo'> <!DOCTYPE book [ <!ENTITY hba SYSTEM "pg_hba.conf"> ]>
foo'> <book>&hba;</book>');

ERROR:  invalid XML document
DETAIL:  pg_hba.conf:89: parser error : StartTag: invalid element name
host    all     all   10.1.2.3/32  trust # <-- this is a trusted machine
                                            ^
Entity: line 3: parser error : Failure to process entity hba
&hba;
           ^
Entity: line 3: parser error : Entity 'hba' not defined
&hba;

foo=> SELECT XMLPARSE (DOCUMENT '<?xml version="1.0"?>
foo'> <!DOCTYPE book [ <!ENTITY file SYSTEM "/proc/12345"> ]>
foo'> <book>&file;</book>');

ERROR:  invalid XML document
DETAIL:  I/O warning : failed to load external entity "/proc/12345"
Entity: line 3: parser error : Failure to process entity file
<book>&file;</book>
            ^
Entity: line 3: parser error : Entity 'file' not defined
<book>&file;</book>

xml2 モジュールで使用している libxslt ライブラリは、スタイルシートコマンドを通してファイルや URL に読み書きを提供します。したがって、データベースサーバプロセスのユーザ権限にて、データベース上のユーザからファイル読み書きができてしまいます。本修正は libxslt のセキュリティオプションでこれを防ぎます。

なお、xslt_process() 関数は以前から、使用にあたってセキュリティリスクがあることがマニュアルで示されていました。また、ビルド時に --with-libxslt を指定していない場合、xslt_process() 関数は利用できません。

本セキュリティ問題は CVE-2012-3488 として登録されています。

読み取り専用トランザクションでは XID (トランザクションID) を割り当てなくても良いようにした際に、本障害が導入されてしまいました。読み取り専用トランザクションが未だ走っている削除済ページを再利用してしまう可能性があります。

本障害で誤ったインデックス検索結果が返ることがありえますが、タイミングが限定されるため、発生確率は低いといえます。

シーケンスを作成あるいはリセットして、次に ALTER SEQUENCE を実行して、そこで nextval() を実行した後、クラッシュリカバリを経ると、シーケンスの値が nextval() の実行を反映していない値となっていました。

以下に障害発生例を示します。

$ psql
=# CREATE SEQUENCE newseq;
=# ALTER SEQUENCE newseq INCREMENT 10;
=# SELECT nextval('newseq');
 nextval
---------
       1

$ pg_ctl stop -m immediate
$ pg_ctl start
$ psql
=# SELECT nextval('newseq');
 nextval
---------
       1
(1 row)

enum型の要素追加（ALTER TYPE) と同時に実行する enum型の値を比較するクエリが失敗することがあります。以下のエラーが出ることが報告されています。

ERROR:  XX000: enum value 117745 not found in cache for enum myenumtype

起動直後、非ホットスタンバイのとき正しくない XID が返ることがありました。本障害は直前のマイナーリリースバージョンの修正で入ってしまったものです。

プライマリが pg_receivexlog や pg_basebackup などの疑似的なスタンバイ接続を同期スタンバイと誤認してしまい、それらを待ち続けてしまう可能性がありました。

以下のようなエラーメッセージが現れます。

FATAL: out-of-order XID insertion in KnownAssignedXids
LOG: startup process (PID 12345) exited with exit code 1

ストレージ装置が提供するバックアップ手段と組み合わせる時に、不都合がありました。

これまで SIGALARM を無視するようになっていたものをシグナルハンドラで処理をするようにしました。稀なケースで処理がブロックしてしまう（ずっと待ってしまう）ことを防ぐねらいです。

非同期コミットのトランザクションだけであるときにレプリケーション遅延を大幅に減らします。

書き込みに失敗した後、それ以降の全ての NOTIFY メッセージ送信は以下のような不適切なエラーメッセージが出て失敗していました。Success となっている箇所に I/O 問題のエラーが表示されるべきでした。

ERROR: could not access status of transaction 0
DETAIL: Could not read from file "pg_notify/01A3" at offset 112345: Success

修正前は一貫性に欠けた振る舞いをしていました。本修正により自動VACUUM が deadlock_timeout よりも短い時間で自動にキャンセルされることはなくなります。

「sending cancel to blocking autovacuum PID ...」というメッセージが DEBUG2 レベルで出ていましたが、LOG レベルで出るようになりました。
「DETAIL: Process ... waits for ... on ...」というロック待ちの詳細も出力されるようになりました。

サーバ再起動が頻繁に行われる環境下では、ローテーションに伴う古いログメッセージの切捨てが機能しませんでした。

以下のような SQL が動作するようになります。

=# WITH outermost(x) AS ( SELECT 1 UNION (
    WITH innermost AS ( SELECT 2 )
    SELECT * FROM innermost UNION SELECT 3))
   SELECT * FROM outermost;
 x
---
 1
 2
 3
(3 rows)

修正前は以下エラーが出て、動作しませんでした。

ERROR:  relation "innermost" does not exist
LINE 1: ...UNION (WITH innermost as (SELECT 2) SELECT * FROM innermost ...

GROUP BY や ORDER BY で指定したカラムが追加されてしまっていました。以下は修正前の実行例です。本来は１カラム出力になります。

=# CREATE TABLE int4_tbl (f1 int4);
=# INSERT INTO int4_tbl VALUES (1), (2), (3);
=# SELECT q FROM (SELECT max(f1) FROM int4_tbl GROUP BY f1 ORDER BY f1) q;
   q
-------
 (1,1)
 (2,2)
 (3,3)
(3 rows)

(正しい出力)
=# SELECT q FROM (SELECT max(f1) FROM int4_tbl GROUP BY f1 ORDER BY f1) q;
   q
-------
 (1)
 (2)
 (3)
(3 rows)

不要な pg_depend システムテーブルの項目が残っていて、その後の操作、特にインデックスのカラムに対する ALTER TABLE ... ALTER COLUMN TYPE に混乱が生じていました。

以下の手順でエラーが発生してしまう現象が報告されています。

=# CREATE TABLE z (i int4);
=# CREATE UNIQUE INDEX q ON z (i);
=# ALTER TABLE z ADD PRIMARY KEY USING INDEX q;
=# ALTER TABLE z ALTER COLUMN i TYPE int8;
ERROR:  could not open relation with OID 76087

以下のようなエラーが出ることが報告されています。

=# REASSIGN OWNED BY user1 TO user2;
ERROR:  unexpected classid 3079

以下のようにテーブル全体を指定する制約があるテーブルをベースに子テーブルを作ると、制約定義と矛盾した動作をしてしまいます。

=# CREATE TABLE pt (id int primary key, v text,
     CHECK(length((pt.*)::text) < 10));
=# CREATE TABLE ct (cid int) INHERITS (pt);

=# d ct
      Table "public.ct"
 Column |  Type   | Modifiers
--------+---------+-----------
 id     | integer | not null
 v      | text    |
 cid    | integer |
Check constraints:
    "pt_check" CHECK (length(ct.*::text) < 10)
Inherits: pt

=# INSERT INTO ct VALUES (1, 'AAAA', 100);
=# SELECT length(ct.*::text), ct.* FROM ct;
 length | id |  v   | cid
--------+----+------+-----
     12 |  1 | AAAA | 100

また、CERATE TABLE ... LIKE の場合には以下のようなエラーが生じます。

=# CREATE TABLE lt (cid int, LIKE pt INCLUDING ALL);
=# INSERT INTO lt VALUES (101, 2, 'A');
ERROR:  table row type and query-specified row type do not match
DETAIL:  Table has type integer at ordinal position 2, but query expects text.

修正後バージョンは以下のようにエラーになります。

=# CREATE TABLE ct (cid int) INHERITS (pt) ;
ERROR:  cannot convert whole-row table reference
DETAIL:  Constraint "pt_check" contains a whole-row reference to table "pt".

なお、インデックスについては以下のようなインデックスがあるテーブルを CREATE TABLE .. LIKE で参照したテーブル定義が禁止されます。

=# CREATE UNIQUE INDEX pt_unique_all ON pt ((pt.*));
=# CREATE TABLE lt (cid int, LIKE pt INCLUDING ALL);
ERROR:  cannot convert whole-row table reference
DETAIL:  Index "pt_unique_all" contains a whole-row table reference.

メモリリークを避けるため、当該コードで使われている値を空にするタイミングを修正しています。

以前は、コア機能においては、必要とされていませんでしたが、サードパーティには必要になると判断されました。

「^(foo)?bar」のような、括弧内の部分正規表現に対する検索で、不正なインデックス最適化を引き起こしていました。

以下のようなケースとなります。時分秒の判別に失敗しています。

SELECT interval '1 +2:03' minute to second;
 正： 1 day 00:02:03
 誤： 1 day 02:03:00

SELECT interval '1 +2:03:04' minute to second;
 正： 1 day 02:03:04
 誤： 1 day -00:02:03

SELECT interval '1 -2:03' minute to second;
 正： 1 day -00:02:03
 誤： 1 day -02:03:00

SELECT interval '123 2:03 -2:04';
 正： ERROR:  invalid input syntax for type interval: "123 2:03 -2:04"
 誤： 123 days 02:03:00

'123 day 2 hour 3 minute' のような書き方であれば本障害は関係しません。

pg_dump で以下のような形のビューについて、プライマリキーへの依存関係が不適切に判断されててしまいました。

 CREATE VIEW v AS
  SELECT t1.id, t1.v1, t1.v2 FROM t1
   LEFT JOIN t2 ON t1.id = t2.t1id
   GROUP BY t1.id;

プライマリキーへの依存関係を不適切に扱っている pg_dump 出力では、良くても非効率なリストアとなり、最悪の場合、並行動作オプション (-j) での pg_restore が完全に失敗していました。

pg_restore で以下のようなエラーが出る可能性があります。

pg_restore: [archiver (db)] could not execute query:
ERROR:  column "t1.v1" must appear in the GROUP BY clause or be used
in an aggregate function

カスタム形式（-Fc）アーカイブを使って並行リストアをさせる場合の問題となります。

この修正はいくつか特定ケースでの問題を回避します。特に、PostgreSQL でサポートする文字エンコーディングを Python でサポートしていないことによる問題が避けられます。

大きな機能的な変化は、サーバエンコーディングが SQL_ASCII の場合、UTF-8 文字コードを得ることになるということです。いままでは、非ASCII文字の文字列は全てエラーとなっていました。

以前は、xsltApplyStylesheet() から返ってくるエラーのチェックをしていませんでした。

モロッコ、トケラウ諸島における夏時間法の変更、カナダにおける歴史的な修正が適用されています。

この修正は、チェックポイントの間、パフォーマンスを向上させます。9.1の変更は、バックパッチするのに安全であり、十分なフィールドテストがされていると判断されました。

パスワード文字列に 0x80 という１バイトが含まれていると、その文字以降の文字列が無視されてしまい、パスワードが見た目よりも弱くなっていました。CYRILLIC CAPITAL LETTER KOPPA U+0480 (UTF8: 0xD2 0x80) など、0x80 はマルチバイト文字エンコーディングの 2バイト目以降として文字列データ型に含まれることがあります。

0x80 バイトを含むパスワードのハッシュ化データは、本修正前と本修正後で異なるものとなるため、バージョンアップにともなって、パスワード再登録が必要となります。パスワードを ASCII文字に限っているのであれば、障害による問題も、修正による影響もありません。

この問題は CVE-2012-2043 として登録されています。

(9.1.3 実行例)
postgres=# SELECT crypt(E'passxC2x80word', 'XX');
     crypt
---------------
 XXZ9QB82f805A
(1 row)

postgres=# SELECT crypt(E'passxC2x80', 'XX');
     crypt
---------------
 XXZ9QB82f805A
(1 row)

(9.1.4 実行例)
postgres=# SELECT crypt(E'passxC2x80word', 'XX');
     crypt
---------------
 XXYXXMy.GzcWk
(1 row)

postgres=# SELECT crypt(E'passxC2x80', 'XX');
     crypt
---------------
 XXZ9QB82f805A
(1 row)

これらの属性を手続き言語呼び出しハンドラ関数に適用するとサーバクラッシュが引き起こされる可能性がありました。手続き言語呼び出しハンドラ関数は、新たな手続き言語を作成するときに用意して、CREATE LANGUAGE 命令で指定するものです。

この問題は CVE-2012-2655 として登録されています。

citext は大文字小文字の区別がない文字列型を提供する追加モジュールです。

9.1.2 バージョンから CREATE EXTENSION コマンドによるアップグレードの際に、既存の citext型のカラム定義とインデックス定義に変更を加えるようになっていましたがcitext型の配列やcitext型をベースとしたドメインについて対象となっていませんでした。

以下のようなエラーが生じる可能性があります。

ERROR:  could not determine which collation to use for string comparison
HINT:  Use the COLLATE clause to set the collation explicitly.

既にアップグレードをしていて問題が生じている場合には、管理者権限ユーザで、以下アップグレードスクリプト末尾に記述されている UPDATE コマンド群を手動実行してください。WITH節で始まる UPDATE コマンドがいくつか記述されています。

《PGSQL_INSTALL_DIR》/share/extention/citext--unpackaged--1.0.sql

いくつかの歴史的なタイムゾーンで15時間以上の時間差が必要でした。そのようなタイムゾーンをデフォルトにした場合、ダンプデータが本修正前のバージョンで読み込めない可能性が生じます。

(9.1.3 の実行例)
postgres=# SELECT '2012-06-04 12:00:00+15'::timestamptz;
ERROR:  time zone displacement out of range: "2012-06-04 12:00:00+15"
LINE 1: SELECT '2012-06-04 12:00:00+15'::timestamptz;

(9.1.4 の実行例)
postgres=# SELECT '2012-06-04 12:00:00+15'::timestamptz;
      timestamptz
------------------------
 2012-06-04 06:00:00+09
(1 row)

ちょうど切り替わる日のときに正しく変換ができないケースがありました。

(9.1.3 以前における障害報告例)
postgres=# SET timezone TO 'Europe/Moscow';
postgres=# SELECT '2011-03-27 23:00:00'::timestamptz;
      timestamptz
------------------------
 2010-12-17 21:04:06+03
(1 row)

(9.1.4 の実行例)
postgres=# SET timezone TO 'Europe/Moscow';
postgres=# SELECT '2011-03-27 23:00:00'::timestamptz;
      timestamptz
------------------------
 2011-03-27 23:00:00+04
(1 row)

マルチバイト文字エンコーディングで最大長(64バイト)以上部分を切り捨てる処理が修正されました。末尾がマルチバイト文字として正しくないことがありました。

正しくない処理結果を引き起こす可能性がありました。

トランザクション周回したときに、スタンバイ側で適切な値が返らないことが報告されていました。

(9.1.3 再現例)
postgres=# CREATE TABLE tbl (q1 int, q2 int);
CREATE TABLE
postgres=# SELECT * FROM tbl t1 LEFT OUTER JOIN
  (SELECT q1 AS x, 99 AS y FROM tbl t2) ss on t1.q2 = ss.x
   WHERE 1 = (SELECT 1 FROM tbl t3 WHERE ss.y IS NOT NULL );
ERROR:  Upper-level PlaceHolderVar found where not expected

外部結合で NULL の可能性のある外側クエリの変数を参照するサブクエリにおいて、問題が生じる可能性があります。該当する形状のクエリにおいて、本来発生すべきでないエラーが発生します。9.0.x、8.4.x においては、サブクエリに渡る値がNULL になるべきところそうならないため、おそらくは誤った値が黙って返ります。

該当する場合に著しく悪いプランが選択されていました。

(9.1.3 の悪いプラン例)
postgres=# EXPLAIN SELECT (id, v) FROM
  (SELECT 1 as c, * FROM t1 UNION ALL SELECT 2 as c, * FROM t2) as s
   WHERE c = 2 ORDER BY  v, id;
                              QUERY PLAN
----------------------------------------------------------------------
 Sort  (cost=43.17..43.19 rows=10 width=37)
   Sort Key: t1.v, t1.id
   ->  Result  (cost=0.00..43.00 rows=10 width=37)
         ->  Append  (cost=0.00..43.00 rows=10 width=37)
               ->  Seq Scan on t1  (cost=0.00..21.50 rows=5 width=37)
                     Filter: (1 = 2)
               ->  Seq Scan on t2  (cost=0.00..21.50 rows=5 width=37)
                     Filter: (2 = 2)

(9.1.4 のプラン - 実際の実行時間はこちらが速い)
                               QUERY PLAN
-------------------------------------------------------------------------
 Sort  (cost=68.83..71.33 rows=1000 width=37)
   Sort Key: t2.v, t2.id
   ->  Result  (cost=0.00..19.00 rows=1000 width=37)
         ->  Append  (cost=0.00..19.00 rows=1000 width=37)
               ->  Seq Scan on t2  (cost=0.00..19.00 rows=1000 width=37)

pg_attribute はテーブルにどのようなカラムが定義されているかを格納するシステムテーブルです。テーブル数が多いとき、大きくなりがちです。

pg_attribute のサイズが shared_buffers の 1/4 を超える場合、セッションスタート時にしばしば必要となるキャッシュ再構築を行うコードが同期スキャン処理を引き起こし、通常よりも時間を要していました。一度に多数のセッション開始（接続）が発生する場合、特に深刻でした。

有効行が無いページを読んでいる場合、その間、割り込みに反応することができませんでした。

クエリキャンセルの割り込みのタイミングによっては予期せぬ良くない結果を招く可能性がありました。

曖昧なテーブル名、カラム名を伴う稀なケースで、ダンプリストア後に出力結果が変化してしまう危険性がありました。

E'\0' は nullマーカーとして許されるべきですが、動作しませんでした。8.4 バージョンで入り込んだ問題で、8.3.x では動作していました。

(9.1.3 エラー例)
postgres=# COPY t FROM '/home/postgres/file.copy' NULL E'\0';
ERROR:  invalid byte sequence for encoding "UTF8": 0x00
HINT:  This error can also happen if the byte sequence does not match the
encoding expected by the server, which is controlled by "client_encoding".
CONTEXT:  COPY t2, line 9: "3   "

(9.1.3 の誤った出力例 - aテーブルへのINSERT に Output: b.bc2 と出ている)
postgres=# CREATE TABLE a (ac1 int, ac2 int);
postgres=# CREATE TABLE b (bc1 int, bc2 int);
postgres=# EXPLAIN (VERBOSE) WITH wcte AS
   (INSERT INTO a VALUES (42,47) RETURNING ac2)
    DELETE FROM b USING wcte WHERE bc1 = ac2;

                               QUERY PLAN
-------------------------------------------------------------------------
 Delete on public.b  (cost=0.04..39.58 rows=11 width=34)
   CTE wcte
     ->  Insert on public.a  (cost=0.00..0.01 rows=1 width=0)
           Output: b.bc2
           ->  Result  (cost=0.00..0.01 rows=1 width=0)
                 Output: 42, 47
   ->  Hash Join  (cost=0.03..39.57 rows=11 width=34)
         Output: b.ctid, wcte.*
         Hash Cond: (b.bc1 = wcte.ac2)
         ->  Seq Scan on public.b  (cost=0.00..31.40 rows=2140 width=10)
               Output: b.ctid, b.bc1
         ->  Hash  (cost=0.02..0.02 rows=1 width=32)
               Output: wcte.*, wcte.ac2
               ->  CTE Scan on wcte  (cost=0.00..0.02 rows=1 width=32)
                     Output: wcte.*, wcte.ac2

歴史的に PREPARE TRANSACTION は、保持しているセッションレベルのアドバイザリロック（勧告的ロック）を無視する仕様ですが、エラーが出るようになっていました。

(9.1.3 エラー例)
postgres=# BEGIN;
postgres=# SELECT pg_advisory_lock(1234);
postgres=# PREPARE TRANSACTION 'P1234';
ERROR:  cannot PREPARE when session locks exist

9.1 でトランザクションレベルのアドバイザリロックが導入されたことに関連して本問題が入り込みました。

TRUNCATE で初期化フォークファイルが作られませんでした。クラッシュ時に初期化フォークから初期化しなければいけない場合に、問題が出る可能性がありました。

ALTER DATABASE SET などで存在しないスキーマを search_path に指定することができます。9.1.3 までは、ALTERコマンドまでは成功しますが、適用される段階でスキーマが存在しないとエラー扱いとなって実際には設定されない動作となっていました。

これが 9.1.4 ではそのまま設定されます。

9.1.4 でも SETコマンドで設定する場合（つまりインタラクティブな場合）には、存在しないスキーマを含んだ指定はエラーとなります。

拡張モジュールのアップデートスクリプトの中に ALTER TABLE がある場合などで発生し、拡張モジュールをアップデートする際に以下のようなエラーとなります。内部的に一時テーブルが使われていて、その扱いに問題がありました。

(エラー発生例)
postgres=# ALTER EXTENSION myext UPDATE TO '0.2';
ERROR:  cannot drop table pg_temp_28906 because extension myext requires it
HINT:  You can drop extension myext instead.

これまで通常のバックエンドプロセス以外の子プロセスにはスタック深度のチェックが行われていませんでしたが、これを行うようになりました。特に autovacuum のワーカプロセスは、
任意のユーザコードを実行することがあるため、例えばインデックス定義に無限に再帰処理を行うような障害があった場合、インスタンス全体のダウンに至る危険がありました。

高負荷のときに大きいメッセージの再構築に失敗することがありました。これまで同時に行えるメッセージ再構築処理は20個までという恣意的な上限があったため、問題が生じていました。

インデックス作成時に本エラーがでることが報告されていました。

不要な PANIC が発生することが考えられました。

このようなケースではスタンバイサーバへの書き込みは必要ありませんが、一部のコードではそのことを認識せず待ってしまっていました。

エラーの場合でも正常返り値で終了してしまうことがありました。

対象が関数の最初の変数であるとき値が NULL になってしまいました。

(9.1.3 再現例)
postgres=# CREATE TABLE t1 (i int);
postgres=# CREATE FUNCTION f1 (OUT r1 INT) LANGUAGE plpgsql AS $$
  BEGIN
   INSERT INTO t1 VALUES (1);
   GET DIAGNOSTICS r1 = row_count;
  END $$;
postgres=# SELECT f1();   ⇒ 1 でなく NULL が返ってしまう

以下のようなエラーが出る例が、PL/Perl 関数中の動作で、PL/Perl関数によるトリガ起動を引き起こす場合に発生していました。

ERROR:  couldn't fetch $_TD at line 4.
CONTEXT:  PL/Perl function "myplperlfuxnc"

9.1 にて、ディクショナリのような他の形式をサポートするようにした際に混入した障害です。

pg_dump はデータベースに多数のスキーマが含まれていたり、多数のオブジェクトが依存関係のループをなしていたり、多数のシーケンスが在った場合に、非常に遅い動作となることがありました。

これは max_locks_per_transaction 設定の上限を超えるのを避けるためです。この振る舞いは新たな -l オプションによって調整できます。

南極、アルメニア、チリ、キューバ、フォークランド諸島、ガザ、ハイチ、ヘブロン、モロッコ、シリア、トケラウ諸島における夏時間法の変更、カナダにおける歴史的な修正が適用されています。

以下のように一般ユーザ foo が テーブル t0 にトリガを作る権限をもっているとき、以前のバージョンでは、指定したトリガ関数に実行権限が無くともトリガが作れてしまいました。

db=# CREATE FUNCTION f0_trig () RETURNS TRIGGER LANGUAGE PLPGSQL
     AS $$ BEGIN 《何らかの処理定義》RETURN NEW ; END $$;
db=# REVOKE EXECUTE ON FUNCTION f0_trig() FROM public;

db=> CREATE TABLE t1 (id int, v text);
db=> CREATE TRIGGER tr0 BEFORE INSERT ON t1 EXECUTE PROCEDURE f0_trig();
(修正後は「ERROR:  permission denied for function f0_trig」となる）

トリガ関数が、関数所有者の権限で実行される SECURITY DEFINER 設定で定義されている場合、アクセス制限における脆弱性となりえます。別テーブル用の本来実行できないトリガ関数が、一般ユーザが作ったダミーのテーブルに対してトリガ設定することで、実行できてしまいます。この問題は CVE-2012-0866 として登録されています。

libpq と サーバは共にSSL証明書から抽出したコモンネームを 32バイトで切捨てていました。通常は予期せぬ認証失敗が生じる以上の問題は起きません。しかし、ある証明書の保持者が他人に成りすますことができるシナリオがありえました。ちょうど 32バイトのコモンネームをもつ被害者に対して、攻撃者は信頼されたCA(認証局)に、その文字列をプレフィックスとして持つコモンネームの証明書を発行させて成りすましを実現します。

なお、本方法でサーバに成りすますには更にクライアント接続を乗っ取ることが必要となります。本件は CVE-2012-0867 として登録されております。

pg_dump は以下のようにコメントを伴った出力をします。このとき、オブジェクト名に改行が含まれない想定の実装となっていました。

--
-- Name: t1; Type: TABLE; Schema: public; Owner: postgres; Tablespace:
--

CREATE TABLE t1 (
    id integer NOT NULL,
    v text
);

以下のような改行を含むようなテーブル名でテーブルを定義してダンプを取ると、

db=> CREATE TABLE "t2
db"> drop database x;
db"> -- :P" (id int);

以下のようなダンプデータが生成されて、命令（この例では DROP DATABASE文)が混入してしまいます。

-- Name: t2
drop database x;
-- :P; Type: TABLE; Schema: public; Owner: postgres; Tablespace:
--

CREATE TABLE "t2
drop database x;
-- :P" (
    id integer
);

本件は CVE-2012-0868 として登録されています。

データ挿入によって生じるインデックスページ分割が、同時実行の VACUUM がインデックス要素を削除するのを失敗させることがありました。対応するテーブルの行が削除された後、誤ったインデックス要素が "ERROR: could not read block N in file ..." などを引き起こします。また、インデックス先に別のデータが置かれることで、誤った問い合わせ結果が返ることも考えられます。

本障害はバージョン 8.2 から存在していましたが、発生頻度が低いため、これまで明らかにされませんでした。本障害で破損したインデックスは、REINDEX で修復されます。

再生ロジックでは共有バッファをゼロ埋めすることがあり、バッファ内容は一時的に無効になります。これにより、ホットスタンバイモードでは、並行して実行している問い合わせが無効なデータを見てしまうことが起こり得ます。

本障害による様々な症状が考えられますが "ERROR: invalid memory alloc request size ... " が出ることが一般的です。

INSERT、UPDATE、DELETE を含む WITH節は、親の UPDATE または DELETE 文が、READ COMMITTED モードにて、同時実行の更新により行の再評価を要する場合にクラッシュします。

read-write の SERIALIZABLE トランザクションを終了するとき、残っているアクティブな SERIALIZABLE トランザクションが全て read-only である場合に、クラッシュする可能性がありました。

SSI(Serializable Snapshot Isolation)トランザクションが採用された 9.1.x バージョンで該当します。

ロジックに誤りがあり、ホットスタンバイモードで動作しているときバックエンドプロセスがクラッシュすると、インスタンスを再起動するのではなく、終了させるようになっていました。

TOASTテーブルのインデックスを CLUSTER、VACUUM FULL で処理するとき、"ERROR: duplicate key value violates unique constraint .. " を引き起こす可能性がありました。

本修正以前には、ALTER TABLE .. OWNER TO を行っても、以下のようにカラム単位権限が更新されず、元の所有者名が残ってしまいます。

db=# z t2
                          Access privileges
 Schema | Name | Type  | Access privileges | Column access privileges
--------+------+-------+-------------------+--------------------------
 public | t2   | table | baz=arwdDxt/baz  +| c1:                     +
        |      |       | foo=r/baz         |   bar=r/baz

db=# ALTER TABLE t2 OWNER TO foo;
db=# z t2
                          Access privileges
 Schema | Name | Type  | Access privileges | Column access privileges
--------+------+-------+-------------------+--------------------------
 public | t2   | table | foo=arwdDxt/foo   | c1:                     +
        |      |       |                   |   bar=r/baz

これまで REASSIGN OWNED で外部データラッパー、外部サーバを持つ所有者の変更を試みると "ERROR: unexpected classid" が出ていました。

default_text_search_config、default_tablespace、temp_tablespaces で設定が可能になります。未だ有効でないテキスト検索設定や、未だ作られていないテーブルスペースを指定することができます。search_path については以前から実在しないスキーマを設定できるようになっていました。

以下のようなケースでエラーが発生します。

db=> CREATE TABLE t3 (v varchar(25));
db=> INSERT INTO t3 VALUES ('AA' COLLATE "C");
ERROR:  unsupported node type: 325
STATEMENT:  INSERT INTO t3 VALUES ('AA' COLLATE "C");

DROP TABLE はトランザクションコミット後に対応するファイルの削除を引き起こします。例えばファイルアクセス権限の問題などでファイル削除に失敗した場合、トランザクションをアボートさせるには遅いので、警告メッセージを出して処理を継続します。バージョン 8.4 からこのロジックが壊れており、同状況で PANIC（クラッシュ終了）とデータベース再起動の失敗を引き起こしていました。

WAL再生でテーブルスペースのディレクトリを削除しようとして、何らかの理由（アクセス権限不足などで）で失敗することがあります。以前は、リカバリ処理が PANIC となり、データベースは手動で補正しないかぎり再起動できない状態になりました。本修正でログに問題を報告し、処理は継続するようになりました。

0番トランザクションによってロック待ちが生じたという誤ったログが出力されることがありました。本障害により、スタンバイサーバでアサートエラーが発生することが知られています。それ以外にも深刻な問題を引き起こす可能性があります。

これまでは WAL再生モード（リカバリ）を終了するまで、OIDカウンタは最大値で止まったままとしていました。これでおよそ実用的には問題ありませんでした。しかし、スタンバイサーバがプライマリに昇格する場合に OID カウンタを適切な値まで進めるのに時間を要することがあり、修正されました。

これまでは一つの WALレコードが再生されるまでは誤った値を見せていました。

本来マッチすべき文字列よりも幅広く、マッチしたものとしていました。以下例ではパターン '^([bc])1*$' に対して、実際には '^([bc])(1+|[bc]*)$' というパターンであるかのような処理がこれまで行われていました。

(本来マッチするパターン)
db=> SELECT 'c' ~ '^([bc])1*$';   ⇒ TRUE
db=> SELECT 'ccc' ~ '^([bc])1*$'; ⇒ TRUE

(修正前)
db=> SELECT 'bcc' ~ '^([bc])1*$'; ⇒ TRUE

(修正後)
db=> SELECT 'bcc' ~ '^([bc])1*$'; ⇒ FALSE

前回マイナーリリースにて導入された障害となります。メモリリークを引き起こし、特にこれら型のカラムに Btreeインデックスを作るときに大きく現れます。

9.1.2 バージョンの修正の際に混入した誤りとなります。

以下のような再帰問い合わせ実行時にプランナのエラーが発生していました。

db=> CREATE TABLE parent (id int, val text);
db=> CREATE TABLE child1 () INHERITS (parent);
db=> CREATE TABLE child2 () INHERITS (parent);
db=> INSERT INTO parent VALUES (1, 'p1');
db=> INSERT INTO child1 VALUES (11, 'c11'),(12, 'c12');
db=> INSERT INTO child2 VALUES (23, 'c21'),(24, 'c22');

db=> WITH wcte AS ( INSERT INTO child1 VALUES (42, 'new')
     RETURNING id AS newid )
         UPDATE parent SET id = id + newid FROM wcte;
ERROR:  could not find plan for CTE "wcte"

db=> WITH rcte AS ( SELECT max(id) AS maxid FROM parent )
     DELETE FROM parent USING rcte WHERE id = maxid;
ERROR:  could not find plan for CTE "rcte"

本障害は通常の --enable-cassert を指定しないビルドでは影響ありません。

ほとんどの場合、--enable-cassert を設定している場合にアサートエラーが発生するだけですが、そのほかの問題が発生する可能性もあります。

通常は本エラーは表面化しません。しかし、デバッグ版の Windows では Exception を引き起こします。

本来より短いコンテキストで回収されるべきメモリが、関数終了時まで回収されません。

本関数は、型グロブまたは $^V のような読み込み専用オブジェクトを扱う際にクラッシュします。PL/Perl でこれを避けるようになりました。

--schema や --table オプションで拡張モジュール自体をダンプ対象としている場合を除いて、拡張モジュールの設定テーブルはダンプ対象外となります。

子テーブルのカラムが親テーブルのカラムにおけるデフォルト式あるいは NOT NULL 指定について、文面上は一致していてもスキーマサーチパスの違いなどで実際には同一でないような指定があるとき、同一のものと誤認してしまう問題がありました。

以下をダンプ、リストアすると、s1.t1 テーブルと s2.t1 テーブルが同一シーケンスをデフォルト値とするように変ってしまっていました。

db=> CREATE SCHEMA s1;
db=> CREATE SCHEMA s2;
db=> CREATE TABLE s1.t1(c1 bigserial primary key, c2 text);
db=> CREATE TABLE s2.t1(c1 bigserial primary key) inherits (s1.t1);

pg_dump にて --inserts または --column-inserts オプションを指定して取得したダンプファイルを pg_restore でリストアするときにエラーが発生します。ダンプファイル自体には誤りはなく、pg_restore の問題となります。また、直接リストアするのでなくテキストモードで出力させる場合には問題となりません。

以下に発生例を示します。

$ pg_dump -Fc --inserts db > dump
$ createdb dbx
$ pg_restore -d dbx dump
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 2635; 0 16519 TABLE DATA t postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  syntax error at or near "INT"
LINE 66: INSERT INT
                ^
    Command was: INSERT INTO t VALUES (1, 'AAAAAAAAAAAAAA');

9.1.0 は当初から障害がありましたが、9.0.x 系クA係.3.x系については前回、あるいは前々回のマイナーバージョンアップで混入した障害となります。

PL/Python を含む 9.1.x 以前のデータベースを pg_upgrade でアップグレードする場合、本障害により失敗していました。

pg_upgrade が pg_class の OID を保護するようになったため、regclass カラムを扱えない制約がなくなります。

これによりユーザホームディレクトリが /dev/null などに設定してあって証明書がない場合にも SSL接続が可能となります。

本機能はすでに実装されていましたが、誤ってエラーチェックで弾くようになったままとなっていました。

連番を付加した自動的な命名が行われるようになります。

トップレベルにブランケット([])が使われていましたが、ブレース({})が適切でした。

これらの関数はある種の無効入力エラーを報告せず、誤った入力に対し、ランダムなゴミ値を返していました。

コードは本来よりも1バイト多く読み込もうとしており、まれにクラッシュを引き起こします。contrib/test_parser はサンプルであるため、これ自体はセキュリティ問題ではありません。

この関数は、以前使っていた ARMv6 以降では推奨されず使えない SWPB 命令を置き換えます。報告によると、古いコードは最近のARM基盤でも直接的な失敗にはなりません。しかし、同時アクセスの連動が行なえず、マルチプロセス処理での奇妙な失敗が起こります。

これは最近の版の gcc が独創的な結果を生成し、分裂したシナリオになるのを防ぎます。

configureスクリプトでは、これまでこの組合せは動かないとしていました。しかし FreeBSD が問題を修正したので、エラーチェックを外しました。

この情報スキーマのビューは各テーブルに定義された外部キーの一覧を返すもので、誤った結果を返す場合がありました。
既存のデータベースクラスタに修正を適用するには、各データベースに対して情報スキーマを作り直さないといけません。
インストール先の share 以下に情報スキーマ定義の SQLファイルがあります。

以下にコマンド例を示します。

  $ pg_config --sharedir
  /usr/local/pgsql/share

  $ psql -U postgres db
  db=# DROP SCHEMA information_schema CASCADE;
  db=# i /usr/local/pgsql/share/information_schema.sql

citext モジュールは大文字小文字を区別しない文字列型を提供するものです。
pg_upgrade で 9.1 以前のデータベースクラスタからアップグレードするときに、存在する citext 型のカラムとインデックスが正しくマークされませんでした。
この結果、文字列比較で以下のようなエラーが生じました。

ERROR:  could not determine which collation to use for string comparison
HINT:  Use the COLLATE clause to set the collation explicitly.

本修正は「CREATE EXTENSION citext FROM unpackaged」コマンドで、モジュールをアップグレードする場合にも対応します。

既にアップグレードをしていて問題が生じている場合には、管理者権限ユーザで、以下アップグレードスクリプトの末尾に記述されている UPDATE コマンドを手動実行してください。
share ディレクトリは「pg_config --sharedir」で確認できます。

PGSQL_INSTALL_DIR/share/extension/citext--unpackaged--1.0.sql

ここでスカラ値とは複数行でなく一行分の値という意味です。クラッシュは対象行が同時更新されている場合のみ発生するため、発生したりしなかったりします。

WAL レコードのリプレイは、クラッシュリカバリ、PITR バックアップからのリストア、レプリケーションで実行される動作です。

この誤りにより、クラッシュ後やホットスタンバイサーバで一時的にインデックス要素の検索に失敗します。ただし、当該インデックスに対する次の VACUUM で修復されます。

「ALTER TABLE ADD COLUMN」でテーブル変更されていると、そのテーブル内容を他のテーブルに転写するとき、データ破損が生じることが稀にありました。

この問題が明白に現れるのは 8.4 以降バージョンです。しかし、別の実行パターンで同様の誤りを引き起こす可能性があるため、それ以前のバージョンにも修正を適用しています。

syscache とはシステムカタログ内容のキャッシュです。

典型的な症状としては、一時的に「missing chunk number 0 for toast value NNNNN in pg_toast_2619」のようなエラーが発生します。メッセージで示される TOAST テーブルは常にシステムカタログに属するものとなります。

これまでは、参照されているものでも削除できてしまいました。そのため、以下のようなエラーが発生しました。

=# CREATE FUNCTION f2(x int DEFAULT f1(1)::int) RETURNS int
   LANGUAGE sql AS $$ SELECT 1; $$;
CREATE FUNCTION
=# DROP FUNCTION f1(int);
DROP FUNCTION
=# SELECT f2();
ERROR:  cache lookup failed for function 25244

この更新を適用しても、依存先オブジェクトが失われている状態は回復しません。デフォルト値にビルトインオブジェクト以外を使用している各関数について CREATE OR REPLACE FUNCTION を実行しなおして確認することが推奨されます。

本障害では以下のエラーが生じます。「ERROR: variable not found in subplan target lists」また、外部結合を伴うとき誤った問い合わせ結果が返る可能性がありました。

これまで「ERROR: could not find pathkey item to sort」というプランナのエラーが出ていました。

ここでの collation とはロケールに従った文字照合のことを指します。
「・・・ WHERE hstore_col ? 'text'」など、collation 適用不能な型と可能な型とで比較する場合に、インデックスが想定通り使われないことがありました。

JOIN REMOVAL とは不要な結合を除去するオプティマイザの働きです。遅延評価のユニーク制約はトランザクション内では値を拘束しないことから、誤った結果を返すことがありえました。

これは PostgreSQL サーバのコアコードには影響ありませんが、アドオンコードが、DatumGetInetP() が一般的な習慣に従ってデータ展開するものと期待していた場合に、クラッシュするのを防ぎます。

C言語関数や独自インデックスの記述に影響があります。

全ての標準 lc_monetary フォーマットオプションをサポートするわけではないとしても、入出力関数は一貫性を欠いていました。ダンプしたものが再読み込みできないロケールがありました。

transform_null_equals は CASE 構文から内部的に生成されたイコールチェックは対象外で、「foo = NULL」式が直接記述された場合だけ効果があるべきです。

そのテーブル自身を参照しているカスケード外部キーについて、一行の更新に対して ON UPDATE トリガーと CHECK トリガーが一つのイベントとして発火するようになりました。

ON UPDATE トリガーを先に実行しなければいけないところ、CHECK を最終的な状態になっていない行に実行し、不適切なエラーが出ることがありました。

これは 9.2 バージョンで導入された変更の一部を後方適用したものです。本変更を適用するにはトリガーが正しい順序になるように外部キー制約を削除し、再作成する必要があります。

不正な拡張モジュール依存関係管理で、奇妙な振る舞いが生じるのを防ぎます。

テーブルの行型(rowtype)や自動生成された配列型は、pg_depend において拡張モジュールの一員であるとする必要がありません。これらがあることで拡張モジュールのアップグレードが複雑になっていました。

これ自体では害はありませんが、ある種のプラットフォームで不快なカーネルログメッセージが生じていました。

自動バキュームはこれまではクラスタ全体のデフォルトトランザクション隔離レベルで動作していました。しかし、READ COMMITTED よりも高レベルで動作する必要はなく、SERIALIZABLE での動作は他のプロセスに不要な遅延をもたらしていました。

これまでは、これらは pg_settings ビューで正しく表示されませんでした。

これまでは空白行は除外されていました。これは空白行を含む文字列リテラルを表現するときなどに問題を引き起こしていました。

C言語ライブラリ関数 malloc(0) が NULL を返す場合に該当します。

pg_dump は歴史的には -F 指定を伴わない -Z オプションを受け付けました。これは gzip 圧縮されたテキスト形式の出力をします。この振る舞いが復活しました。

排他制約が正しく扱えるようになりました。Windows における失敗を回避します。8.4 データベースの TOASTテーブル名の不一致についてエラー等が出なくなります。

9.1 より前のバージョンの、 void 型を返す PL/Perl 関数は返し値となる最後の Perl 文を無視するという振る舞いに戻されました。9.1.0 では、最後の分がリファレンスを返すと、エラーを投げていました。

また、文字列が型の入力フォーマットに合っていれば、必ず複合型むけの文字列値を返すようにします。

加えて、関数が関数が配列や複合型を返すように定義されていないとき、Perl の配列やハッシュを返そうとした場合、それぞれエラーを投げるようになりました。
以前は 'ARRAY(0x221a9a0)' や 'HASH(0x221aa90)' といった文字列が返されていました。

CREATE EXTENSION でモジュールをロードするときに助けとなります。

一部の関数で palloc() の結果がゼロ埋めされていると想定していました。

これらのテストには root権限が必要で、自動実行させるのには実際的ではありませんでした。代わりに手動で行うものとして、テストスクリプトは提供されます。

pgstattuple() にも同様の問題があり、これは過去に修正されています。

ソースコード中の設定項目 WAL_DEBUG が 9.1.0 でデフォルトで有効となっていました。これは軽微な負荷ですがデフォルトとすることは意図したものではないので元に戻されました。

src/include/pg_config_manual.h に設定箇所があります。

以下のような長い表示が出ていました。

ERROR:  42703: column "foo" does not exist
LINE 1: select foo;
               ^
LOCATION:  transformColumnRef, /build/buildd-postgresql-9.1_9.1.1-3-i386-AP0ovQ/postgresql-9.1-9.1.1/build/../src/backend/parser/parse_expr.c:766

ソースを展開したディレクトリ上でビルドする場合には問題となりません。

中部標準時を CST6CDT でなく CST6 に割り当てます。一般にDST (夏時間) はアメリカ中部で常に使われるわけではないからです。

ブラジル、キューバ、フィジー、パレスチナ、ロシア、サモアにおける夏時間法の変更が反映されます。また、アラスカと英領東アフリカの歴史的な修正が含まれます。

これまでは クラッシュを引き起こしていました。

多数の行を持つテーブルに対するGiSTベースの排他制約の検証など、分散した GiSTインデックススキャンを多数行うコマンドで、本メモリリークにより、一時的に大量のメモリを必要とすることがありました。

これまで可能であったものが、9.1.0 で以下のようにエラーになることがありました。

=# CREATE TEMP TABLE pg_temp_2.page (id int, v text);
ERROR:  temporary tables cannot specify a schema name

システムカタログの行の再配置が、同時実行中のプロセスに認識されず、その行を更新しようとするときにカタログが壊れるケースがありました。
最悪の場合、テーブルが完全に失われます。

この誤りはシステムカタログに対する VACUUM FULL または CLUSTER の後に一時的に障害を引き起こします。

このバグにより、システムカタログの REINDEX の後、インデックス破損が生じる可能性がありました。ユーザインデックスに影響は無いものと考えられます。

おそらく発生する可能性は低いですが、インデックス破損を招きます。

必要メモリ量を過小評価したために問題が生じており、サーバプロセスのクラッシュを招きます。

可能性は極めて低いですが、サーバプロセスがクラッシュするおそれがありました。

これまで postmaster は、そのような状況でパニックになっていましたが、実際には正常な状態でした。

新しいバックエンドプロセスが無効化メッセージを見逃し、最新でないファイルを読む可能性がありました。
結果、システムカタログへのアクセスで奇妙な失敗が生じます。典型的には「could not read block 0 in file ...」というエラーが、起動後に生じます。

同じ更新で、BEFORE ROWトリガーが在って動作している場合に、AFTER ROW UPDATEトリガーのWHEN条件の評価でクラッシュする可能性がありました。

これはJOIN結果の劣悪な見積りを招く誤ったプランナヒューリスティックを修正します。

外部結合の結果に NULL が不適切に出現する可能性がありました。
以下は発現例。sub1 または sub2 だけ出力する SELECT文に分けて実行するとNULL は出現しないが、それらを外部結合すると NULL が現れてしまいます。

=# SELECT * FROM (select 1 as key1) sub1
   LEFT JOIN
    (SELECT sub3.key3, sub4.value2 FROM (SELECT 1 as key3) sub3
     LEFT JOIN (SELECT sub5.key5, COALESCE(sub6.value1, 1) as value2
     FROM (SELECT 1 as key5) sub5 LEFT JOIN (SELECT 1 as key6, value1
     FROM (SELECT NULL::integer as value1) sub7 WHERE false) sub6
     ON false) sub4 ON sub4.key5 = sub3.key3) sub2
   ON sub1.key1 = sub2.key3;

 key1 | key3 | value2
------+------+--------
    1 |    1 |
(1 row)

通常はプランニング上の理由により、空テーブルは最小だがある程度のサイズを持つものと仮定します。このヒューリスティックは、テーブル継承における親テーブル（たいていは空テーブル）に対しては弊害が大きいと考えられます。

プランナが本来等価なデータを等しくないと判断する状況が生じ、最適化が劣悪なものになる可能性がありました。

本問題で「ERROR: bogus varno: 65001」のようなエラーが発生します。

同じカラムで別タイプのインデックス可能な条件が組み合わされている場合に問題があります。
該当するケースでは、問い合わせで結果が 0行であるべきところで出力が生じる現象を引き起こします。
以下は再現例です。

=# CREATE TABLE foo (a int);
=# CREATE INDEX foo_a_idx ON foo (a);
=# INSERT INTO foo VALUES (10), (NULL);
=# SELECT 1 FROM foo WHERE a IS NULL AND a > 10000;
 ?column?
----------
        1
(1 row)

クラッシュリカバリでコミット済みトランザクションが失われる可能性がありました。

「CREATE VIEW test_view AS VALUES (1), (2), (3) ORDER BY 1」というビューをダンプすると、以下のようになってしまいます。

CREATE VIEW test_view AS
    VALUES (1), (2), (3) ORDER BY "*VALUES*".column1;

この操作はもともと機能しないと考えられ、問題を引き起こします。

これまでビジビリティマップにより処理を省略している場合、reltuples、relpages は更新されませんでした。結果として、自動VACUUM による、テーブル毎のVACUUM実施判断が劣悪になることがありました。

典型的な症状としては "The function requested is not supported" というエラーが出ます。

「SELECT pg_reload_conf();」でサーバプロセスがクラッシュするケースが報告されています。

従来の hostssl の行は無視されるという振る舞いの方がよりユーザフレンドリであるという結論になりました。

これは与えられたシードを正しく適用できませんでした。ランダム性が推測に対して弱くなるため、潜在的なセキュリティ問題をはらんでいます。OS が同名関数を提供するため PostgreSQL の srand48 関数は多くのプラットフォームでは使用されません。

'FM' (fill mode 充填モード) と小数点の後の数字位置指定なしの整形で、小数点の左側のゼロが誤って除去されていました。
以下は再現例です。本来は「10」が出力されなければいけません。

=# SELECT to_char(10, 'FM99.');
 to_char
---------
 1

過剰なチェックは保持すべき長さ修飾の破棄を引き起こしていました。

Windows ロケールの一部（People's Republic of China など）で問題が起きていました。

システム用に予約された接頭辞 'pg_' で始まるスキーマは対象から外すようになりました。 テーブル OID が移行後に不一致となることを防ぎます。

アップグレード後に pg_clog/ 下のファイルの早すぎる削除を引き起こす可能性がありました。

standard_conforming_string = on で作られたアーカイブファイルを直接データベースにリストアするとき、pg_restore は不正なコマンドを発行する可能性がありました。

サポートされないケースかをリストア動作を行う前に確認して報告するようになります。

特に SSL接続開始時に fork に失敗したときのエラー報告が、適切ではありませんでした。

char が符号付きであるプラットフォームで不適切なコードでした。これにより暗号化されたパスワードが本来よりも脆弱になります。

カナダ、エジプト、ロシア、サモア、南スーダンの夏時間法の変更が適用されています。

ホットスタンバイでないリカバリの場合に稀に発生していました。

8.3 と 8.2 で使用している autoconfバージョン はコンパイラのリンク時の最適化にだまされることがありました。

サーバプロセスがクラッシュする僅かな可能性がありました。