1. /
  2. /
  3. PostgreSQL 9.4.23 に関する技術情報

PostgreSQL 9.4.23 に関する技術情報

このリリースは 9.4.22 からの修正リリース（2019年6月20日リリース）です。

9.4.x からのアップデートではダンプ、リストアは不要です。
9.4.18より前のバージョンからのアップデートの場合には 9.5.18 のリリース情報も確認してください。

PostgreSQL 9.4.22 から 9.4.23 への変更点

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

  1. SCRAM検証のパース処理におけるバッファオーバフロー障害が修正されました。 (Jonathan Katz, Heikki Linnakangas, Michael Paquier) (11)(10)

    2. 認証を受けるユーザは誰でも、パスワードを意図的に作りこんだ値に変更することで、スタックのバッファオーバフローを起こすことができました。さらに PostgreSQLサーバをクラッシュさせることもできました。これにより PostgreSQLを実行するOSユーザで任意コードを実行できる可能性がありました。

    類似のオーバフロー障害が libpq にもあり、これはよからぬサーバがクライアントをクラッシュさせたり、クライアント側OSユーザで任意コードを実行させたりできる可能性がありました。(CVE-2019-10164)

  2. 実行時パーティション除外のロジックで、いくつかの誤りが修正されました。 (Tom Lane, Amit Langote, David Rowley) (11)

    3. 除外に使われる比較値が（プリペアドステートメントのパラメータで）動的に決定される場合や、複数のレンジパーティション列が除外の判断に関わる場合、あるいは、STABLEな（IMMUTABLE でない）比較演算子が関わる場合に、本障害がパーティションテーブルに対する問い合わせに誤った結果をもたらすおそれがありました。 

    （上記の内「複数レンジパーティション列が関与する」ときの障害動作例）
db=# CREATE TABLE t2p (a int, b int, c int) PARTITION BY RANGE (a, abs(b), c);
db=# CREATE TABLE t2p0 PARTITION OF t2p
       FOR VALUES FROM (0, 0, 0) to (0, maxvalue, maxvalue);
db=# CREATE TABLE t2p1 PARTITION OF t2p
       FOR VALUES FROM (1, 1, 1) TO (2, minvalue, minvalue);
db=# CREATE TABLE t2p2 PARTITION OF t2p
       FOR VALUES FROM (2, minvalue, minvalue) TO (3, maxvalue, maxvalue);
db=# INSERT INTO t2p VALUES (0, 1, 1), (1, 1, 1), (2, 1, 1);

（以下は 3行返るのが正しい）
db=# SELECT * FROM t2p WHERE a < 3 AND abs(b) = 1;
 a | b | c
---+---+---
 1 | 1 | 1
(1 row)
  3. 新たなパーティションにトリガ定義をコピーするときにクラッシュする可能性があり、修正されました。 (Tom Lane) (11)

    4. パーティションテーブルにトリガが定義されている状態で、属するパーティションを新たに追加したときにクラッシュする動作が報告されました。

  4. テーブルが部分的な排他制約を持つ場合に、ALTER TABLE ... ALTER COLUMN TYPE ... がエラーになる動作が修正されました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)
    5. （以下のエラー発生パターンが報告されました）
db=# CREATE TABLE t4 (id int);
db=# ALTER TABLE t4 ADD EXCLUDE USING btree (id WITH =) WHERE (id IS NOT NULL);
db=# ALTER TABLE t4 ALTER COLUMN id TYPE bigint;
ERROR:  relation "t4_id_excl" already exists

    発生するエラーは以下のようにバージョンによって様々です。「ERROR: could not open relation with OID 123456」「ERROR: cache lookup failed for relation 654321」「ERROR: relation "t4_id_excl" already exists」

  5. ドメインの制約に対するコメントでCOMMENTコマンドがエラーになる動作が修正されました。 (Daniel Gustafsson, Michael Paquier) (11)(10)(9.6)(9.5)

    6. 一般ユーザで実行時に以下のような奇妙なエラーが報告されました。 

    db=> CREATE DOMAIN ddd AS text CONSTRAINT ccc CHECK (TRUE);
db=> COMMENT ON CONSTRAINT ccc ON DOMAIN ddd IS 'test';
ERROR:  type with OID 16413 does not exist
  6. ハッシュ集約のハッシュキーのリストに重複する列があるとき、不適切なメモリ上書きの可能性があり、防止されました。 (Andrew Gierth) (11)(10)

    7. 例えば、以下の形状の問い合わせで HashAggregate が生じた場合に該当する可能性があります。 

    db=# CREATE TABLE t6a (v text);
db=# CREATE TABLE t6b (v1 text, v2 text);
db=# SELECT * FROM t6b WHERE (v1, v2) IN (SELECT v, v FROM t6a);
  7. ゼロ個または複数個の引数を伴う集約関数の部分集約における、引数の誤ったNULL検査が修正されました。 (David Rowley, Kyotaro Horiguchi, Andres Freund) (11)

    8. 部分集約(Partial Aggregate)は集約をパラレル実行するときに生じるプラン要素です。パラレル実行時に単一引数でない集約関数に不正な結果が返る動作が報告されました。

  8. Merge Appendプランの誤った生成が修正されました。 (Tom Lane) (11)(10)(9.6)

    9. 以下のエラーが発生する可能性があります。 

    ERROR:  could not find pathkey item to sort

    SELECT DISTINCT ... FROM (SELECT ... UNION ALL SELECT ...) という形状の問い合わせで発生が報告されました。

  9. 重複する結合名を伴う問い合わせの誤った出力が修正されました。 (Philip Dubé) (11)(10)(9.6)(9.5)(9.4)

    10. この誤りで、このような問い合わせを含むビューのダンプ/リストア失敗が生じます。同様に psql の d+ コマンドでも誤った出力が生じます。

    以下例の「same」が重複する結合名で、このビューは正しくダンプされません。 

    CREATE TABLE t9_1 (c1 int);
CREATE TABLE t9_2 (c2 int);
CREATE TABLE t9_3 (c3 int);
CREATE TABLE t9_4 (c4 int);
CREATE VIEW v9 AS
  SELECT * FROM (
    SELECT * FROM (t9_1 CROSS JOIN t9_2) same) ss,
      (t9_3 CROSS JOIN t9_4) same;
  10. json_to_record() と json_populate_record() で、JSON文字列リテラルからJSON型出力列への変換を修正しました。 (Tom Lane) (11)(10)

    11. エスケープを要する文字を含むリテラルで誤動作が生じていました。jsonb型むけ同様の関数では正しく動作していました。 

    （エラーが発生する誤動作の例）
db=# SELECT * FROM json_to_record('{"out": "{"key": 1}"}') as x(out json);
ERROR:  invalid input syntax for type json

（正しくは以下の出力）
      out       
----------------
 "{"key": 1}"
(1 row)
  11. 正規表現で {1,1} 量指定子の誤った最適化が修正されました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)

    12. このような量指定子は何もしないものとして最適化で無きものとされていました。しかし、{1,1}? と最短マッチ指定が付いた場合には、この最適化は不適切です。誤動作は副式が取り込み括弧を含むか後方参照を含む場合のみ発生します。 

    （誤動作例: 最初の取り込み括弧が最短マッチであることが反映されていない）
db=# SELECT regexp_matches('AAbbbccc', '^(A*){1,1}?(.*)(c*)$');
 regexp_matches
----------------
 {AA,bbbccc,""}
(1 row)

（修正後の正しい応答）
  regexp_matches  
------------------
 {"",AAbbbccc,""}
(1 row)
  12. ページ分割の際にINCLUDEされた列を処理して失敗するという稀な場合に、無効な空のBtreeインデックスページを書き出す動作が回避されました。 (Peter Geoghegan) (11)

    13. この無効なページは通常のインデックス操作では動作に影響ありませんが、後の VACUUM でエラーを起こす可能性があります。インデックス再構築（REINDEX）を行って復旧することができます。

  13. 新たなプロセスの pg_stat_activity むけデータを初期化する際に失敗することがあり、回避されました。 (Tom Lane) (11)(10)(9.6)(9.5)

    14. SSL証明書から取り出した文字列をデータベースエンコーディングに変換する等の場合に失敗する可能性がありました。これはクリティカルセクション内で実行されるため、共有の pg_stat_activityデータに対するアクセス手順を妨げ、データベース全体のハングアップをひき起こしました。

  14. 既存の共有メモリセグメントが別のpostmasterから未だ使用中かどうかを検査する際の競合状態が修正されました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)

    15. 実行タイミングによっては検査をすり抜けて他のpostmasterが使用中の共有メモリを削除してしまうことがあり得ました。

  15. walreceiverのシグナルハンドラにおける安全でないコーディングが修正されました。 (Tom Lane) (11)(10)

    16. これにより、walreceiverプロセスが終了シグナル(SIGTERM)を受けたときにクラッシュまたはデッドロックするという、稀に起こりうる問題を回避します。

  16. 特定データベースに接続していないプロセス(walsender等)がパラメータ検査のためにデータベースアクセスを試みる動作が回避されました。 (Vignesh C, Andres Freund) (11)(10)(9.6)(9.5)(9.4)

    17. この誤りは「FATAL: cannot read pg_class without having selected a database」のようなエラーをもたらしました。

  17. SSL を使っていて OpenSSL のデータバッファにちょうど 256×N バイトが含まれる場合の libpq でのハングアップが回避されました。 (David Binderman) (11)(10)(9.6)(9.5)
  18. initdb でシステムタイムゾーンに対する複数の等価な名前の扱いが改善されました。 (Tom Lane, Andrew Gierth) (11)(10)(9.6)(9.5)(9.4)

    19. initdb は /etc/localtime シンボリックリンクを調べて、シンボリックリンクが存在するなら、システムタイムゾーンに対して等価な名前の中から、それを選ぶようになりました。

    これにより initdb は同一タイムゾーンが複数存在する場合にユーザーが予期するタイムゾーン名を選択します。 /etc/localtime がゾーンデータファイルへのシンボリックリンクでない場合や、タイムゾーンが TZ環境変数から決定される場合の振る舞いは変更ありません。

    これとは別に、TZ も /etc/localtime もヒントとして提供されていない時、そのタイムゾーンの他のスペルよりも UTC を優先するようになりました。これにより tzdata 2019a によってもたらされた煩わしい変更を修正します。それは UCT と UTC のゾーン名を同等にするための変更で、initdb は UCT を好むようになりましたが、ほとんど誰も望んでいません。

  19. pg_dump と pg_dumpall によって発行されたデータベースとテーブルスペースに対するGRANTコマンドの順序が修正されました。 (Nathan Bossart, Michael Paquier) (11)(10)(9.6)

    20. カスケードしている GRANT が発行されている場合、それらの相互依存性に考慮しない順序で GRANTコマンドが並んでいるために、リストアが失敗する可能性がありました。

  20. pg_dump がテーブルパーティションを再作成する際、作成コマンドにCREATE TABLE ... PARTITION OF ... ではなく、CREATE TABLE の後に ALTER TABLE ... ATTACH PARTITION をするように変更されました。 (Álvaro Herrera, David Rowley) (11)(10)

    21. これによりパーティションの列の順序が親の列から変更されている可能性があるという問題を回避します。また、親テーブルがまだリストアされていなくても、パーティションは（スタンドアロンテーブルとして）ダンプからリストア可能となりました。 ATTACH は失敗しますが、それは無視することができます。

  21. reindexdb でのエラー時に誤解を招く余計なエラー報告が修正されました。 (Julien Rouhaud) (11)(10)(9.6)(9.5)(9.4)

    22. インデックスやスキーマを指定して実行して失敗した場合に、以下のようなデータベースに対する reindexdb に失敗したというメッセージが出力されることがありました。 

    reindexdb: reindexing of database "db" failed: ....
  22. vaccumdb で並列ジョブ実行中にエラーが発生した場合、正しい終了ステータスを確実に返すようになりました。 (Julien Rouhaud) (11)(10)(9.6)(9.5)

    23. これまで、-j を付与して並列実行させている場合、エラーが起きていてもコマンドが正常終了(0)を返すことがありました。

  23. auto_explain でパラレルクエリの時に問題が発生しないように修正されました。 (Tom Lane) (11)(10)(9.6)

    24. 以前は、auto_explain で親のクエリがログに記録されていない場合であっても、パラレルワーカーが自分自身のクエリをログに記録しようとしていました。これは時々動作することもありますが紛らわしいですし、時には「ERROR: could not find key 3 in shm TOC at 0x7f45a0334000」のようなエラーを発生させる原因となっていました。

    また、サンプリングレートが 1.0 に設定されている場合ですら、必ずしもすべてのクエリーが記録されるとも限らないという、off-by-oneバグも修正されました。

  24. postgres_fdw で BEFORE ROW UPDATEトリガーによるデータ変更がある可能性を新たに考慮するようになりました。 (Shohei Mochizuki) (11)(10)(9.6)(9.5)(9.4)

    25. これまでは不必要なデータ転送を避けるために UPDATE処理で明示的に対象となったデータだけが転送対象でした。しかし外部テーブルに BEFORE ROW UPDATEトリガーが存在している場合、トリガーは対象となっていない列も変更する可能性があり、そのような場合はそれらの列の変更された値を送り損ねてしまいます。今回の変更で BEFORE ROW UPDATEトリガーが存在するときはすべての列を送信するようにします。

  25. Windows上でデータベースエンコーディングが SQL_ASCII に設定されている時にASCII 以外の文字列を記録する試みが失敗しないようになりました。 (Noah Misch) (11)(10)(9.6)(9.5)(9.4)

    26. これまでの実装では記録する文字列が必ず UTF-8 である前提となっていて、妥当なエンコードではないように見える時はエラーを投げていました。これからは変換していないバイト列を単純にログに送信します。

    該当の関数は pgwin32_message_to_UTF16() で、新しい挙動は pg_do_encoding_conversion() と整合性があります。

  26. PL/pgSQLのヘッダファイル等の変数名が C++の予約語と衝突しないように変更されました。 (George Tarasov) (11)(10)(9.6)(9.5)(9.4)

    27. これまで PL/pgSQL のヘッダファイルや Cソースファイルの変数名が（new、typeid、typemod など）C++の予約語と衝突していました。

関連記事:

  1. PostgreSQL 9.4.19 に関する技術情報
  2. PostgreSQL 9.4.18 に関する技術情報
  3. PostgreSQL 9.4.17 に関する技術情報
  4. PostgreSQL 9.4.16 に関する技術情報