これまで TCP接続にデータを挿入できる中間者は、暗号化で保護されているはずのデータベースセッションの冒頭に平文データを投入可能でした。サーバが認証データを要求してこない場合（例えば SSL証明書認証のみを使っている場合）に限られますが、これを悪用して偽の SQLコマンドをサーバに送ることができました。(CVE-2021-23214)

これまで TCP接続にデータを挿入できる中間者は、暗号化で保護されているはずのデータベースセッションの冒頭に平文データを投入可能でした。libpq の問い合わせ応答以外の細かい振る舞いのために実現は容易ではありませんが、これを悪用してクライアントの最初の問い合わせに偽の応答を挿入することがおそらく可能でした。別の攻撃は、セッションの初期に送られたクライアントのパスワードやその他の機微データを抜き出すことです。これは前項のサーバ側脆弱性と組み合わせて可能となります。(CVE-2021-23222)

ダウンするプライマリが不完全な WALレコードの残りを書き込み完了できなかった場合、以前のクラッシュリカバリロジックでは、それをバックアップして、不完全な WALレコードの最初から WAL を上書きしました。スタンバイサーバは既にその WALセグメントのコピーを持っているかもしれないので、これは問題がありました。不整合な次セグメントに遭遇して、手動の介入なしにはリカバリできないことになりました。

本障害により、更新処理を実行中のプライマリのクラッシュ後にスタンバイがレプリケーション継続できなくなる可能性があり、対処策はスタンバイで WALファイルを手動削除して再起動することでした。

クラッシュ後の再起動時に WALセグメント境界を越えたバックアップをしないように修正されました。その代わりに、次の WALセグメントの始めに新しいタイプ（OVERWRITE_CONTRECORD）の WALレコードを書いて、不完全な WALレコードは無視しなければならないことを知らせるようになりました。

この修正を適用する場合、新しい WALレコードタイプが生じるようになるため、プライマリより先にスタンバイサーバをアップデートするのが良いです。

テーブルが min_parallel_index_scan_size を上回る 2つ以上のインデックスを持つ場合に、並列VACUUM が min_parallel_index_scan_size を下回るインデックスを処理していませんでした。この結果、これらのインデックスは VACUUM で除去済みのヒープ上のエントリに対する参照を持つことになって、破損した状態となる可能性があります。

この問題は並列VACUUM を行わない autovacuum には影響しません。発生条件に該当する、サイズの大小が異なる複数のインデックスを持っていて手動VACUUM を行ったことがあるテーブルについて、REINDEX を行うことが推奨されます。

準備されたトランザクションから直近に挿入された行が、新たなインデックスから無視されるかもしれませんでした。その結果、インデックスに依存する問い合わせが、その行を取りこぼすおそれがありました。

この問題に対する以前の修正は、CREATE INDEX CONCURRENTLY が検査したときに進行中の PREPARE TRANSACTIONコマンドを考慮できていませんでした。max_prepared_transactions > 0 の準備されたトランザクション（二相コミット）が有効なサーバでは、CONCURRENTLY指定で作成されたインデックスを全て REINDEXすることが推奨されます。

これにより破損したインデックスが生じる可能性があります。実際には稀にしか発生しないとみられますが、この誤りは潜在的に CONCURRENTLY指定を付けたあらゆるインデックス構築または再構築に影響する可能性があります。同時作成したインデックスの全てを REINDEXすることが推奨されます。

REINDEX CONCURRENTLY 実行後にデフォルトパラメータになってしまう現象が発生していました。

データベースの複製は、テンプレートデータベースから新たなデータベースを作成するとき行われます。本誤動作の結果 pg_shdepend の内容が不正になります。原理的には本障害でオブジェクトを所有しているロールが削除可能になってしまう可能性がありますが、本障害の実際の影響は限定的と考えられます。

本障害により、アタッチ/デタッチの後に既存のセッションからそのパーティションに対する直接の挿入/更新を行ったときに、アタッチ/デタッチ操作がリレーションキャッシュに反映されていないことによる、不適切な制約の適用等の誤動作を起こす可能性がありました。

CREATE TYPE がパースツリーの要素を誤って解放していて、続くイベントトリガや CREATE TYPE コマンドがプランキャッシュに格納されて後に再使用される場合に、（クラッシュや予期せぬエラー等の）問題が起きる可能性がありました。

「UPDATE tab SET fld[1].subfld = val」のようなコマンドが、配列要素が複合型ではなく複合型のドメインである場合に失敗して、クラッシュや誤った更新結果を引き起こしました。

（障害発生例／クラッシュが生じる）
db=# CREATE TYPE typ11 AS (subfld1 int, subfld2 int);
db=# CREATE DOMAIN dom11 AS typ11 NOT NULL;
db=# CREATE TABLE tbl11 (id int, fld dom11[]);
db=# INSERT INTO tbl11 VALUES (1, '{"(1,2)","(3,4)"}'::dom11[]);
db=# UPDATE tbl11 SET fld[1].subfld1 = 1;
server closed the connection unexpectedly

FETCH FIRST WITH TIES は同順位でない行を見つけるまで停止しないため、返すべき行数に加えてもう 1行を取り出す必要があります。また、現在の実装では FOR UPDATE が使われた場合は返さない行についてもロックを取得します。その結果、SKIP LOCKED オプションが指定された場合に望ましくない振る舞いが生じました。当面の対処として、この組み合わせが禁止されました。

以下の動作例では id=3 の行が応答に登場しない結果となります。

（望ましくない動作の例）
db=# CREATE TABLE t12 (id int, n int);
db=# INSERT INTO t12 VALUES (1,10),(2,10),(3,30),(4,40);
db=# BEGIN;
     SELECT * FROM t12 ORDER BY n FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED;
 id | n
----+----
  1 | 10
  2 | 10
(2 rows)

（別セッションで以下を実行）
db=# SELECT * FROM t12 ORDER BY n FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED;
 id | n
----+----
  4 | 40
(1 row)

これまでパーサが受け付けていて、ALTER TABLE の場合と同じパラメータが指定可能でしたが、これは文書記載がなく、実際には機能しない一方、オプションを付与するとその列やテーブルの削除ができなくなりました。

第一引数が 1 に非常に近い場合に不正確な結果が生じる可能性がありました。「^」演算子の左辺が 1 に近い場合についても同様に該当します。

本障害により、クラッシュまたは誤った問い合わせ結果が生じるおそれがありました。

FROM にある関数が FROM句の副問い合わせの出力をラテラル参照する場合で、副問い合わせを外側の問い合わせに平坦化が可能である場合、関数の式へコピーされた式は完全には処理されませんでした。その結果、プランの実行時にクラッシュを引き起こすおそれがありました。

（本障害でクラッシュを起こす問い合わせの例）
db=# SELECT * FROM (
       SELECT jsonb_path_query_array(mod->'lecs', '$[*]') AS lec
         FROM unnest(array['{"lecs": [{"id": "1"}]}'::jsonb]) AS um(mod)) AS ss,
           jsonb_to_recordset(ss.lec) AS j (id text);

ANALYZE で稀に MCV（most-common-values、最頻値）リストが作られてヒストグラムは作られないことがあります。このような場合、MCVリストのみでデータ全体をあらわせそうな場合に限って、MCVリストのみで列値の範囲を見積をするようになりました。

プロシージャがあるトランザクションをコミットやロールバックして、その次の明示的な動作が新たなサブトランザクション内である場合にスナップショット管理を誤っていました。その結果、不正なポインタが生じて、クラッシュを引き起こす可能性がありました。

典型的には PL/pgSQL で以下のような処理を行う場合に該当します。

  FOR i IN 1..100 LOOP -- 何らかのループ
    BEGIN 
      {問い合わせを実行}
    EXCEPTION
      {条件に応じて COMMIT や ROLLBACK を実行してループを継続}
    END;
  END LOOP;

この誤りは、同じセッションがスナップショットを再びエクスポートしようとした場合に限って問題を引き起こします。ありそうな該当シナリオは、レプリケーションスロットを作成して、それが何らかエラーで失敗して、その後に続けて他のレプリケーションスロットを作成しようとすることです。

予期せぬ「ERROR: clearing exported snapshot in wrong transaction state」が発生する動作が報告されました。

この誤りにより、スタンバイサーバで顕著な性能低下をもたらすおそれがあります。該当した場合、SubtransSLRU についての過大な処理量がはっきり現れました。

同時実行中のセッションが取得したスナップショットで、準備されたトランザクションが省略される可能性がある限られた時間帯がありました。その後、そのセッションがスナップショットを使用してデータを更新すると、誤った結果やデータの破損が発生する可能性がありました。

CTE (WITH句）を伴う問い合わせの EXPLAIN で、以下のエラーが出る動作が報告されました。

ERROR:  could not find RecursiveUnion for WorkTableScan with wtParam 0

歴史的な理由から、ALTER INDEX ... RENAME はあらゆる種類のリレーションに適用できます。インデックス名を変更するのに必要なロックレベルは、テーブル等その他のリレーション名を変更する場合より低いのですが、ALTER INDEX を使った場合には対象がインデックス以外であっても、誤って低いロックレベルが使用されていました。

（誤動作例）
db=# CREATE TABLE t24a (id int);  CREATE TABLE t24b (id int);
db=# BEGIN;
db=*# ALTER TABLE t24a RENAME TO t24x;
db=*# ALTER INDEX t24b RENAME TO t24y;
db=*# ^Z

（別セッションでロックを確認）
db=# SELECT relation::regclass, locktype, mode FROM pg_locks WHERE relation IS NOT NULL;
 relation | locktype |           mode
----------+----------+--------------------------
 pg_locks | relation | AccessShareLock
 t24b     | relation | ShareUpdateExclusiveLock
 t24a     | relation | AccessExclusiveLock
(3 rows)

以前は下記のようなメッセージが出力されましたが、実際のリークはほとんど害のないものでした。

WARNING:  Snapshot reference leak: Snapshot 0x5634afd61cb8 still referenced

本修正は DOMEIN型の列に値を投入したり、DOMAIN型に型キャストする場合のエグゼキュータ処理を効率化します。

これにより、 (1)プライマリ上で多数の排他ロックを保持しているトランザクションをスタンバイでリプレイする場合、 (2)チェックポイント後に削除(unlink)されることになっているファイルが多数ある場合、 (3)ハッシュ集約に多くのバッチ(ディスク書き出し)が含まれる場合、 (4)pg_trgm が複雑な正規表現からインデックス可能な条件を抽出する場合、を含むいくつかのシナリオで処理速度低下が修正されました。

これらのうち、実際にユーザから報告されたのは (1) だけですが、それ以外も非効率なリスト削除により該当すると見られます。

この変更により、テーブルの TID の重複を含むインデックスの破損を検出できるようになります。

アサートを無効にした実運用むけビルドにおいては、このような場合、いくらか非効率的ですが間違ってはいないインデックスになります。

これまで数秒を要することがありました。

以前はこの設定は受け入れられていましたが、実装がないため何もしませんでした。

RETURN QUERY は、UPDATE RETURNING のようにタプルを返すことができる任意のクエリを受け入れるべきです。 v14 では誤って SELECT 以外のものを禁止していました。さらに、可変の RETURN QUERY EXECUTE では、クエリ型チェックがまったく適用されていませんでした。

大域的な（限定なしの）ALTER DEFAULT PRIVILEGES コマンドが関数の EXECUTE などデフォルトである権限を取り消した後、限定付きの ALTER DEFAULT PRIVILEGES コマンドが選択されたロールやスキーマに対してその権限を再び付与した場合、pg_dump は制限付きの権限付与を正しくダンプできませんでした。

pg_dump が子のパーティションのいずれかをロックすれば、パーティションテーブル自体に対する重要な DDL を防ぐのに十分であるためこの見落としはたいていの場合は無害なものでしたが、関連するロックが保持されないため、子のないパーティションテーブルをダンプするときに問題が発生する可能性がありました。

以前は以下のようなファイル名が空のエラーメッセージが表示されていました。

pg_restore: error: invalid line in large object TOC file "": ..

望ましい動作は実行を完了した後、ステータス 2 で終了することで、そのように修正されました。また、ソケットレベル障害のエラー報告が修正されました。

これにより、ほぼ確実に矛盾しているように見える、役に立たないリレーションのチェックが回避されます。

このようなテーブルは空になりますし、UNLOGGEDインデックスもすでにスキップするようになっているため、このようにするのが適切です。

2GB 以上のファイルを一度に読み込もうとするとすると失敗する可能性があるため、複数回に分けて読み込むようになりました。

（サードパーティモジュール以外で）影響があるのは contrib/sepgsql のみです。

これによりインストールされていないプログラムを検出できるようになりました。

initdb は新たなクラスタのタイムゾーンパラメータに、システムのタイムゾーンに対応した IANAタイムゾーンを設定しようとします。これまで Windows で利用していたマッピングテーブルは何年も前に生成され、更新も散発的にしか行われないため、エラーが含まれていたり、最近追加されたゾーンが存在していなかったりと問題がありました。既存インストレーションには影響はなく、新しく初期化されたデータベースクラスタにのみ影響します。

フィジー、ヨルダン、パレスチナ、サモアで夏時間法が変更され、バルバドス、クック諸島、ガイアナ、ニウエ、ポルトガル、トンガの歴史的修正が行われています。

また、Pacific/Enderbury は Pacific/Kanton に名称変更されました。また、Africa/Accra、America/Atikokan、America/Blanc-Sablon、America/Creston、America/Curacao、America/Nassau、America/Port_of_Spain、Antarctica/DumontDUrville、Antarctica/Syowa の各ゾーンは、近くのより人口の多いゾーンに統合されました。これらの名前はエイリアスとして残されています。

PostgreSQL は浮動小数点型は全ての NaN が等しいと見なすため、ハッシュ関数が IEEE 754 規格に従って NaN である全てのパターンに対して同じハッシュコードを生成することが重要です。今までそれができていなかったため、ハッシュインデックスやハッシュを伴った実行計画で、正規化されていない NaN値（'-NaN'::float8 など）に対して、誤った問い合わせ結果がもたらされるおそれがありました。

このような NaN値が含まれる可能性がある場合には、浮動小数点型の列に対するハッシュインデックスを再作成することが推奨されます。

CREATE TABLESPACE から次のチェックポイントまでの間にサーバがクラッシュした場合、クラッシュリカバリが実施されても完全にデータが復元されない可能性がありました。wal_level が minimal 以外の場合には該当しません。

無効化が行われていなかったことによって、既存セッションでロジカルレプリケーションが誤動作を起こす可能性がありました。

無効化が行われていなかったことによって、既存セッションでロジカルレプリケーションが誤動作を起こす可能性がありました。

例えば、numeric(18,3) と定義されている f1列の場合、パーサは f1::numeric の様なキャストを実行時には影響がないという理由で破棄していました。しかし、外側にあらわれる型は、numeric(18,3) ではなく numeric であるべきです。これは再帰的な UNION など、より大きな構造の型を正しく解決するために重要です。

（ビュー定義で型キャストが無視される誤動作例）
db=# CREATE TABLE t51 (f1 numeric(18, 3));
db=# CREATE VIEW v51 AS SELECT f1::numeric AS n1 FROM t51;
db=# \d+ v51
                                View "public.v51"
 Column |     Type      | Collation | Nullable | Default | Storage | Description
--------+---------------+-----------+----------+---------+---------+-------------
 n1     | numeric(18,3) |           |          |         | main    |
View definition:
 SELECT t51.f1 AS n1
   FROM t51;

旧動作が誤っていると考えられますが、非互換性を含む修正となります。

これまでは作成はできていましたが、実際には照合順序は使用できず、削除することもできない状態となっていました。

(.){0}...\1 の様な正規表現において、間違った後方参照番号が引き出され、下記のようなエラーやクラッシュ、アサート失敗が生じる可能性がありました。エラーを発生させずに後方参照がマッチしないと判断するように修正されました。

ERROR:  invalid regular expression: invalid backreference number
ERROR:  invalid regular expression: quantifier operand invalid

正規表現エンジンは部分的なマッチを拒否した後のキャプチャした括弧のマッチデータ排除に関して不注意でした。これにより、定義された参照先がないために失敗するはずの場所で、後方参照が一致する可能性がありました。

（誤動作例）
db=# select 'abcdef' ~ '^(.)\1|\1.';
 ?column?
----------
 t
(1 row)

（先頭で同文字が連続していないので部分マッチせず、全体としても f になるのが正しい）

後方参照のロジックが正しくなく、必要以上に時間を要する箇所がありました。幸いなことに、この問題はほとんどの場合に他の最適化によって顕在化することがありませんでした。

動的な TZ 略語でゾーンが指定されている場合に誤った問い合わせ結果が生じる可能性があります。

（報告された誤動作例、CLT は -03 または夏時間で -04）
db=# SELECT '12:34 -02'::timetz AT TIME ZONE 'CLT';
     timezone
-------------------
 09:51:14-04:42:46
(1 row)

PlaceHolderVars は内部実装上のデータ構造です。この誤りにより、パーティションテーブルや継承テーブルを外部結合の外側（無ければ NULL になる側）に持つ問い合わせで、アサート失敗や実行計画の異常が生じる可能性がありました。実際の問題発生は稀であると考えられます。

実行するための基盤が無いため、実行されてしまうと単に NOTIFY によるキューのクリーンアップを妨げる結果となります。

この変更によってプロシージャ内の COMMIT 直後に通知を送信できるようになりました。また、ロジカルレプリケーションワーカが通知を送信できるようになりました。これまではアイドル状態にならないと送信されず、これらのことができませんでした。

長い間 NO SCROLL カーソルを逆方向にフェッチすることは禁止されていましたが、歴史的背景により、クエリを完全に巻き戻してから再度フェッチすることは禁止されていませんでした。この例外は、特に巻き戻しに必要なデータを全て保持していない可能性のある保留されたカーソルの場合には不整合を引き起こしました（クラッシュが報告されています）。最悪のケースを防ぐためにスクロールできない保留されたカーソルの巻き戻しを禁止するようになりました。

非互換性を含む修正となります。

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

これまでも 2^32 - 1 ブロックという最大長を超えてテーブルやインデックスを拡張する試みはストレージ処理の段階で拒絶されました。しかし、不整合な内部状態を防ぐにはより早い検知が必要で、バッファマネージャにおいてエラーを出すようになりました。

アサート失敗が報告されました。

これが行われなったため、安全でないパラレルプラン選択などの問題が生じるおそれがありました。ルールが適用される問い合わせの実行時に「ERROR: cannot assign XIDs during a parallel operation」が生じる動作が報告されました。

これからは、データ変更を伴う CTE を持つ問い合わせには DO INSTEDルールの適用はできず、そのことを示すエラーになります。

（修正後の振る舞い例）
db=# CREATE TABLE t63a (i int);
db=# CREATE TABLE t63b (i int);
db=# CREATE RULE r63a AS ON INSERT TO t63a DO INSTEAD
       INSERT INTO t63b SELECT NEW.i;
db=# WITH cte1 AS (DELETE FROM t63a RETURNING *)
       INSERT INTO t63a SELECT * FROM cte1;
ERROR:  INSERT...SELECT rule actions are not supported for queries having data-modifying statements in WITH

以前は意図したメッセージではなく以下のようなキャッシュルックアップエラーが出力されていました。

ERROR:  cache lookup failed for type 27447

以前はトランザクション分離レベルが REPEATABLE READ よりも低かった場合、パラレルクエリで誤動作をすることがありました。

アサート失敗が報告されました。

ロジカルデコーディングは、ALTER TABLE によるヒープ書き換えなどで作られる一時テーブルの変更を通常は無視しますが、関連する TOASTテーブルについてそのようになっていませんでした。

これにより、パブリッシュされたテーブルを ALTER TABLE すると、その後で予期せぬエラーが生じることがありました。

アサート失敗やクラッシュを引き起こす可能性がありました。

通知ファイルとは archive_status ディレクトリ下に作られる.ready や .done のサフィックスを持ったファイルです。

これまで walreceiver はちょうど WALセグメント境界で終了した場合、最後に受信したセグメントの通知ファイル作成に失敗していました。その結果、スタンバイでセグメントをアーカイブするのが遅れていました．

昇格直後のベースバックアップがpg_veryfybackup で失敗するケースが報告されていました。

OLD や NEW を指定して SELECT .. FOR UPDATE を行うルールの実行で予期せぬエラーやクラッシュが生じていました。

FILTER式が単純な boolean型の列の場合に、誤った意味解釈が行われて仕様外の動作（即ち、誤った問い合わせ結果）が生じる可能性がありました。また、FILTER式自体が boolean型を返す集約である場合にはエラーを出すべきですが、そのようになっておらず、実行時にクラッシュを起こすことがありました。

（修正前バージョンでの障害発生例）
db=# CREATE TABLE t71 (i int, b boolean);
db=# INSERT INTO t71 VALUES (1, 't'),(2, 't'), (3, 'f');
db=# SELECT (SELECT max(0) FILTER (WHERE b IS TRUE)) FROM t71;
 max
-----
   0
(1 row)

db=# SELECT (SELECT max(0) FILTER (WHERE b)) FROM t71; -- 誤動作する
 max
-----
   0
   0

(3 rows)

db=# SELECT (SELECT array_agg(z.b) FILTER (WHERE bool_or(z.i > 0))
       FROM t71) FROM t71 z; -- クラッシュする
server closed the connection unexpectedly

拡張のスクリプトで実行された ALTER .. SET は、ターゲットとなるオブジェクトが拡張のメンバになっていなかった場合に、それを拡張のメンバにしてしまうことがありました。

拡張のスクリプトがその拡張に属さないオブジェクトにアクセスする理由はほとんど無いため、これ自体は大きな問題はありません。しかし、ALTER TYPE .. SET はその型に依存するドメインにも再帰的に効果を及ぼすため、それらも拡張のメンバになり、拡張のアップグレードスクリプトで望まない副作用を引き起こしました。

これにより、致命的な LLVM のエラーが起きた後にバックエンドが終了する際に起こりうるクラッシュを防止します．

SP-GiST のコードでは、タプルのカウンタは正しく進む一方で、インデックススキャン回数の加算が欠落していました。

これにより設定変更が直ぐに効くようになります。

これは数百GB の work_mem が設定されていない限り顕在化しないため、実際には発生していなかったものと見られます。

コード再編成の誤りで以下のドキュメント記載された関数がエクスポートされていませんでした。

  pg_encoding_to_char()
  pg_utf_mblen()
  pg_char_to_encoding()
  pg_valid_server_encoding()
  pg_valid_server_encoding_id()

ecpg を使うクライアントで pthread の mutex が残ったままになっていて、リソースリークやデッドロックを起こす恐れがありました。

静的関数は古いスナップショットを使って呼ばれており、そのため、セッションのトップレベルコマンドの開始後に行われたデータベースの変更が見えていませんでした。

明示的な RETURN を必要としないルーチンであれば、この使い方は有効でしたが、これまでは許されていませんでした。

これにより、例えば postmaster に渡すコマンドラインオプションを多数指定する場合の制限がなくなります。なお、pg_ctl が扱うパス名についての制限は未だあり、殆どの場合 MAXPGPATH（デフォルト1024）バイトで制限されます。

これらの変更はローカルサーバからのダンプでは重要ではありませんが、リモートサーバからのダンプではネットワーク往復が少なくなることで顕著なメリットがあります。

< や <= 演算子を使ったインデックススキャンが実行されたときに、誤った問い合わせ結果（返るべきエントリが返らない）が生じました。インデックス破損ではなく、検索ロジックの誤りに起因します。

この誤りは、おそらく OpenSSL のインストールを監査する類のタスクを行うコードでのみ問題となります。しかし、形としては OpenSSL API に違反しているため修正されました。

PostgreSQL 12 以降から、長らく正しい pkg-configファイルが提供されていませんでした。

pg_regexec() は PostgreSQL の正規表現機能の内部実装関数です。

search_start が文字列の終わりを過ぎている場合に、これまではクラッシュの可能性がありましたが、REG_NOMATCH を返すようになります。この場合はおそらく PostgreSQLコアコードでは生じませんが、拡張モジュールから使われるかもしれません。

2つの ProjectionPath（射影、ターゲットリストの処理を行うパス）が互いにスタックした場合、プランナが誤った実行計画を作成する可能性がありました。これを再現させる既知の手順は並列ソートのみですが、それ以外の発生パターンもあるかもしれません。本障害によりクラッシュまたは誤った問い合わせ結果が生じます。また、障害動作を狙って起こしてサーバのメモリ内容の漏洩を狙う攻撃も可能です。(CVE-2021-3677)

以下に再現例を示します。

db=# CREATE TABLE t1 (c1 int, c2 int);
db=# INSERT INTO t1 VALUES (1, 2), (3, 4);
db=# SET parallel_setup_cost TO 0;
db=# SET parallel_tuple_cost TO 0;
db=# SET min_parallel_table_scan_size TO 0;
db=# SET max_parallel_workers_per_gather TO 4;

db=# SELECT generate_series(1, c1), array(SELECT generate_series(1, c1)) FROM t1 ORDER BY c2;
（修正前の誤った問い合わせ結果）
 generate_series |   array
-----------------+-----------
               1 | {1,2}
               2 | {1,2}
               1 | {1,2,3,4}
               2 | {1,2,3,4}
               3 | {1,2,3,4}
               4 | {1,2,3,4}
(6 rows)

（修正後の正しい応答）
 generate_series |  array
-----------------+---------
               1 | {1}
               1 | {1,2,3}
               2 | {1,2,3}
               3 | {1,2,3}
(4 rows)

（修正前の誤ったプラン、一部で c1列と c2列が取り違えられている）
db=# EXPLAIN (VERBOSE, COSTS off)
       SELECT generate_series(1, c1), array(SELECT generate_series(1, c1)) FROM t1 ORDER BY c2;
                      QUERY PLAN
-------------------------------------------------------
 ProjectSet
   Output: generate_series(1, t1.c2), (SubPlan 1), t1.c1
   ->  Gather Merge
         Output: t1.c2, t1.c1
         Workers Planned: 3
         ->  Sort
               Output: t1.c2, t1.c1
               Sort Key: t1.c2
               ->  Parallel Seq Scan on public.t1
                     Output: t1.c2, t1.c1
   SubPlan 1
     ->  ProjectSet
           Output: generate_series(1, t1.c2)
           ->  Result
(14 rows)

SSL再ネゴシエーションはしばらく前から無効になっていましたが、クライアイントから再ネゴシエーションの要求があれば受けつけてしまい、悪意の狙って作られた要求によりクラッシュを起こすおそれがありました（OpenSSL の脆弱性 CVE-2021-3449 を参照）。OpenSSL 1.1.0h 以降のそれが可能なバージョンについて、再ネゴシエーションが完全に無効化されました。

この変更により、COMMIT または ROLLBACK の直後に TOAST化された値を取得しようとし、「no known snapshots」または「missing chunk number 0 for toast value」のエラーとなる場合が修正されます。

一部の拡張はポータル外で SQL を実行するかもしれません。このような拡張は事前に外部スナップショットの存在確認をする必要があります。以前はスナップショットを存在せずとも動作する場合もありましたが、今後は「cannot execute SQL without an outer snapshot or portal」のエラーとなります。

（修正前の障害動作例）
db=# CREATE TABLE t3 (c text);
db=# INSERT INTO t3 VALUES ((SELECT string_agg(random()::text, ':') FROM generate_series(1, 1000)));
db=# INSERT INTO t3 VALUES ((SELECT string_agg(random()::text, ':') FROM generate_series(1, 1000)));
db=# DO $$
     DECLARE
       r record;
     BEGIN
       FOR r in SELECT c FROM t3 LOOP
         INSERT INTO t3 VALUES (r.c);
         COMMIT;
       END LOOP;
     END;
     $$;
ERROR:  no known snapshots
CONTEXT:  PL/pgSQL function inline_code_block line 5 at FOR over SELECT rows

以前は、クエリ結果全体を常に巻き戻して再読み取りしていましたが、行を再度取り出した際に以前とは異なる結果となる可能性があり、あとで大きな問題となっていました。NO SCROLL指定のカーソルは順序どおりにしか行を取り出せないため、読み取っていない部分のみを保持することで修正されました。SCROLL指定のカーソルは問題が残ったままですが、不安定なクエリで使用するのは安全でないことがすでにマニュアルに記述されています。そこで、その記述をより強調することで対処されました。

また、PL/pgSQL のクエリ結果による FORループで使用される暗黙カーソルに NO SCROLL指定を強制し、プロシージャ内のコミットでそのようなカーソルを保持する際の同様の問題が修正されました。

（修正前の誤った問い合わせ結果の例）
db=# CREATE TABLE t4 (c1 int, c2 text);
db=# INSERT INTO t4 VALUES (1, 'foo'), (2, 'bar'), (3, 'baz');
db=# DO $$
     DECLARE
       c CURSOR FOR SELECT c1 FROM t4 ORDER BY c1 FOR UPDATE;
     BEGIN
       FOR r IN c LOOP
         UPDATE t4 SET c2 = c2 || ' ' || c2 WHERE c1 = r.c1;
         COMMIT;
       END LOOP;
     END;
     $$;

db=# SELECT * FROM t4;
 c1 |   c2
----+---------
  2 | bar
  1 | foo foo
  3 | baz baz
(3 rows)

(修正後の正しい結果)
 c1 |   c2
----+---------
  1 | foo foo
  2 | bar bar
  3 | baz baz
(3 rows)

グループ化セットなしの GROUP BY と同様に FOR UPDATE は拒否すべきですが、以前は、空のグループ化セットを正しく処理できず、エグゼキュータでクラッシュしていました。

（修正前のクラッシュする問い合わせ例）
db=# SELECT NULL FROM t1 GROUP BY GROUPING SETS (()) FOR UPDATE;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

(修正後)
db=# SELECT NULL FROM t1 GROUP BY GROUPING SETS (()) FOR UPDATE;
ERROR:  FOR UPDATE is not allowed with GROUP BY clause

以前はクラッシュしていました。

（修正前のクラッシュ発生例）
db=# CREATE RULE r AS ON INSERT TO t DO INSTEAD NOTIFY n;
db=# WITH w AS (INSERT INTO t VALUES (0)) VALUES (0);
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

（修正後は以下のエラーが出ます）
ERROR:  DO INSTEAD NOTIFY rules are not supported for data-modifying statements in WITH

（修正前の動作）
db=# SELECT (0.1 - 2e-16383) * (0.1 - 3e-16383);
ERROR:  value overflows numeric format

（修正後の応答）
                                   ?column?
-------------------------------------------------------------------------------
 0.010000000000000000000000000000000(中略)000000000000000000000000000000000000
(1 row)

（修正前の誤動作例：エラーになる場合）
db=# SELECT 0.9999999999 ^ 70000000000000;
ERROR:  value overflows numeric format

（修正前の誤動作例：誤った問い合わせ結果が返る場合）
db=# SELECT 0.9999999999 ^ 23300000000000;
                                   ?column?
-------------------------------------------------------------------------------
 1.000000000000000000000000000000000...中略...000000000000000000000000000000000
(1 row)

（障害動作例）
db=# SELECT to_char(1.2345e-16379::numeric, '9.999EEEE');
ERROR:  division by zero

（修正後の正しい応答）
     to_char
---------------
  1.235e-16379
(1 row)

（正の値の応答）
db=# SELECT pg_size_pretty(10485247::bigint);
 pg_size_pretty
----------------
 10239 kB
(1 row)

（負の値に対する障害動作）
db=# SELECT pg_size_pretty(-10485247::bigint);
 pg_size_pretty
----------------
 -10 MB
(1 row)

（修正後の正しい応答）
 pg_size_pretty
----------------
 -10239 kB
(1 行)

無効なテーブル空間の OID とファイルノード番号に対しては NULL を返すべきですが、以前は 0 を与えた場合に紛らわしいエラーとなっていました。

（修正前のエラー応答）
db=# SELECT pg_filenode_relation(0, 0);
ERROR:  unexpected duplicate for tablespace 0, relfilenode 0

以前は ALTER EXTENSION ADD/DROP と DROP EXTENSION が同時に実行できて、その結果、システムカタログを破損する可能性がありました。

（修正後のエラーが返る動作）
db=# ALTER SUBSCRIPTION s SET (slot_name = '');
ERROR:  replication slot name "" is too short

これまではパーティションテーブルのトリガのステータスが、子テーブルに伝搬しませんでした。

mv と newdata など、特定の名前の列を含むマテリアライズドビューでコマンドが失敗していました。「ERROR: column reference "mv" is ambiguous」といったエラーが発生しました。

同じ勧告的ロックID値に対してセッション寿命とトランザクション寿命の両方のロックを持っている場合、トラザクションは準備された状態にできません。この制限は完全には検査されておらず、PREPARE TRANSACTION 実行時に PANIC を引き起こすおそれがありました。

そのような場合、アサート失敗や「ERROR: tuple already updated by self」が引き起こされました。

特に、DROP OWNED BY を使うのにスーパーユーザであることを必須とする場合について、修正されています。

ある時点から、古い形式のロケールに対して OS がバージョン情報を提供できないためにエラーにしていましたが、そのようなロケールを再度許容するようになりました。

（13.3 バージョンでエラーになる例）
db=# CREATE COLLATION public.ja_jp (LOCALE = 'Japanese_Japan.932');
ERROR:  could not get collation version for locale "Japanese_Japan.932":
error code 87

GENERATED句で行全体の変数を利用することは、生成列がそれ自体もしくは他の生成列を参照できないというルールに違反しており、そのようなケースの動作が明白に定義されていませんでした。実際の動作としては、しばしばクラッシュを引き起こしました。

（GENERATED句に行全体の変数を使用する例）
db=# CREATE TABLE t20 
       (a int PRIMARY KEY, b int GENERATED ALWAYS AS (num_nulls(t20)) STORED);
ERROR:  cannot use whole-row variable in column generation expression

システム列 tableoid に対して 0 や誤った値が取得される場合がありました。ALTER TABLE で後から生成列を加えた場合や、生成列を持つ外部テーブルにINSERT や UPDATE を行う時に誤動作が発生します。

外部テーブルのようにローカルにヒープストレージが存在しない場合、高速デフォルトは役に立たず、その後の操作で混乱が生まれます。バージョン11 で高速デフォルトが追加された際に対象のテーブルが通常テーブルであるかのチェックがなかったため追加されました。

これにより、インデックス述部が IMMUTABLE と宣言されているけれども実際にはそうではない場合の処理で失敗するのを回避できます。CREATE INDEX CONCURRENTLY でアサート失敗が生じるケースが報告されました。

プリペアドステートメントとして、これら命令を実行したときに、「ERROR: unrecognized node type: N」(Nは数値）という予期せぬエラーが生じるケースが報告されました。

今までは最新の SQL コマンドが表示されており、実際には表示されている SQL コマンドではなくレプリケーションコマンドが実行されている場合に紛らわしいものとなっていました。

pending_restart は再起動が必要な設定項目が変更された際は正しく表示されていましたが、設定項目自体が削除された場合に対応できていませんでした。

これにより hash_mem_multiplier を数ギガバイトを超えるような大きなハッシュ集約のディスク書き出しを防ぐ目的で利用できるようになりました。

SELECT FOR UPDATE や関連するコマンドで、アサート失敗、もしくは、「ERROR: could not find junk column」が発生していました。

問い合わせでクラッシュやアサート失敗を起こす動作が報告されました。

いくつかの条件が組み合わさった際にスタンバイが間違った WALタイムラインに従おうとする可能性がありました。

ファイル切り捨ては元に戻せないため、そのレコードよりも前の時点でリカバリを止めることは安全ではありません。トランザクションがコミットされた場合で該当するケースは数年前に修正されていましたが、アボートのケースは修正されていませんでした。

全てのレプリケーションスロットが無効となった際に境界値を再計算しておらず、最終的にサーバの WAL ストレージが溢れる可能性がありました。

これはエラー後において安全な方法ではありません。

タイミングによっては、後のセッションが同じ PGPROCオブジェクトを再利用する場合にアサート失敗が発生する可能性がありました。

relmapper は OID とファイルノードの対応を保持するデータで、ファイル名は pg_filenode.map です。

パラレルワーカによるソート処理の開始前にも状態報告するようになりました。

ロジカルレプリケーションワーカは多くの箇所でアサートを用いて、不適切なレプリケーションコマンドの検査を行っていましたが、通常のエラー処理に変更されました。

不正な入力に対して、デバッグビルドでアサート失敗で停止することも、実運用ビルドで検査が行われないことも、望ましくありません。

TRUNCATE実行時にサブスクライバ側で「ERROR: deadlock detected」が発生していました。

投機的挿入は INSERT .. ON CONFLICT .. で使われる処理です。メモリリークや予期せぬエラー、アサート失敗がもたらされる可能性がありました。

これは後のクラッシュやメモリリークを引き起こす原因となっていました。

結果としてメモリリークが生じる可能性がありました。

場合によってはクラッシュが発生する可能性がありました。

Intelハードウェアでは明白にバグが修正されたという結果が観察できないかもしれませんが、メモリオーダリング制御が弱いマシン上では問題が起きる可能性がありました。

あるコードパスで NULLポインタを解放しようとする可能性がありました。本ケースは、コアサーバのソート利用では到達できないように見えますが、拡張から引き起こされる可能性がありました。

既存のエントリと同一の TID を持つアイテムを挿入しようとすると、クラッシュするのではなく、エラーを投げるようになりました。 これは決して起こるべきではありませんが、インデックスがそのテーブルと矛盾している時に場合に起こることが報告されています。

INCLUDE列がリーフインデックスタプルがページに収まらないほどのスペースを占めている場合、text_ops演算子クラスはタプルを収めるために無駄に無限ループに陥ってしまいました。11以前のバージョンには INCLUDE列がありませんが、演算子クラスのバグに対する良い防御策と思われるので、このループ防止の修正が後方適用されました。

これまでは abort(3) でプログラムを終了させていました。

以前の ecpg の範囲チェックでは INT_MIN ではなく -INT_MAX を範囲内としていたため、-2147483648 が範囲外として拒否されていました。

文字列の終わり近くに不適切にエンコードされたマルチバイト文字があると、様々な処理ループが文字列の最後の NUL を越えて実行される可能性があり、その結果、後続のメモリに何があるかによって、検出不能な問題からプログラムのクラッシュまで様々な問題が発生します。これは CVE-2006-2313 を想起させますが、これらの特定ケースが注意を喚起させるセキュリティ上の重要性を持つとは思われません。

このような場合にダンプで指定されていた状態が失われていました。

新しい glibc バージョンの mktime() の移植性の問題により、異なるタイムゾーンで作成されたダンプファイルに対して pg_restore を実行した時、下記のメッセージが出ていました。

pg_restore: warning: invalid creation date in header
pg_restore: while PROCESSING TOC:

以前、新しいインストールの「oldestXID」は（通常）すぐに周回防止の自動バキュームが強制実行されるような古い値に設定されていました。これはパフォーマンスの観点からは望ましくありません。さらに悪いことに、大きな値の autovacuum_freeze_max_age を使用しているインストールでは、アップグレード直後に不必要な強制シャットダウンが発生する可能性がありました。

これからは、拡張を新PostgreSQLバージョンでデフォルトとされるバージョンにアップグレードするのに必要な ALTER EXTENSION UPDATE コマンドを含む、スクリプトファイルが作成されます。

外部テーブルの生成列が外部テーブルの生成列をあらわす場合については、適切に動作するようになりました。

postgres_fdw は IMPORT でリモートテーブルの生成列を通常の列として取り込み、外部テーブルに INSERT を行う時に「ERROR: cannot insert a non-DEFAULT value into column "..."」というエラーが出ていました。import_generated オプション（デフォルトtrue）が追加され、true なら、IMPORT FOREIGN SCHEMA は生成列を取り込むようになりました。

通常はこの方法で動作しますが、カタログアクセスが機能しないエラーが発生している可能性があるため、あまり安全ではありませんでした。この修正の副作用として、データ変換エラーに関するメッセージで、外部テーブルや外部列の実際の名前ではなく、クエリのテーブルやカラムのエイリアス（使用されている場合）が言及されるようになりました。

これにより、ごく稀な場合でのサーバの堅牢性が向上し、printf の実装が一般的なライブラリと同様となります。

「recovery stopping before abort of transaction %u, time %s」と出力すべきメッセージが、これまでは、「recovery stopping before commit of transaction %u, time %s」と出力されていました。

（メッセージ改善例）
db=# CREATE VIEW v69 AS SELECT * FROM t1;
db=# ALTER TABLE v69 ALTER c SET STATISTICS 0;
ERROR:  "v69" is of the wrong type
（修正後のメッセージ）
ERROR:  "v69" is not a table, materialized view, index, partitioned index, or foreign table

db=# CREATE TABLE t70 (c int) PARTITION BY HASH (c);
db=# CREATE TABLE p70 PARTITION OF t70 FOR VALUES WITH (MODULUS 4, REMAINDER 0);

(修正前)
db=# SELECT satisfies_hash_partition('t70'::regclass, 0, 0, NULL);
ERROR:  modulus for hash partition must be a positive integer
db=# SELECT satisfies_hash_partition('t70'::regclass, 1, -1, NULL);
ERROR:  remainder for hash partition must be a non-negative integer

(修正後)
db=# SELECT satisfies_hash_partition('t70'::regclass, 0, 0, NULL);
ERROR:  modulus for hash partition must be an integer value greater than zero
db=# SELECT satisfies_hash_partition('t70'::regclass, 1, -1, NULL);
ERROR:  remainder for hash partition must be an integer value greater than or equal to zero

libldap_rライブラリが存在しない場合は、libldapライブラリは暗黙的にスレッドセーフであると想定されます。

これらは、ドキュメントをビルドまたはインストールしないことを除き、world および install-world と同じです。

LLVM 13 では、以前の JIT コンパイラではクラッシュをもたらす、互換性のない API の変更が行われています。

GSSAPI の仕様では文字列ポインタと長さを返すことになっています。実際には文字列は通常 null終端されているため、従来コードでもエラーは発生していませんが、AddressSanitizer から問題が報告されました。

最新の Kerberosビルドとのさまざまな非互換性が修正されました。

SHA224ハッシュを使った操作で valgrid がエラーを検知する可能性がありました。これは、アライメント用パディングバイトのメモリ破壊にすぎないため、実際には影響なさそうですが、念のため修正されました。