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 がエラーを検知する可能性がありました。これは、アライメント用パディングバイトのメモリ破壊にすぎないため、実際には影響なさそうですが、念のため修正されました。

これまでの配列の実装では、配列の下限と長さが整数をオーバーフローさせる場合を問題としていませんでした。その結果、（添え字を整数として書けないため）配列後方のエントリがアクセス不能になり、さらに重要なことには、続く代入操作を混乱させました。このことは、確実なクラッシュや望まないデータ書き換えを伴うメモリ上書きをもたらすおそれがありました。

サポート終了バージョンであるため修正はリリースされませんが、9.5以前のバージョンについても同様の問題があると考えられます。

UPDATE のリストが、適切な結果に加えて不要列（使われない不要な列、ごみ列）を発生させるような複数列の副問い合わせを持つ場合、UPDATE の処理コードは最終的に余分な不要列の値を含むタプルを格納していました。これは短い実行ではおよそ無害ですが、テーブルに新たな列が追加された場合、その値がアクセス可能になってしまい、追加した列とデータ型が合わない場合には不具合になるおそれがありました。

加えて、パーティションをまたがる更新に対応したバージョンでは、このようなケースで引き起こされたパーティションをまたがる更新が、逆に対象リストから不要列が削除される問題をもたらし、典型的には即座のクラッシュを引き起こしました。

この障害を利用して、一時テーブルを含む、テーブル作成権限を持ったユーザによる、サーバ側の任意メモリを読み取る攻撃も可能でした。

（クラッシュ発生例）
db=# CREATE TABLE t2 (a int PRIMARY KEY, b text) PARTITION BY LIST (a);
db=# CREATE TABLE t2_1 PARTITION OF t2 FOR VALUES IN (1);
db=# CREATE TABLE t2_2 (b TEXT, a INT PRIMARY KEY);
db=# ALTER TABLE t2 ATTACH PARTITION t2_2 FOR VALUES IN (2);
db=# INSERT INTO t2 VALUES(1, 'Boo'), (2, 'Zoo');

db=# WITH aaa AS (SELECT 1 AS a, 'Foo' AS b)
     INSERT INTO t2 VALUES (1, 'Bar') ON CONFLICT (a)
       DO UPDATE SET (b, a) = (SELECT b, a FROM aaa) RETURNING *;
 (a=1、b='Foo' の 1行が返る)

db=# WITH aaa AS (SELECT 1 AS ctea, ' Foo' AS cteb)
     INSERT INTO t2 VALUES (1, 'Bar'), (2, 'Baz') ON CONFLICT (a)
       DO UPDATE SET (b, a) = (SELECT t2.b || cteb, t2.a FROM aaa) RETURNING *;
 (ここでクラッシュ発生)

パーティションテーブルの UPDATE により、行が物理的に異なる行タイプを持つ別のパーティション（例えば、削除された列のセットが異なるパーティション）に移動された場合、その行に対する RETURNING 結果の計算でエラーや間違った答えが生じる可能性がありました。UPDATE で他のテーブルが対象テーブルに結合されない限り、エラーは発生しません。

以下は本障害によりパーティションテーブルの UPDATE で発生するエラーの一例です。

ERROR:  attribute 5 of type record has wrong type
DETAIL:  Table has type record, but query expects integer.

この障害を利用して、一時テーブルを含む、テーブル作成権限を持ったユーザによる、サーバ側の任意メモリを読み取る攻撃が可能でした。

遅延プロパティをパーティションテーブルの外部キー制約に適用するとき、ALTER TABLE ... ALTER CONSTRAINT は、リーフパーティション（末端のパーティション）の制約およびトリガの DEFERRABLE および INITIALLY DEFERRED の印付け調整に失敗しました。これにより、これらの制約の予期しない動作が発生しました。

バージョンアップ後に ALTER コマンドを実行して、必要なプロパティを設定することで、誤動作しているパーティションテーブルを修正できます。

本修正により、リーフパーティションの制約に直接このような ALTER を適用することもできなくなりました。 唯一サポートされているケースは、パーティショニング階層全体が同一の制約プロパティを持つことであるため、このような ALTER はルートパーティション（親テーブル）で適用される必要があります。

これまでは子テーブルの定義が異なっていても、無視して子テーブルの定義を捨てていました。本修正で親子で生成列の定義が異なる場合にエラーが出るように変更されました。

db=# CREATE TABLE t13_p1 (a int, b int GENERATED ALWAYS AS (a * 2) STORED);
db=# CREATE TABLE t13_c1 (a int, b int GENERATED ALWAYS AS (a * 3) STORED);

（13.2 での動作）
db=# ALTER TABLE t13_c1 INHERIT pp1;
ALTER TABLE

（13.3 での動作）
db=# ALTER TABLE t13_c1 INHERIT pp1;
ERROR:  column "b" in child table has a conflicting generation expression

GENERATED ALWAYS AS IDENTITY は NOT NULL を意味しますので、明示的な NULL 指定と組み合わせて使用することはできません。

以前は、後で使用する際に値が有効であったとしても、過剰な有効性チェックによってこれらのコマンドが拒否されることがありました。 このため、ダンプ/リロードや pg_upgrade の際に、コマンドの順序が乱れてしまうことがありました。

これまでは実行前に設定されていた pg_attribute.attstattarget が REINDEX CONCURRENTLY を実行して作成される新しいインデックスで失われていました。

以下に本修正による動作の違いを示します。

（13.2 での動作）
db=# BEGIN;
db=*# SAVEPOINT foo;
db=*# COMMIT AND CHAIN;
db=#
（↑トランザクションが終了、プロンプトが # に変わっています）

（13.3 での動作）
db=# BEGIN;
db=*# SAVEPOINT foo;
db=*# COMMIT AND CHAIN;
db=*#
（↑正しく動作して再びトランザクション内になります、プロンプトが *# です）

7レベル以上の十分に深い WITH構造の入れ子によりクラッシュや、WITH 入れ子に対する誤ったエラー（下記）が発生していました。

ERROR:  stack depth limit exceeded

本障害により、COLLATE が照合不能な値に適用されているように見える解析ツリーが作成されていました。COLLATE は実行時には影響しないため、通常の使用上の影響はありませんが、ダンプ/リロード時に拒否されるビューを作成することがありえました。

（誤動作例： \d 出力のビュー定義の COLLATE句 が余計で、この SELECT はエラーになる）
db=# CREATE VIEW v9 AS
       SELECT c1+1 AS c1p FROM (SELECT ('4' COLLATE "C")::INT AS c1) ss;
db=# \d+ v9
                             View "public.v9"
 Column |  Type   | Collation | Nullable | Default | Storage | Description
--------+---------+-----------+----------+---------+---------+-------------
 c1p    | integer |           |          |         | plain   |
View definition:
 SELECT ss.c1 + 1 AS c1p
   FROM ( SELECT 4 COLLATE "C" AS c1) ss;

これにより状況によってはクラッシュをおこす可能性がありました。

ここでは普通の関数のみがサポートされます。集約関数の呼び出しはすでにエラーとなっていましたが、ウィンドウ関数の呼び出しはクラッシュし、プロシージャの呼び出しはそのプロシージャがトランザクション制御を行わない場合にのみ機能していました。

以前は、pg_event_trigger に対する本関数の実行で、予期せぬエラー「ERROR: requested object address for unsupported object class 32: text result "ddl_postgrest"」が発生していました。

以前そのような時は通常クラッシュを引き起こしてました。

（修正前 13.2 ではクラッシュ）
db1=# SELECT * from TO_CHAR(interval '-1Mon', 'rm');
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.

（修正後 13.3 の動作例）
db=# SELECT * from TO_CHAR(interval '-1Mon', 'rm');
 to_char
---------
 xii
(1 row)

これまで不正な値に対してアサート失敗が生じていました。アサート無効のビルドでは、おそらく無害ですが pg_collation に無効な collnamespace列の値を持ったエントリができる可能性がありました。

この誤りにより、数量詞が欲張りでない動作をする可能性がありました。すなわち、完全な正規表現（ARE) における {m,n}? 数量詞の動作と同様に振る舞いました。

これまでは (a, b) の拡張統計が存在するテーブルに対する「SELECT ... GROUP BY a, b, ctid」といったシステム列を含めた問い合わせの推定値がおかしくなっていました。

通常、選択度は NaN と評価され、後にアサート失敗や奇妙なプランナ動作を引き起こす可能性がありました。

下記の正規表現を使用してアサート失敗が発生するケースが報告されました。

SELECT * FROM test WHERE t ~* ('^' || repeat('-', 500));

BRINインデントのページ範囲サイズが 2 の累乗でなければ、ビットマップスキャンがテーブル実際の終りより先のページを読み込もうと試み、稀に「ERROR: could not open file」が出ることがありました。

マッチするインデックス数が過大になると（閾値は work_mem 設定値で決まります）、保持しているビットマップは損失を伴うもの（lossy）になります。このとき、再チェック（recheck）は不要と誤判断する可能性があり、誤った問い合わせ結果を返すことがありました。

以前（13.0 リリース前）の修正によって「LOG: could not rename file ...: Permission denied」というログメッセージが断続的に出力されていて、その修正が元に戻されました。深刻な問題ではありませんでしたが大量のログ出力が迷惑でした。

この不具合により、後続の WALレコードは間違ったタイムラインID で記録され、整合性が取れなくなる問題や、サーバが再起動できなくなる問題が起きる可能性がありました。

スタンバイサーバがリカバリの途中で切断されると、保持しているロックが一部残る可能性があり、デバッグが有効なビルドではアサート失敗が発生していました。本番ビルドで重大な問題が発生するかは不明です。

通常のコマンド実行では問題がありませんが、レプリカのトリガから実行するときにクラッシュが発生しました。

FreeBSD 13 は open_datasyncをサポートしているため、通常、それがデフォルトで選択されました。しかしながら PostgreSQLにとってそれがより優れた選択とは限られませんので、既存のデフォルト設定のままにするようになりました。

古くなった統計情報を追跡するという考えはautovacuum_vacuum_insert_threshold設定とは相性が悪く、結果として必要のないフルインデックススキャンが行われ、autovacuum のパフォーマンス劣化につながりました。autovacuum_vacuum_insert_threshold の仕組みがより優れていると判断されて、古い統計情報のロジックが削除されました。

vacuum_cleanup_index_scale_factor設定はバージョン14 から完全に削除されます。既存の設定ファイルにも影響を及ぼすという懸念から、バージョン13 ではまだパラメータが残されていますが、機能はしなくなりました。

ALTER CONSTRAINT の中でトリガを更新する際、ALTER 処理後のフックはトリガを更新するものと知らされますが、ここでトリガの OID ではなくトリガのための制約の OID が渡されていました。ALTER 後に誤った制約の動作が生じました。

（修正前バージョン 13.2 での障害動作例）
db=# CREATE TABLE pt27m (k1 int, k2 int, PRIMARY KEY (k1, k2)) PARTITION BY LIST (k1);
db=# CREATE TABLE p27m1 PARTITION OF pt27m FOR VALUES IN (1);
db=# CREATE TABLE pt27t (k1 int, k2 int, v int) PARTITION BY LIST (k1);
db=# CREATE TABLE p27t1 PARTITION OF pt27t FOR VALUES IN (1);

db=# BEGIN;
db=*# ALTER TABLE pt27t ADD CONSTRAINT fkey1 FOREIGN KEY (k1, k2) REFERENCES pt27m;
db=*# ALTER TABLE pt27t ALTER CONSTRAINT fkey1 DEFERRABLE INITIALLY DEFERRED;

db=*# INSERT INTO pt27m VALUES (1, 2);
db=*# INSERT INTO pt27t VALUES (1, 2, 100);
db=*# DELETE FROM pt27m;
ERROR:  update or delete on table "p27m1" violates foreign key constraint "pt27t_k1_k2_fkey" on table "pt27t"
DETAIL:  Key (k1, k2)=(1, 2) is still referenced from table "pt27t".

（最後の DELETE による制約違反はコミット時までエラーにならないのが本来の期待される動作です）

パラレルクエリで作成されたテンポラリファイルが即時に削除されない問題が発生する可能性がありました。

この誤りは殆どのプラットフォームで無害ですが、アトミック変数やスピンロックがサポートされないプラットフォームでは下記のエラーが発生する可能性がありました。

ERROR:  invalid spinlock number: 0

修正前は以下のようなエラーが発生していました。

ERROR:  tupdesc reference ... is not owned by resource owner TopTransaction

（initdb 出力メッセージの例）

成功しました。以下のようにしてデータベースサーバを起動できます。

　^"C^:^/Install^ Dir^/bin^/pg^_ctl^" -D ^"C^:^\database^\data^" -l <ログファイル> start

（↓上記が以下のように出力されるようになります）

　^"C^:^\Install^ Dir^\bin^\pg^_ctl^" -D ^"C^:^\database^\data^" -l <ログファイル> start

以前のバグ修正により、PGPORT などの環境変数が接続サービスファイルのエントリを上書きしていました。サービスファイルでの指定が優先される、以前の振る舞いに戻されました。

psql が COMMIT AND CHAIN によって既に解放済みの自動発行セーブポイントを解放しようとして、「ERROR: savepoint "pg_psql_temporary_savepoint" does not exist」というエラーになっていました。

高速な入力を行うと、一時編集ファイルの変更をファイルタイムスタンプから検知できないことがありえました。直近のファイル変更内容が反映されない動作をすることが報告されました。

前マイナーリリースで導入された修正はパーティションテーブルには適用すべきではなく、従来からの継承テーブルにのみ適用すべきでした。

シークできないカスタム形式のダンプファイルを読み取る場合、pg_restore はダンプファイルのバージョンを確認していませんでした。サポートされているものより新しいダンプファイルの形式が提供された場合、リストアに失敗することになります。

pg_restore が「pg_restore: [archiver] unsupported version (...) in file header」のエラーを出す代わりにクラッシュする動作が報告されました。

アップグレード不可能なデータ型がコンテナ型（配列や範囲など）に埋め込まれている場合の検出が改善されました。

また、ユーザーテーブルにシステム定義の複合型の列（システムテーブルを複合型として使っている場合など）が含まれている場合には、それらの型の OID はバージョン間で安定していないため、アップグレードを許可しないようになりました。

これは SELECT FOR UPDATE 実行後においては正常な状態でした。

通常、深刻な影響はありませんが、postmaster に SIGHUPシグナルが繰り返し送信されると、時間の経過と共にメモリリークが増大する可能性があります。