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

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

除外に使われる比較値が（プリペアドステートメントのパラメータで）動的に決定される場合や、複数のレンジパーティション列が除外の判断に関わる場合、あるいは、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)

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

（以下のエラー発生パターンが報告されました）
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」

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

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

例えば、以下の形状の問い合わせで 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);

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

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

ERROR:  could not find pathkey item to sort

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

この誤りで、このような問い合わせを含むビューのダンプ/リストア失敗が生じます。同様に 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;

エスケープを要する文字を含むリテラルで誤動作が生じていました。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)

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

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

（修正後の正しい応答）
  regexp_matches  
------------------
 {"",AAbbbccc,""}
(1 row)

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

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

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

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

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

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

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

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

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

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

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

reindexdb: reindexing of database "db" failed: ....

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

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

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

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

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

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

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

一部のプランナの選択性見積り処理ではプランナ統計情報(pg_statistic の 最頻値など)で見つかった値にユーザ定義演算子を適用します。そのため、実行したユーザにその列を参照する権限がなくとも、漏洩のある演算子が一部行の列データ値を露出させることができます。9.6.3、9.5.7、9.4.12、9.3.17、9.2.21 での CVE-2017-7484 セキュリティ障害の修正で同様の問題に対する対処が行われていましたが、行単位セキュリティについては対応されていませんでした。

本修正により、漏洩のある（LEAKPROOF属性が真でない）演算子は関連する行単位セキュリティ(RLS)ポリシーが無い場合に限ってプランナ統計情報に適用が許されるようになります。

この障害はクラッシュをひき起こします。また、原理的にはサーバメモリ内容を露出させる攻撃に利用できる可能性があります。なお、上記のパーティション振り分けのエラーとは以下の類です。

db=# CREATE TABLE parted_tbl (id int, v text) PARTITION BY RANGE (id);
db=# CREATE TABLE part1 PARTITION OF parted_tbl FOR VALUES FROM (1) TO (100);
db=# INSERT INTO parted_tbl VALUES (105, 'XX');
ERROR:  no partition of relation "parted_tbl" found for row
DETAIL:  Partition key of the failing row contains (id) = (105).

例えば、ALTER TABLE .. ALTER COLUMN TYPE 実行時に物理テーブルの書き換えは不要と判断したケースで発生します。ALTER TABLE を行って定義情報の破損が生じたパーティションテーブルを、次に DROP したときにバックエンドプロセスがクラッシュ終了する動作が報告されました。

以下のような発生例が報告されました。

（あるセッションで以下のように一時テーブルを作った後、）
db=# CREATE TEMP TABLE t4 (c int GENERATED BY DEFAULT AS IDENTITY)
       ON COMMIT DROP;

（別セッションで別の一時テーブルを作ろうとした際に不明なエラーが出る）
db=# CREATE TEMPORARY TABLE t4_2 (d text);
ERROR: could not open relation with OID 16345

これにより pg_upgrade を失敗させる可能性もあります。以下の予期せぬエラーが発生します。

ERROR:  incorrect attribute map

この障害は、アタッチ後に実行する当該パーティションインデックスを使う DDL で以下のような予期せぬエラーを発生させます。

ERROR:  index ... not found in partition ...

これは、READ COMMITTED 隔離レベルを使用していて、他のセッションが問い合わせの対象行を同時並行に更新していた場合にEPQ(EvalPlanQual)の再チェック処理で発生します。

パーティションテーブルに列削除が行われていた場合に INSERT 実行に対して、以下の予期せぬエラーが発生する場合がありました。

ERROR: cannot extract attribute from empty tuple slot SQL state: XX000

（権限の問題などで）fast-path処理が使えない場合という、一般的でない場合以外では、この問題は顕在化しません。fast-path、slow-path は検査処理実装の内部的な区別です。前者が使えない場合に後者が使われます。

以下のようなエラー発生が報告されました。

db=# CREATE ROLE test_role WITH LOGIN;
db=# CREATE TABLE t9_ref(a int PRIMARY KEY);
db=# GRANT REFERENCES ON t9_ref TO test_role;
db=# SET ROLE test_role;
db=> CREATE TABLE t9(a int, b int) PARTITION BY LIST (a);
db=> ALTER TABLE t9 ADD CONSTRAINT t9_b_key
        FOREIGN KEY (b) REFERENCES t9_ref(a);
ERROR:  could not open file "base/16432/49876": No such file or directory

このような場合、RETURNING句があっても問い合わせが正しい列セットを報告せず、文レベルトリガがあっても実行されませんでした。

（障害動作例: WHERE false の場合の RETURNING句の応答は列が無く不正）
db=# CREATE TABLE t10 (a int, b int);
db=# CREATE TABLE t10c () inherits (t10);
db=# INSERT INTO t10c VALUES (1,2);
db=# UPDATE t10 SET a = a + 1 WHERE false RETURNING b, a;
--
(0 rows)
UPDATE 0

db1=# UPDATE t10 SET a = a + 1 WHERE true RETURNING b, a;
 b | a
---+---
 2 | 2
(1 row)
UPDATE 1

この変更は 10.xバージョンの振る舞いに戻したことになります。

db=# CREATE TABLE t11p (a int) PARTITION BY LIST (a);
db=# CREATE TABLE t11c PARTITION OF t11p FOR VALUES IN (1);
db=# SET constraint_exclusion TO on;
db=# EXPLAIN SELECT * FROM t11c WHERE a = 2;
（修正前の結果、範囲外の値でもテーブルスキャンが発生）
                     QUERY PLAN
----------------------------------------------------
 Seq Scan on t11c (cost=0.00..41.88 rows=13 width=4)
   Filter: (a = 2)
(2 rows)

（本来期待される結果）
                QUERY PLAN
------------------------------------------
 Result  (cost=0.00..0.00 rows=0 width=4)
   One-Time Filter: false
(2 rows)

プロシージャがオープンされた明示的あるいは暗黙的なカーソル（PL/pgSQLのFORループ問い合わせなど）を持つときにコミットしようとした場合、カーソルはコミット前に完全に実行され結果を保存して以降で利用可能にします。このような処理の中でエラーが生じた場合にバックエンドプロセスのクラッシュが起こっていました。

このようなテーブルはパブリケーション用には無視されるべきでしたが、一部コードでそうなっていませんでした。

以下例のように複数行を同時に挿入した場合、ビューにデフォルト値が無い列で元テーブルのデフォルト値ではなく NULL が使われてしまいます。

（障害動作発生例: a=14 の行と a=15,16 の行で振る舞いが違う）
db=# CREATE TABLE t14 (a int, b text default 'Table default',
                       c text default 'Table default', d text, e text);
db=# CREATE VIEW v14 AS SELECT * FROM t14
db=# ALTER VIEW v14 ALTER b SET DEFAULT 'View default';
db=# ALTER VIEW v14 ALTER d SET DEFAULT 'View default';
db=# INSERT INTO v14 VALUES (14, default, default, default, default);
db=# INSERT INTO v14 VALUES (15, default, default, default, default),
                            (16, default, default, default, default);
db=# SELECT * FROM t14;
 a  |      b       |       c       |      d       | e
----+--------------+---------------+--------------+---
 14 | View default | Table default | View default |
 15 | View default |               | View default |
 16 | View default |               | View default |
(3 rows)

これによりゼロ列テーブルが作成可能であることと一貫性を持ち、テーブルをビューで置き換える際に失敗するケースを回避できます。

db=# CREATE TABLE t15 (id int primary key, v text);
db=# CREATE TABLE t15_0 ();
db=# CREATE VIEW v15 AS SELECT FROM t15;
db=# CREATE VIEW v15_0 AS SELECT * FROM t15_0;
（修正前バージョンでは上記両CREATE VIEVで以下のエラーが出ました）
ERROR:  view must have at least one column

AS の後に問い合わせにプリペアド文を実行する EXECUTE文を記述することは可能であるべきでしたが対応していませんでした。

これまで、行単位セキュリティ(RLS)ポリシーを持つテーブルがビューを通してアクセスされる場合に、セキュリティ検査がビューを呼び出したユーザで行われ、ビュー所有者ユーザで行われませんでした。後者が本来の正しい動作です。

これまでは PostgreSQL は SQL:2003 の定義に従っていて、このような場合にはデータを受け入れませんでした。しかし、ダンプ/リストアで全ての有効なXMLデータを受け入れる xmloption の設定値が無いという重大な問題が問題が生じることから、SQL:2006 の定義に変更されました。

加えて、確実にダンプ/リストアできるように pg_dump が SET xmloption = contentを出力するようになりました。

PostgreSQLのマスタプロセス(postmaster)は、たとえ postmaster.pid ファイルが削除されていても、以前の postmasterから生じた実行中プロセスが無いかを調べるようになりました。

これにより PostgreSQL二重起動によるデータ破損を予防します。

これは vacuum_cleanup_index_scale_factor 設定値に基づいてインデックスのクリーンアップが必要かどうかについて不正確な判断をひき起こします。

パラレル問い合わせ実行があるときに、実行時統計情報のトランザクション数が本来より多く計数されていました。

前回のマイナーリリースには後方互換性に問題がありました。ストリーミングレプリケーション等で更に以前のマイナーバージョンが生成したWAL を適用する場合にロック処理の問題からハングアップする動作が報告されました。

本修正で WALレコードを適用する際に、前マイナーリリースの修正があるWALレコードも、無いレコードも両方読めるように修正されました。

特に JDBCで問い合わせ結果を1行ずつ取得する場合に顕在化します。

このメモリリークはセッション内で継続します。

ファイル同期に失敗が生じたなら PANIC とする前回リリースでの変更は、失敗が想定できて本質的に操作がサポートされないことによる場合については、過度に偏執的でした。

例えば Windows Subsystem for Linux において sync_file_range がサポートされないために PANIC が起きていました。

以前は誤ってデータベース名が報告されていました。

（エラー発生例）
db=# SELECT * FROM (VALUES (1),(2)) v1(r1)
       LEFT JOIN LATERAL (
         SELECT * FROM generate_series(1, v1.r1) AS gs1
           LEFT JOIN LATERAL (
             SELECT * FROM generate_series(1, gs1) AS gs2
               LEFT JOIN generate_series(1, gs2) AS gs3 ON TRUE
           ) AS ss1 ON TRUE
           FULL JOIN generate_series(1, v1.r1) AS gs4 ON FALSE
       ) AS ss0 ON TRUE;
ERROR:  failed to build any 3-way joins

この障害により、10.x バージョンでは僅かに非効率なプランが生成されるだけですが、11.x バージョンでは「ERROR: set-valued function called in context that cannot accept a set 」エラーをひき起こす可能性があります。

元となるテーブルにビューを通してアクセスするとき、漏洩のある演算子をテーブルの統計データに適用して良いかの判断に、問い合わせを実行するユーザの権限ではなく、ビュー所有者の権限を考慮するようになりました。これにより、プランナのどのデータが可視かのルールをエグゼキュータのルールと一致させて、劣ったプランを回避します。

これまでは、並列化されている可能性のある対象リストを評価する動作が無いかもしれませんでした。この問題によりプランの劣化が発生していました。

本障害により、含められた列を持つユニークインデックスが問い合わせ結果の唯一性を保証することをプランナが認識しなくなる可能性があり、プランの劣化がもたらされました。

以下例のように STRICT を指定した SQL関数に NULL を渡しても、応答が NULL にならない動作が発生していました。

db=# CREATE TABLE t34 (c1 int);
db=# INSERT INTO t34 VALUES (1), (NULL);
db=# CREATE FUNCTION f34 (int) RETURNS int[] LANGUAGE sql AS 
     $$ SELECT array[0, $1]::bigint[]::int[] $$ STRICT;
db=# SELECT f34(c1) FROM t34;
（修正前の応答）
   f34
----------
 {0,1}
 {0,NULL}
(2 rows)

（正しい応答、2番目は NULL が返る）
  f34
-------
 {0,1}

(2 rows)

これにより「ERROR: dsa_area could not attach to segment」や「ERROR: cannot unpin a segment that is not pinned」のエラーが生じる可能性がありました。

pg_identify_object_as_address() はシステム情報を取得するSQL関数の一つです。

以前は未来のトランザクションの状態を取得し続けると、最終的に以下のようなエラーが発生していました。

=# SELECT txid_status(txid_current() + 1);
ERROR:  could not access status of transaction 32768
DETAIL:  Could not read from file "pg_xact/0000" at offset 8192: No error: 0.

サーバが OpenSSL 1.0.2 以降を使用しているときに libpq がOpenSSL 1.0.1 以前を使用していると、どの SASL機構を使用するかのネゴシエーションが失敗し、「ERROR: channel binding not supported by this build」という分かりにくいエラーメッセージが発生していました。

一致する先頭文字をもつパスワード文字列が SCRAM-SHA-256 または MD5形式に正しくハッシュ化されたものと間違われる可能性がありました。

SCRAM-SHA-256形式では先頭が SCRAM-SHA-256$ であるかのみをチェックし、フィールドはチェックしておらず、MD5 形式では先頭が md5 であるかと長さのみをチェックし、16進数の文字であるかはチェックしていませんでした。パスワードは受け入れられますが、あとで使用できなくなります。

ASCII 以外の文字を含むローカライズされた月または日の名前は、以前は予期せぬエラーまたはそのロケールで誤った出力を発生させていました。

以前は log_file_mode で指定された権限を使用していましたが、バックアップユーティリティに問題を発生させる可能性がありました。

以前は以下のような警告が発生していました。

db=# SET operator_precedence_warning TO on;
db=# SELECT -random() IS NULL;
WARNING:  operator precedence change: IS is now lower precedence than -
row 1: SELECT -random() IS NULL;
                       ^
 ?column?
----------
 f
(1 row)

=# SET random_page_cost TO 'NaN';
ERROR:  parameter "random_page_cost" requires a numeric value

アサートを無効にしたビルドでは本障害によるユーザに見える影響はありません。

コアコードでは考慮する必要はありませんが、いくつかの拡張ではその必要があります。SnapBuildInitialSnapshot() は主としてロジカルレプリケーションのために使われる内部実装関数です。

これまで認識されていなかった不具合の原因は、プロセスのデフォルトスレッドプール用のスレッドスタックの作成です。そのようなスタックが異なるメモリ領域に割り当てられるようになりました。

ディレクトリの読み取り権限がない、といったエラーが検出されないか正しく報告されず、そのかわりにディレクトリが空であるかのように静かに振る舞っていました。

ecpg プログラムでセミコロンが欠けているとき（「SET variable TO DEFAULT」でなく）「SET variable = DEFAULT」の誤変換をひき起こし、サーバに拒否されるであろう誤った構文を出力しました。さらに、複数の型名を列挙した DROP TYPE または DROP DOMAIN コマンドは、実際には最初の型名だけが処理されていました。

以前は、このような状況が原因でサーバーがクラッシュしたり、UPDATE結果が不正確になったりしていました。

これによって Africa/Casablancaゾーンで 2440年の標準時とサマータイムの誤った遷移が出力されるという zic の小さな不具合が修正されます。また、zic に新しい -r オプションが追加されます。

Etc/UCT は Etc/UTC への後方互換性のあるリンクになりました。現在は一般的にタイプミスとされる略語の UCT を生成する別のゾーンではありません。PostgreSQL は依然としてゾーンの省略形として UCT の入力を受け入れますが、それを出力しません。