一時関数の発効には長らく、pg_temp.func_name(args) という明示的な一時スキーマの指定が必要でした。これは、pg_temp.type_name(arg) と関数風の構文を使って一時データ型にキャストする場合も同様に必要です。そうでないと一時オブジェクトを使って関数呼び出しを横取りすることができて、8.2.4バージョンで防止された CVE-2007-2138 の脆弱性と同様の方法で、権限拡大を狙うことが可能でした。

一時スキーマとは一時オブジェクトのためのスキーマです。pg_temp_1 など番号を伴う名前が自動付与されますが、指定する場合には pg_temp という名前で代表させることができます。また、search_path に明示的な pg_temp の指定が無いと一時スキーマは優先して選択されます。

本修正後は、以下例の最初の型キャストは使用できず、型キャストのための処理に進む前にエラーになります（後者の 2つもエラーですが、これらは型キャスト処理が働いた結果のエラーです）。

db=# CREATE DOMAIN pg_temp.nonempty AS text CHECK (VALUE <> '');

db=# SELECT nonempty('');
ERROR:  function nonempty(unknown) does not exist
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

db=# SELECT pg_temp.nonempty('');
ERROR:  value for domain nonempty violates check constraint "nonempty_check"

db=# SELECT ''::nonempty;
ERROR:  value for domain nonempty violates check constraint "nonempty_check"

ハッシュ化された副プランは、ハッシュ要素を比較するために外側の問い合わせの元の比較演算子を使用していました。その演算子が型を跨る場合は、全てのハッシュ要素が副問い合わせの出力型になるので、これは誤りでした。PostgreSQL本体に含まれるハッシュ可能な型を跨る演算子に対して、64bitマシンでは、この誤りはほぼ無害です。しかし、32bitマシンでは、クラッシュやサーバメモリの不当なデータ露出になる可能性があります。

以下の問い合わせは = 演算子が text型と副問い合わせからの name型（外側と異なるデータ型）との間で適用され、副問い合わせ結果が「hashed SubPlan 1」として扱われるので、問い合わせの形状としては本問題に該当します。

explain (verbose)
  SELECT 'foo'::text IN (SELECT 'bar'::name UNION ALL SELECT 'bar'::name);

拡張モジュールが、より大きなリスクをもたらすハッシュ可能な型を跨る演算子を提供しているかもしれません。

これは一つ前のマイナーリリースで混入した障害です。変更された列のインデックスが適切に処理されていませんでした。

インデックスを持つ列をいくつかデータ型変更する ALTER TABLE に対して、以下のエラーになる動作が報告されました。

ERROR:  relation "《インデックス名》" already exists

特にトリガで実現されている外部キー制約で該当します。

本修正前には、トランザクションのコミット時に処理すべきトリガが削除されてしまったことで COMMIT時にエラーが生じる可能性がありました。

（例）
db=# CREATE TABLE t4_1(f1 int primary key);
db=# CREATE TABLE t4_2(f1 int REFERENCES t4_1 DEFERRABLE INITIALLY DEFERRED)
       PARTITION BY RANGE (f1);
db=# CREATE TABLE t4_2_p1 PARTITION OF t4_2 FOR VALUES FROM (0) TO (10);
db=# INSERT INTO t4_1 VALUES (1);
db=# BEGIN;
db=# INSERT INTO t4_2 VALUES (1);
db=# ALTER TABLE t4_2 DROP CONSTRAINT t4_2_f1_fkey;
（修正後はここで以下のようなエラーが生じる）
ERROR:  cannot ALTER TABLE "t4_2" because it has pending trigger events
db=# COMMIT;
（修正前はここで以下のようなエラーが生じる）
ERROR:  relation 16123 has no triggers

本修正前は「CREATE TRIGGER ... EXECUTE FUNCTION my_trigger_func('my params', 123);」などとして付与した引数が欠落してコピーされていました。

ALTER TABLE ... DROP COLUMN はパーティションキーである列の削除を拒絶します。しかしながら、間接的な削除（キー列のデータ型をカスケード削除する場合など）では、このようなチェックが働かず、キー列の削除を許していました。この結果、パーティションテーブルが壊れて、アクセスも削除もできなくなるおそれがありました。

本修正は、キー列の削除を要するカスケード削除の際にはパーティションテーブル全体を削除するという要素を pg_depend に追加します。これはパーティションテーブルが作られるときに追加されます。したがって、バージョンアップ前に作られた既存パーティションテーブルでは、キー列のみ削除されてしまうリスクが残ります。

この問題は組み込みのデータ型のパーティションキー列では発生しません。したがって、大部分のユーザには無害であると考えられます。

デフォルトパーティションでのみ一部の列を削除してあるなど、列が1対1対応でない場合に誤動作することがありました。

その後の有効なパーティションテーブルに対する操作（パーティション追加など）で、以下のようなエラーが生じる可能性がありました。

ERROR:  attribute 4 of type t7_partition_1 has been dropped

これまではインデックスを作成しようとしたり、インデックスのあるパーティションテーブルに外部テーブルをアタッチするときに、以下のようなエラーが発生していました。

ERROR: cannot create index on foreign table "t8_parted"

これからは外部テーブルのパーティションについては単にインデックスが作られない動作になります。ただし、ユニークインデックスである場合には例えば以下のようなエラーになります。

ERROR: cannot create unique index on partitioned table "t8_parted"

通常、テーブルの主キー列が GROUP BY に含まれる場合は他のグループ化列を安全に除去することができます。主キー列でグループを特定できるからです。しかし、継承テーブルを読む場合には、親子テーブル間、子テーブル間をまたがるユニーク性は保証されないため、この最適化は使えません。

以下の誤動作が報告されました。最後の SELECT は 2行が返るのが正しい動作です。実行プランで c1列がグループ化対象から外れてしまっていました。

db1=# CREATE TABLE t11  (c0 INT PRIMARY KEY, c1 INT);
db1=# CREATE TABLE t11c (c0 INT) INHERITS (t11);
db1=# INSERT INTO t11  (c0, c1) VALUES (0, 0);
db1=# INSERT INTO t11c (c0, c1) VALUES (0, 1);
db1=# SELECT c0, c1 FROM t11 GROUP BY c0, c1;
 c0 | c1
----+----
  0 |  0
(1 row)

この障害により、一部の EXISTS問い合わせからの結果行が重複し、誤った結果が返ります。

修正前も、処理が非効率にはなりますが、問い合わせ結果は正しいです。

PostgreSQLのプランナはインデックスを使って値の最大値、最小値を調べる動作をすることがあります。

プランナが列の最小値や最大値を知るために最近に作られたインデックスを使うとき、最近に無効になった実際には端点値を含まないタプルを誤って選択してしまう可能性がありました。

誤選択したタプルには NULL が入っているかもしれず、最悪の場合は、以下のエラーになります。

ERROR: found unexpected null value in index ...

本障害でよくある挙動は、誤った値が使われてプラン作成におけるデータ推測の品質が劣化することです。

遷移テーブルを使った処理で以下のエラーが出るケースが報告されました。

ERROR:  executor could not find named tuplestore "《NEW遷移テーブル》"

EvalPlanQual処理は、READ COMMITTEDトランザクション隔離モードでの行の更新で使われる内部的な仕組みです。

外部キーの全列が同じデータ型でない場合に、ALTER TABLEが外部キーの再検証が必要かどうかの判断を誤る可能性がありました。この判断の誤りは常に保守的な方向で、再検証が不要なものを必要と判断すると見られます。したがって、不要な処理による性能上のバグと言えます。

これにより、ANALYZE の際に以下のエラーが出るのを回避します。

ERROR:  tuple already updated by self

複数のトランザクションがトランザクションT1 が行ロックを解放するのを待っていて、T1 がそのロックレベルを格上げするとき、T1終了時に待っているトランザクションの間で偽性の（実際にはデッドロックではない）デッドロックが報告されました。

ここでのロックレベルの格上げとは、「SELECT ... FOR KEY SHARE」 の行ロックを取得している行に対して、次に「UPDATE ...」を行う場合などを指します。

本障害に該当した場合、デッドロック状態がデッドロックエラーにならず、問い合わせがキャンセルされるまで処理がブロックされてしまいます。

本障害が人工的な問い合わせ以外で発生するのかは明らかではありません。通常パラレルワーカがリーダプロセスで取得済みのロック以外を必要とすることは無いため、実際には問題はほぼ起きないと考えられます。

範囲データ型は、ある値以上である値より小さいという半開区間になるように境界値を標準化させます。これを誤って無限値（infinity、-infinity）に対しても同様に試みていました。無限値の場合には干渉しないようになりました。

修正前は以下のような奇妙な振る舞いが生じていました。

db1=# SELECT '[-infinity,infinity]'::daterange @> '-infinity'::date "include?";
 include?
----------
 t
(1 row)

db1=# SELECT '[-infinity,infinity]'::daterange @> 'infinity'::date "include?";
 include?
----------
 f
(1 row)

db1=# SELECT '[-infinity,infinity]'::daterange;
      daterange
----------------------
 [-infinity,infinity)
(1 row)

money型の最大値（あるいは負の最小値）に近い値で以下のように不正確な変換が生じる可能性がありました。

db=# select '-92233720368547758.07'::money, '-92233720368547758.07'::money::numeric(30,2);
           money            |       numeric
----------------------------+----------------------
 $92,233,720,368,547,758.07 | 92233720368547758.00
(1 row)

これは pg_waldump のクラッシュをひき起こしました。

10以前のバージョンで作った Btreeインデックスがあって、それを pg_upgrade でバージョンアップした後のアクセスで問題が生じました。11 でも修正されていますが、実際にアサート失敗が起きるのは 12 の betaバージョンです。

これによって結果がテーブルに直接格納された場合の問題が回避されます。これまでは以下の処理でエラーが発生していました。

db=# CREATE TYPE two_int8s AS (q1 int8, q2 int8);
db=# CREATE FUNCTION compresult(int8) RETURNS two_int8s LANGUAGE plpgsql AS
       $$ DECLARE r record; BEGIN r := ROW($1,$1); RETURN r; END $$;
db=# CREATE TABLE two_int8s_tab (f1 two_int8s);
db=# INSERT INTO two_int8s_tab VALUES (compresult(42));
db=# SELECT f1 FROM two_int8s_tab;
   f1
---------
 (42,42)
(1 row)

(再接続後に実行)
db=# SELECT f1 FROM two_int8s_tab;
ERROR:  record type has not been registered

ごくまれな場合に、Windows形式の改行コードを含むサービスファイルが誤って解析され、接続エラーになっていました。

ユーザ定義 opclass がユーザ定義範囲型のサブタイプ opclass である場合、関連するオブジェクトが誤った順序でダンプされ、リストアできないダンプが生成されていました。

opclass の依存関係を処理する潜在的なエラーはほかのケースでも発生する可能性がありますが、これは唯一知られているケースです。

NULL を Perl の undef値として扱わせて、それを jsonb に変換する場合に以下エラーが出るケースが報告されました。

ERROR:  cannot transform this Perl type to jsonb

これにより、VS 2017 と SDK v10 の組み合わせでビルドする際にSDK v8.1 が無いとビルドに失敗する問題が回避されます。

場合によっては initdbコマンドは実際のゾーン名より優先して、これらの人工的なゾーン名のいずれかを選択していました。

これらの 2 つよりも C ライブラリのタイムゾーンの動作に一致するほうが優先されるようになります。

歴史的に IANA では、この人工的なゾーンに「Local time zone must be set--see zic manual page」のような省略形を設定します。tzdbデータベースの最新バージョンでは代わりに -00 が表示されますが、一部のプラットフォームでは何らか歴史的なフレーズを表示するためにデータを変更します。

最新の省略形が使用される場合に限ってこのタイムゾーンを表示することで、非常に長い文字列が abbrev列に出力されるのが防止されました。

これによって zicコマンドに新しい -b slim オプションが追加され、インストールされたゾーンファイルのサイズを削減できます。現在は使用されていませんが、将来的には有効になる可能性があります。

認証を受けるユーザは誰でも、パスワードを意図的に作りこんだ値に変更することで、スタックのバッファオーバフローを起こすことができました。さらに 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++の予約語と衝突していました。