この制限は信頼された拡張に対する SQLインジェクションを防止するものです。

拡張のスクリプトには @extschema@ や @extowner@ といったプレースホルダを使うことができます。これに対して、作りこまれたスキーマ名や所有者名を適用させることで、SQLインジェクションが狙えました。標準で付属している拡張には脆弱性はありません。また、攻撃者はデータベース作成権限が必要です。(CVE-2023-39417)

MERGE が UPDATE アクションを実行するとき、ターゲットテーブルに定義された UPDATE と SELECT の RLSポリシーを適用して、通常の WHERE句 を持つ UPDATE の動作と一貫性を持たせるべきです。しかしながら、そうなっておらず、MERGEではINSERT の RLSポリシーを INSERT と UPDATE のアクションに適用していました。(CVE-2023-39418)

加えて、MERGE が DO NOTHING アクションを行うとき、ターゲットテーブルのDELETE の RLSポリシーを、既存行に適用していました。こちらはセキュリティ障害ではありませんが、予期せぬエラーを引き起こす可能性がありました。

揮発性のフィルタ条件を含むサブプランに Memoize を適用すると、誤った問い合わせ結果がもたらされます。この検査が一部漏れていて、LATERAL を使う場合にこのような実行プランが発生する可能性がありました。

本障害により、返すべき NULL値の結果を返さない可能性があります。NULL を検索するかもしれない BRINインデックスは、バージョンアップ後に再構築してください。

（誤動作例: SELECT結果で 1000行が返るべきところで 0行が返っている）
db1=# CREATE TABLE t_brin (id int, v text);
db1=# CREATE INDEX ON t_brin USING brin (id);
db1=# INSERT INTO t_brin SELECT null, null FROM generate_series(1, 1000);
db1=# INSERT INTO t_brin SELECT g, g::text FROM generate_series(1001, 2000) g;
db1=# SET enable_seqscan TO false;
db1=# SELECT id FROM t_brin WHERE id IS NULL;
 id
----
(0 rows)

これまで DROP DATABASE が取消できない段階に進んだ後に中断された場合、対応する pg_database の行の削除はロールバックされてしまうため、DROP を中断したデータベースは（中身はおそらく破損しているにもかかわらず）アクセス可能な状態で残りました。

取消不能な操作を開始する前に、データベースに使用不能(invalid) の印付けをするように修正されました。この印付けをした後の何らか失敗で、データベースは部分的に残った状態になりますが、再度 DROP DATABASE をする以外のことはできなくなります。例えば接続を試みると「ERROR: cannot connect to invalid database "..."」というエラーになります。

新たなパーティションインデックスが既存インデックスと一致するけれども、一部パーティションにおいては無効なインデックスである場合に、パーティションインデックスは有効と印付けしてしまう可能性がありました。これにより、その後のパーティションテーブルに対する問い合わせで、誤動作（誤った問い合わせ結果）やアサート失敗を引き起こす可能性がありました。

アタッチするテーブルの無効なインデックスは無視されて、その代わりに新たな子インデックスが作成されるようになりました。

インデックスの pg_index エントリの更新では、有効フラグ(indisvalid)列以外の列について古いデータを使う可能性がありました。報告された症状の例は、トランザクション内でいくつかの DDL 操作をした後にパーティションのアタッチを行うと「ERROR: attempted to update invisible tuple」が出ることです。

このような場合には以前から以下のエラーが出る実装になっていましたが、検出できないケースがあり、予期せぬ振る舞いが生じていました。

ERROR:  extension "ext1" does not support SET SCHEMA
DETAIL:  obj1 is not in the extension's schema "extscm1"

ALTER TABLE ... SET ACCESS METHOD は、テーブルのアクセスメソッドを変更するときに、関連する pg_depend のエントリを更新することに失敗していました。

この障害により、組み込みでないアクセスメソッドを使っているとき、依存するオブジェクトが未だあるのにアクセスメソッドを DROP できてしまう危険性がありました。

なお、バージョンアップで本修正を適用しても、既に欠損している pg_depend のエントリが修復されることはありません。

テーブルをスキャンするときにその部分インデックスを使わない場合には読み取った行の一意性が保たれないかもしれないため、これにより誤ったプランを作ってしまう可能性がありました。結果として誤った問い合わせ結果も生じます。

不正なプランにより、結果として誤った問い合わせ結果が生じる可能性もあります。

以下の例では、リモートサーバ側で結合を行うプランとなっていますが、「CURRENT_USER = SESSION_USER」の条件が消えてしまっています。このような結合をリモートサーバ側にプッシュダウンすることは、今のところサポートされていません。このような結合対象テーブルと無関係な条件が付加されている場合には、ローカルサーバ側で結合するプランを生成するように修正されました。

（不正なプラン生成の例）
db1=# explain (verbose, costs off) 
        SELECT t1.c1, t2.c1 FROM ft1 t1
	      JOIN ft2 t2 ON (t1.c1 = t2.c1 AND CURRENT_USER = SESSION_USER)
          ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10;
                                                                              QUERY PLAN                                                                        
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit
   Output: t1.c1, t2.c1, t1.c3
   ->  Foreign Scan
         Output: t1.c1, t2.c1, t1.c3
         Relations: (public.ft1 t1) INNER JOIN (public.ft2 t2)
         Remote SQL: SELECT r1.c1, r2.c1, r1.c3 FROM (public.t1 r1 INNER JOIN public.t2 r2 ON (((r1.c1 = r2.c1)))) ORDER BY r1.c3 ASC NULLS LAST, r1.c1 ASC NULLS LAST
(6 rows)

プラン作成時にアサート失敗や奇妙なエラーを引き起こす可能性がありました。

ビットマップヒープスキャンを使っていて、GINインデックスを使っていて、さらに、最初は空の btree インデックスを調べるときに、衝突が見落とされる可能性がありました。

このような場合、不適切に衝突しているトランザクションのコミットを許すことになるため、トランザクション分離に失敗する結果を招きます。これにより、誤った問い合わせ結果や誤った更新結果が生じる可能性がありました。

EvalPlanQual検査は、READ COMMITTED分離モードのトランザクションで実行される処理です。この誤りにより、READ COMMITTED分離モードで UPDATE や DELETE動作が、同時更新と衝突しているためスキップされるべきところでも、実行されました。これにより、誤った問い合わせ結果や誤った更新結果が生じる可能性がありました。

（報告された誤動作ケース）
db1=# CREATE TABLE t12p (id int, v int);
db1=# CREATE TABLE t12c1 () INHERITS (t12p);
db1=# CREATE TABLE t12c2 () INHERITS (t12p);
db1=# INSERT INTO t12c1 VALUES (1,1);
db1=# INSERT INTO t12c2 VALUES (1,1);

（トランザクション１）
db1=# BEGIN;
BEGIN
db1=*# UPDATE t12p SET v = 2 WHERE v = 1;
UPDATE 2
              （トランザクション２）
              db1=# BEGIN;
	          BEGIN
              db1=*# DELETE FROM t12p WHERE v = 1;
			  （ここでロック待ちになる）

db1=*# COMMIT;
COMMIT
               (ロック待ちが解放されるが 1行だけ DELETEされる誤動作）
               DELETE 1        
               db1=*# SELECT * FROM t12p;
                 id |  v
                ----+-----
                  1 |  2
               (1 row)

               db1=*# COMMIT;
               COMMIT

そのようなパラメータの値が変更された後で結合を再スキャンするとき、ハッシュテーブルを再構築しなければなりませんが、それをしていませんでした。その結果、結合の出力行が失われて誤った問い合わせ結果が生じることがありました。

(バージョン15.3 での障害動作例)
db1=# CREATE TABLE t13a AS SELECT generate_series(1, 10)::int AS c1;
db1=# CREATE TABLE t13b AS SELECT c1 AS c2 FROM t13a;
db1=# CREATE TABLE t13c AS SELECT c1 AS c3 FROM t13a;
db1=# SET enable_hashjoin TO off;
db1=# SELECT ta.c1, s.* from t13a ta, LATERAL (
        SELECT tb.c2, tc.c3 from t13b tb
          JOIN t13c tc ON tb.c2 = tc.c3 + ta.c1 ORDER BY 1,2) s;
　⇒ 45行の結果が返る（Hash Join 以外の方式で、正しい結果）

db1=# SET enable_hashjoin TO on;
db1=# SET enable_mergejoin TO off;
db1=# SELECT ta.c1, s.* from t13a ta, LATERAL (
        SELECT tb.c2, tc.c3 from t13b tb
          JOIN t13c tc ON tb.c2 = tc.c3 + ta.c1 ORDER BY 1,2) s;
　⇒ 9行の結果が返る（Hash Join が使われて、誤った結果）

複合型列の値全体が TOAST外部格納を必要とするほど大きい場合、内部的なキャッシュ処理のタイミングによってはエラー（「ERROR: unsupported byval length: ...」）やサーバプロセスのクラッシュが発生しました。

（修正前バージョンの動作、修正後は 2つ目の SELECT も成功する）
db1=# SELECT jsonb_path_query('"2023-08-10 12:34:56+9"', '$.datetime()');
      jsonb_path_query
-----------------------------
 "2023-08-10T12:34:56+09:00"
(1 row)

db1=# SELECT jsonb_path_query('"2023-08-10 12:34:56.789+9"', '$.datetime()');
ERROR:  datetime format is not recognized: "2023-08-10 12:34:56.789+9"

修正後は max_stack_depth 設定に基づいて、スタックの上限超過を報告する ERROR で問い合わせが終了するようになります。

これまでは 256バイトが上限で、場合によっては長さが不足することがありました。そのような場合、「LOG: authentication file token too long, skipping: ...」が出て、設定ファイルの読み込みに失敗します。LDAP認証で長いオプション設定値を与えるときに失敗するケースが報告されました。

誤って一部のエントリが読み飛ばされて、見逃されることがありました。

JIT が使われている場合に、C++ の「new」で out of memory になるとき、想定された C++ の例外に進むべきところ、PostgreSQL の FATAL エラーになっていました。

セグメントは新しいフリースペースの大きさに対して適切な bin (集計区間) に移動されて、後続の検索で見つかるようになりました。この問題により、解放されたメモリが十分あるはずであるのに、動的共有メモリの割り当てに失敗することが報告されました。

無効な隣接ページリンクを検出すると、問題をログ出力しますが VACUUM処理は継続するようになります。これまでは ERROR を出して中断していました。REINDEX をしなければ壊れたインデックスは修復されませんが、そうするまで VACUUM を完了できないことは、より悪い問題を引き起こすリスクになります。

このロックはセッション終了や何らか他のエラーに遭遇した時には解放されますが、ロック解放に失敗することで後にデッドロックを引き起こす可能性がありました。

いくつかの既にディスクにフラッシュされた 2相トランザクション状態データを伴うチェックポイント途中でのクラッシュの後、クラッシュリカバリがプリペアドトランザクションを 2回リプレイしようとして、startup プロセスで「FATAL: lock is already held」などの致命的なエラーが発生する可能性がありました。

これを行わないと、オペレーティングシステムのクラッシュによって空のファイルが失われた場合、その後のテーブル操作が「could not open file」エラーで失敗する可能性がありました。

UNLOGGEDインデックスのメインデータフォークは WAL に記録されませんが、クラッシュ後にインデックスをリストアするための一貫した状態を確保するために、その初期フォークは WAL に記録する必要があります。初期フォークが空の場合に WAL書き出しが行われていなかったため、修正されました。これは標準的インデックスアクセスメソッド(AM) では生じないケースですが、一部の拡張ではおそらく該当します。

pg_waldump と walsender からの不正確な苦情がログに記録されるのを避けるために、この場合を単純な WAL の終了として扱います。WALレコードに問題がない場合でも、pg_waldump 実行時に下記のエラーメッセージが出力されていました。

pg_waldump: error: error in WAL record at 0/1FFFF98: missing
                   contrecord at 0/1FFFFE0

クエリが「like_regex」の結果に「.type()」演算子を適用した場合にアサート失敗していました。非アサートビルドではバグはありません。

（アサートビルドでバックエンドプロセスが終了する SQL文の例）
SELECT jsonb_path_query('["string", "string"]',
                        '($[0] like_regex ".{7}").type()');

アルファベット文字を含まない入力文字列を使用すると、予測不能な出力が発生しました。

場合によっては、文字が誤って空白文字として認識されて捨てられてしまうことがありました。

Mac OS X の en_US.UTF-8 ロケールは isspace(0x85) をバグで真と返すため、UTF-8 では \u0105 が 0xc4 0x85 とエンコードされ、0x85 が空白文字と解釈されていました。

以前は、このような場合に NOTICE メッセージで報告しますが、そのまま続行して無効なインデックスエントリを作成していました。これはインデックスの読み取り時にクラッシュを引き起こす危険があります。「ERROR: input array is too big (.. maximum allowed, .. current), ...」というエラーメッセージを出して、データ更新するコマンドを中断するようになりました。

（これまで報告されていた NOTICEメッセージ例）
NOTICE:  input array is too big (199 maximum allowed, 3001 current), use gist__intbig_ops opclass instead

インデックスが INCLUDE指定によりインデックスキー以外の列を含んでいた場合、gist_page_items() はインデックスのリーフページで情報を表示できなかったり、非リーフページで無条件にクラッシュしていました。

\watch 以外のコマンドでの PSQL_PAGER と同じ扱いになります。

GROUP BY や ON CONFLICT句を使っている場合に該当する可能性がありました。そのような関数は一意インデックスの後にダンプする必要がありますが、そうなっておらず、「warning: could not resolve dependency loop」という警告が出力されました。

詳細情報は infoレベルで出力されていましたが、-v (--verbose ) 指定無しのデフォルトのログレベルでは出力されないため、warningレベルで出力するようになりました。

ここでの空のパイプラインとは pgbenchスクリプトで \startpipeline の直後に\endpipeline を記述した場合を指します。

場合によっては値が古い可能性がありました。リレーションキャッシュのコピーに依存するコードは本体にないため、PostgreSQL に限って言えば潜在的なバグに過ぎません。ただし、これに起因してバグが発生する拡張が存在する可能性があります。

必要な二相トランザクションが最新の (部分的な) ログセグメントに記録されている場合、「ERROR: requested WAL segment .. has already been removed」という誤ったメッセージが出力され、昇格に失敗していました。

チェックポイントが不必要に遅延したり、アサート有効ビルドでアサート失敗したりする可能性がありました。

CREATE SCHEMA は 1つの文の中でスキーマ内要素も作成することができます。CREATE SCHEMA の中では、安全な search_path に変更される場合でも、新たに作るスキーマと元々有効であったスキーマが有効な状態で動作していました。これを利用して、スキーマを作れる権限を持つユーザは SECURITY DEFINER の関数や拡張のスクリプトの権限を奪取することができました。(CVE-2023-2454)

集合を返す SQL言語関数が、行単位セキュリティ(RLS)ポリシーを持つテーブルを参照していて、呼び出し元の問い合わせにインライン化できる場合に、その RLSポリシーは異なるロールでキャッシュされたプランの再使用を伴う一部の場合に正しく働きませんでした。

これにより、ユーザが本来見ることのできない行を参照したり更新したりすることができてしまいました。(CVE-2023-2455)

不適切なバッファ処理が後のテンプレートの pg_classカタログの修正を喪失するリスクをもたらしていました。CREATE DATABASE 直後にテンプレートデータベース上で CREATE TABLE などのDDL を実行して、チェックポイントを行うと、DDL結果が失われたり、サービスのクラッシュ終了が発生することがありました。

SQL標準では「CREATE SCHEMA AUTHORIZATION role_name」と書くことができて、新たなスキーマ名は role_name になります。しかしながら、一部のコードパスはスキーマ名が指定されている想定になっていて、障害を引き起こしました。

（クラッシュ発生例）
db=# CREATE ROLE role1;
db=# CREATE SCHEMA scm1;
db=# CREATE SCHEMA AUTHORIZATION role1 CREATE TABLE scm1.t1 (id int);
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

プラン作成時に「ERROR: variable not found in ...」や「ERROR: PlaceHolderVar found where not expected」などのエラーが出て、失敗することがありました。

MERGE ではコマンドタグで報告する行数として、NULL を返す BEFORE ROWトリガにより実際には変更されない行数も数えていました。これは通常の UPDATE や DELETE の動作と整合しませんので、修正されました。また、MERGE が行をパーティション間で移動するときに、行を重複して数えないように修正されました。

（誤動作例）
db=# CREATE TABLE t7 (id int PRIMARY KEY, v text);
db=# INSERT INTO t7 VALUES (1, 'A');
db=# CREATE FUNCTION f_trg7() RETURNS TRIGGER LANGUAGE plpgsql AS
       $$ BEGIN RETURN NULL; END; $$;
db=# CREATE TRIGGER trg7 BEFORE UPDATE ON t7 FOR EACH ROW
        EXECUTE FUNCTION f_trg7();

（いずれも実際には 0件更新だが UPDATEでは 0、MERGEでは 1 になっていた）
db=# UPDATE t7 SET v = 'X' WHERE id = 1;
UPDATE 0

db=# MERGE INTO t7 t USING (VALUES (1, 'Y')) s (id, v) ON t.id = s.id
       WHEN MATCHED THEN UPDATE SET v = s.v
	   WHEN NOT MATCHED THEN INSERT VALUES (s.id, s.v);
MERGE 1

MERGE により更新または削除される行が同時実行トランザクションで更新されるとき、一部の場合に不適切な振る舞いをしていました。MERGE の実行で、クラッシュや誤ったマージ動作、あるいは、何も行われない、という振る舞いが生じる可能性がありました。

MERGEコマンドを追加したときに見落とされていました。新形式の SQL関数で MERGE を使うときに必要で、ダンプや psql の \sf+ がエラーになりました。

（エラー発生例）
db=# CREATE TABLE t9_src (id int primary key, dat text);
db=# CREATE TABLE t9_tgt (id int primary key, dat text);
db=# CREATE FUNCTION f9() RETURNS void LANGUAGE SQL
     BEGIN ATOMIC
     MERGE INTO t9_tgt USING t9_src s on s.id = t9_tgt.id
       WHEN MATCHED THEN UPDATE SET dat = s.dat
       WHEN NOT MATCHED THEN INSERT VALUES (s.id, s.dat);
     END;
db=# \q
$ pg_dump -s db
pg_dump: error: query failed: ERROR:  unrecognized query command type: 5
pg_dump: detail: Query was: EXECUTE dumpFunc('33892')

RE そのような場合にパーティション上の複製されたトリガを名前から探していたため、ALTER TABLE ... ENABLE/DISABLE TRIGGER がエラーになっていました。OID を使う実装に修正されました。

（エラー発生例）
db=# CREATE TABLE t10fk (id int PRIMARY KEY);
db=# CREATE TABLE t10 (id int PRIMARY KEY,
       fk_id int NOT NULL REFERENCES t10fk (id)) PARTITION BY RANGE (id);
db=# CREATE TABLE t10p1 PARTITION OF t10 FOR VALUES FROM (1) TO (100);
db=# ALTER TABLE t10 DISABLE TRIGGER ALL;
ERROR:  trigger "RI_ConstraintTrigger_c_33906" for table "t10p1" does not exist

ALTER TYPE はテーブル列で使われている複合型に対するバイナリ互換性の無い変更を、今のところ許していません。これまでインデックスで使われている場合について見落とされており、本修正で禁止されました。

システム列として行ごと OID が廃止されたことにより、システム列に対する外部キー制約の用途は無くなったと考えられます。また、現状いくつかのコードはもはや対応していません。

ドキュメントには COPY TO は継承子テーブルの行をコピーしないと書かれています。しかしながら、RLS が有効な場合に誤って子テーブルの行がコピーされていました。

場合によってはクラッシュを引き起こす可能性がありました。

translate('54321', '12345', 'abcd') など、文字を削除させる動作をさせた場合に、範囲外バイトの読み込みが生じて、可能性は低いですがクラッシュを引き起こすおそれがありました。

これまでデータベースのデフォルト照合順序に ICU を使っている場合に混乱がありました。

（クラッシュ発生例）
db=# SET IntervalStyle TO sql_standard;
db=# SELECT ''::interval;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

interval型に対する「P0.1e10D」のような入力は ISO-8601 で公式には認可されていませんが、PostgreSQLではバージョン 15.0 まで長らく許容していました。15.0 で一度禁止されましたが、本バージョンから許容するようになりました。

JSON値の中の文字列リテラルで構文エラーが検出されたほとんど場合に、エラーカーソルを適切に設定することに失敗していました。これは、少なくとも（違う箇所を示す）役に立たないエラーメッセージをもたらし、14.x、15.x では場合によってはクラッシュを引き起こすことがありました。

（15.x でクラッシュを引き起こす例）
db=# SELECT E'\n"\\u00000"'::jsonb;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

そのような vacuum_defer_cleanup_age が設定されているとき、PostgreSQL 14.x、15.x では vacuum が誤って未だ有効な行バージョンを除去してしまう可能性がありました。PostgreSQL 13.x、12.x では GiST インデックスにのみ影響があり、インデックスページの早すぎる再利用が生じる可能性がありました。

結果として以下のような予期せぬエラーがあらわれることが報告されています。

ERROR:  MultiXactId ... has not been created yet -- apparent wraparound
ERROR:  could not open file "base/12345/16789" (target block 999): ...
ERROR:  attempted to lock invisible tuple
ERROR:  could not access status of transaction 3456789

集約関数は入れ子にできないため、「ERROR: aggregate function calls cannot be nested」を出すのが正しい動作です。この見落としにより、パース時点で拒絶されるべき無効な問い合わせで、エグゼキュータでクラッシュやアサート失敗を引き起こす可能性がありました。

（クラッシュ動作例）
db=# WITH cte22 (col1) AS (SELECT 1)
     SELECT avg((
         SELECT avg(a1.col1 ORDER BY (SELECT avg(a2.col2) FROM cte22))
       FROM cte22 a1)) FROM cte22 AS a2(col2);
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

イベントトリガが壊れたパースツリーを取得する場合に問題が起きる可能性がありました。なお、SEQUENCE NAME はドキュメントに記載がありませんが、以下のように使用できます。

CREATE TABLE t23 (id int GENERATED ALWAYS AS IDENTITY (SEQUENCE NAME seq23));

この誤りにより、実行時に「ERROR: subplan "..." was not initialized」というエラーが生じる可能性がありました。Initプランはプランツリーやサブプランツリーの開始点です。

統計の種別に dependencies を含む拡張統計を使用した問い合わせの実行時に予期せぬエラー「ERROR: PlaceHolderVar found where not expected」が発生することがありました。

このような形状の問い合わせでは、アサート失敗や、誤った問い合わせ結果、その他の異常が生じるが起きる可能性がありました。

（予期せぬエラーが出るSQL例）
db=# SELECT * FROM (
       SELECT empno, salary, count((SELECT 1)) OVER (ORDER BY empno DESC) c
         FROM t26) emp WHERE c = 1;
ERROR:  WindowFunc not found in subplan target lists

この最適化では集約の引数式が繰り返し可能な結果を持つ必要があり、副問い合わせでは実現できないと考えられます。アサート失敗が報告されました。

配列に対する必要サイズのオーバーフローを正しく検知できるように修正され、不正メモリアクセスによるクラッシュが回避されました。また、生成される配列の末尾のパディングをゼロ埋めするようになり、後の配列利用で奇妙な動作が生じる可能性が回避されました。

制約の無いドメインで発生します。

（障害発生例）
db=# CREATE TYPE typ1 AS (c1 int, c2 int);
db=# CREATE DOMAIN dom1 AS typ1;
db=# CREATE TABLE t29 (a dom1[]);
db=# INSERT INTO t29 VALUES ('{"(10,20)","(30,40)"}');
db=# UPDATE t29 SET a[1].c1 = -1;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

「boolcol IS NOT TURE」のような条件での除去が正しく働かず、boolcol が NULL である行を返さない、誤った問い合わせ結果が生じる可能性がありました。この他に「(NOT boolcol)」でのパーティション化も誤って処理されていました。

パーティション除去とは enable_partition_pruning = on で有効となる、プラン作成でのパーティションテーブルに対する最適化です。

parallel_leader_participation = off （デフォルトは on）の場合に、タイミングによってはクラッシュを起こす可能性がありました。

READ COMMITTED 隔離レベルでは、問い合わせが最初に見つけたものよりも新しい行バージョンに、行更新の影響を再適用する必要があるかもしれません。その場合、同時の更新で変化した列に依存する GENERATED列を再計算する必要がありました。

EvalPlanQual は READ COMMITTED 隔離レベルの問い合わせで実行される内部処理です。本障害により、被参照列だけ更新されて、それに連動して計算される GENERATED列は元の値まま、という状態で行が読み取られる動作が報告されました。

警告ログメッセージ「WARNING: buffer refcount leak: ...」が発生しました。

以前の修正の誤りのために 14.x、15.x ではミリ秒以下の値が捨てられて処理されていました。

autovacuum がリレーション毎 vacuum_cost_delay設定付のテーブルを処理するときにはいつでも、遅延バランスは無効と考えられていましたが、設定値が 0 の場合にも誤って有効と判断されていました。

更新可能ビューの元となるビューを CREATE OR REPLACE VIEW で列が増えるように作成しなおした場合に、その後の更新可能ビューへの読み書きで、予期せぬ警告（「WARNING: problem in alloc set MessageContext: req size > alloc size ...」）や、トリガの奇妙な動作、クラッシュが生じることがありました。

パーティションテーブルに対して、「INSERT ... ON CONFLICT DO UPDATE SET (c1, ...) = (SELECT ...)」という構文を使用するとき、いずれかの子テーブルが親テーブルと同形でない場合（例えば列の物理順序が異なるなど）、クラッシュや誤ったデータ更新を引き起こす可能性がありました。一般的にはエグゼキュータの整合性チェックでエラーになるだけで済みます。

MULTIEXPR_SUBLINKサブプランは、実行プランツリーにおいて、複数の対象リスト要素を持つサブプランを意味します。

このような場合、一般的には「ERROR: unrecognized node type: ...」エラーか、アサート失敗が生じます。

（エラー発生例）
db=# CREATE TABLE t39 (a int, b int DEFAULT -1);
db=# CREATE VIEW v39 AS SELECT * FROM t39;
db=# CREATE RULE r39 AS ON INSERT TO v39 DO ALSO INSERT INTO t39 SELECT 1;
db=# INSERT INTO v39 VALUES (0, DEFAULT), (1, DEFAULT);
ERROR:  unrecognized node type: 148

このような参照は実際にはラテラル参照ですが、明示的に LATERAL と指定していない場合、クラッシュが生じる可能性がありました。

以下のような処理でアサート失敗が報告されました。

db=# CREATE TABLE t40 (a int, b int DEFAULT -1);
db=# CREATE VIEW v40 AS SELECT * FROM t40;
db=# CREATE RULE r40i AS ON INSERT TO v40 DO ALSO
       INSERT INTO t40 SELECT * FROM (SELECT a FROM t40 WHERE NEW.a = t40.a) tt;
db=# INSERT INTO v40 VALUES (1), (2);

ダンプした結果、もとのコードと異なる内容が出力されてリストア不能になる動作が報告されました。

（障害を起こす関数例）
db=# CREATE TABLE t41_1 (c1 int);
db=# CREATE TABLE t41_2 (c1 int);
db=# CREATE FUNCTION f41 (c1 int) RETURNS void LANGUAGE SQL
       BEGIN ATOMIC
       WITH delete_t41 AS ( DELETE FROM t41_1 WHERE c1 = $1 )
        INSERT INTO t41_1 (c1) SELECT $1 FROM t41_2;
       END;

既に失敗したものと印付けされているトランザクションが、SERIALIZABLE で READ ONLY のトランザクションに対する安全なスナップショットの最適化について混乱させていました。一部の場合に最適化が不必要に省略されていました。また、別のある場合にはアサート失敗が起きていました（アサート無しのビルドでは何ら問題ありません）。

単一セッション内でプラグインの開始と停止を繰り返すと、「ERROR: out of relcache_callback_list slots」が生じました。

この変更は一部の予期せぬエラーが発生していた現象を修正します。

現行コードは範囲にマッチするか判断するときに最後のスキャンキーだけを考慮していました。そのため、たいていインデックスを必要とするより多くスキャンしていました。

（障害動作例）
db=# CREATE TABLE t45 (a int, b int); 
db=# INSERT INTO t45 SELECT g, g FROM generate_series(1, 1000000) g;
db=# CREATE INDEX ON t45 USING brin (a,  b);
db=# SELECT * FROM t45 WHERE a = 12345 AND b > 1; -- 遅く動作する
db=# SELECT * FROM t45 WHERE a > 1 AND b = 12345; -- 適切に高速動作する

この誤りはアサート失敗を引き起こしますが、実運用むけビルドではほぼ無害です。

取得される値は重要では無いため、この誤りは実運用ビルドにおいて通常は無害と考えられます。原理的にはサーバクラッシュを引き起こす可能性があります。

REPLICA IDENTITY FULL オプションのロジカルレプリケーションは、テーブルにこのような列が含まれていると、正しく行の特定ができず、変更がサブスクリプション側に反映されない挙動が発生しました。

ドキュメントでは CommitTsBuffer という名前でしたが、CommitTSBuffer と実装されていました。関連の待機イベント名と一貫するように、ドキュメントの通りに修正されました。

この待機タイプは 14.0 むけのコードリファクタリングの際に誤って削除されてしまっていました。

結果として wal_keep_size設定に正確には従わない可能性ありました。

スタンバイモードでは実際のところリカバリ進捗をしませんが、その場合でも追跡処理が行われていました。

この機能には OpenSSL 1.1.1 以降でのビルドが必要です。この機能追加はサーバ・クライアントの両方に影響します。

PostgreSQLマスタプロセス(postmaster)が子プロセスが消えたことを観測する前に、OS がその子プロセスの PID を再利用する可能性がありました。これにより、同じ PID で複数の子プロセスが記録されることがあり、混乱を招きました。

本障害が原因と思われるアサート失敗が報告されました。

PostgreSQL のコードでは問題に該当する使い方はありませんでしたが、拡張モジュールで問題が生じるかもしれません。

大きい（8kBを越える）pallocチャンクのサイズが減るという一般的でない場合に、Valgrind検知を有効にしたビルドではチャックからのメモリ解放の定義された状態の印付けを誤っていて、Valgrindのテストで誤った結果が生じる可能性がありました。

非ASCII文字が後に続くバックスラッシュで、有効なロケールによってはアサート失敗が生じる可能性がありました。そのロケールの言語で数字を意味する非ASCII文字で問題が報告されました。

リリースされたバージョンでこのケースに到達可能かどうかは完全には明らかではありませんが、到達した場合はアサート失敗が発生する可能性があります。

PL/perl は、データが値の長方形配列を成しておらずサブリストのネストが揃っていないときに、誤動作することがありました。このような場合、クラッシュやゴミ出力（誤った問い合わせ結果）が発生する可能性がありました。これからはエラーを出すようになります。

PL/Python は、空のサブリストを処理するときや、データが値の長方形配列を成しておらずサブリストのネストが揃っていないとき、誤動作することがありました。前者は出力配列が空になり、後者はエラーが発生します。ただし、一部のケースではクラッシュしたり、予期せぬ出力（誤った問い合わせ結果）が発生していました。

稀な障害例としては、PG_TRY 例外スタックをクリーンアップせずに戻ることがあり、次のスタックレベルが巻き戻される前に別のエラーが発生した場合にクラッシュする危険性がありました。

gssencmode が require に設定されていると、GSS の初期化に失敗した後でも、接続は dead とマークされませんでした。 TLS暗号化の同等のケースで以前から行われてきたように、直ちにエラーを返すように変更されました。

varcharsize をゼロに設定して ecpg_get_data() を呼び出すと、直前のフィールドの最後のバイトに終端ゼロ文字が書き込まれ、そのフィールドのデータが切り捨てられることがありました。

列挙値のハッシュコードは列挙値に割り当てられた OID に依存するため、通常、ダンプとリストアの後は異なります。つまり、多くの場合、行は元のパーティションとは異なるパーティションに入る必要があります。ユーザは --load-via-partition-root オプションを指定することでこの問題を回避できますが、それが無ければ成功する可能性はほとんど無いため、pg_dump がこのようなテーブルで自動的にオプション適用するように変更されました。

また、--load-via-partition-root モードが使用されている場合、リストア前にターゲットテーブルを TRUNCATE を試行しないよう pg_restore が修正されました。これにより、デッドロックやデータの喪失の危険性が回避されます。

このバグにより、pg_dump がパイプに書き込む時、または pg_restore がパイプから読み込む時に誤動作が発生していました。ファイルに対して成功していた同じ処理がパイプ経由だと予期せぬエラーが出る動作が報告されました。

これにより、pgbench スクリプトがパイプライン内でSERIALIZABLEトランザクションを開始しようとした時の以下エラーの発生を回避できます。

ERROR:  SET TRANSACTION ISOLATION LEVEL must be called before any query

これまでそのような異常を見逃していました。

破損した場合、最初の xidエポックより前にあるように見える周回した 32ビットxid が表示されることがありました。このような値を 64ビット形式に昇格させると、はるか未来の値が生成され、結果として誤った報告が作成されることになります。このような場合には FirstNormalFullTransactionId を返すことで、合理的に正常に動作するようになりました。

これはエラーを出すべきですが、Python 3 ではチェックが誤動作するようにいくつかの API が変更されたため、クラッシュを起こしていました。

それ以外の値を指定すると、インデックスコンテンツへのアクセスが不整合になります。インテル互換のハードウェアでは無害ですが、他のアーキテクチャではクラッシュを引き起こす可能性があります。

クラッシュする動作が報告されました。

$foo のような正規表現は定義として正当ですが、この表現を満たす文字列は存在しません。正規表現コンパイラはそれを認識し、空の「非決定性オートマトン(NFA)」グラフを生成します。このようなグラフを pg_trgm の GIN または GiST インデックス修飾に最適化しようとすると、作業配列の末尾からアクセスすることになり、クラッシュが発生する可能性がありました。

エスケープを展開するコードは、例えば外部テーブルの自動ANALYZE の中など、バックグラウンドプロセスで実行されるとクラッシュする可能性がありました。

これまで大容量メモリを使う動作をすることがありました。

以前は、 make install-strip で -x オプションが使用されていました。本変更により、llvm-strip の誤動作が回避され、出力もわずかに小さくなります。

SGMLドキュメントを構築するには、現在では DocBook の DTDファイルをローカルにインストールすることが必須となっています。以前は xsltproc が sourceforge.net からこれらのファイルを実行中にダウンロードできましたが、sourceforge.net は現在 HTTPS アクセスのみを許可しており、これをサポートする xsltproc の一般的なバージョンはありません。これに対応して、そのようなことが可能または有用であることを示唆するドキュメント箇所が削除され、代わりに xsltproc の --nonet オプションがMakefile に追加されました。

ビルドディレクトリの tmp_check の下に置くように変更されました。以前のコーディングでは、PGXSビルドは、必ずしも書き込み可能でないインストールディレクトリに配置しようとしていました。

モスクワ時間に従っている場合、Europe/Kirov および Europe/Volgograd は、モスクワ時間に従う他のタイムゾーンとの整合性を保つため、数字による略語ではなく MSK/MSD という略語を使用するようになりました。また、America/Yellowknife は America/Edmonton と区別されなくなり、この地域の 1948年以前のタイムスタンプの一部に影響します。

ALTER TABLE ... ENABLE/DISABLE TRIGGER USER はクローントリガをシステムトリガと誤解してスキップしていました。ENABLE/DISABLE TRIGGER の他の形式ではそれらを処理しますが、それらはスーパーユーザチェックを不適切に実施した後でのみ行っていました。

テーブルにそのような列が含まれている場合、REPLICA IDENTITY FULL オプションを使用したレプリケーションは失敗していました。