改変されたサーバや信頼できない中間者は、Kerberos のトランスポート暗号化の確立中にゼロ終端されていない文字列を送信できます。次に libpq はその文字列とアプリケーションメモリ内の次のゼロバイトまでのバイトをエラー報告にコピーします。呼び出し側のアプリケーションがエラー報告に対して行なう処理によっては、アプリケーションのメモリ内容が漏洩する可能性がありました。また、メモリ終端を超えた読み取りによるクラッシュの可能性もわずかにありました。

サーバメッセージを適切にゼロ終端させることで修正されました。(CVE-2022-41862)

親テーブルに存在しない、または親列の生成式とは異なる依存関係を持つGENERATED列を更新できない問題が生じていました。誤った更新結果が生じるおそれがありました。

（修正前バージョンの誤動作例）
db=# CREATE TABLE t2p (c1 int);
db=# CREATE TABLE t2c (c2 int GENERATED ALWAYS AS (c1 + 1) STORED) INHERITS (t2p);
db=# INSERT INTO t2c VALUES (10);
db=# SELECT * FROM t2c;
 c1 | c2
----+----
 10 | 11
(1 row)

db=# UPDATE t2p SET c1 = c1 * 10;

（以下で c2列は 101 が正しい）
db=# SELECT * FROM t2c;
 c1  | c2
-----+----
 100 | 11
(1 row)

MERGE の最初の行単位アクションが UPDATE の場合、後続の INSERTアクションでは（UPDATEターゲット列のいずれにも依存していないため）UPDATEアクションで計算する必要がないとみなされた GENERATED列の計算に失敗しました。誤った更新結果が生じるおそれがありました。

（修正前バージョンの誤動作例）
db=# CREATE TABLE t3 (id int PRIMARY KEY, c1 int, c2 int,
                      g3 int GENERATED ALWAYS AS (c1 * 2) STORED,
                      g4 int GENERATED ALWAYS AS (c2 * 2) STORED);
db=# INSERT INTO t3 (id, c1, c2) VALUES (1, 5, 100);
db=# SELECT * FROM t3;
 id | c1 | c2  | g3 | g4
----+----+-----+----+-----
  1 |  5 | 100 | 10 | 200
(1 row)

db=# MERGE INTO t3 USING (VALUES (1,10),(2,20)) v(id, c1) ON t3.id = v.id
       WHEN MATCHED THEN UPDATE SET c1 = v.c1
       WHEN NOT MATCHED THEN INSERT VALUES (v.id, v.c1, 200);

（以下の id=1 の行の g3 は 20 が正しく、id=2 の行の g3、g4 は 40、400 が正しい）
db=# SELECT * FROM t3;
 id | c1 | c2  |   g3   |   g4
----+----+-----+--------+--------
  1 | 10 | 100 |     10 |    200
  2 | 20 | 200 | *null* | *null*
(2 rows)

無条件の WHEN句に続く WHEN句は下記のエラーで到達不能として拒否されるべきですが、このケースは常に検出されるわけではありませんでした。

ERROR:  unreachable WHEN clause specified after unconditional WHEN clause

MERGE はルールのあるテーブルには対応していません。しかし、かつてルールを持っていて今は持っていないテーブルでも以下のエラーが生じていました。

ERROR:  cannot execute MERGE on relation "..."
DETAIL:  MERGE is not supported for relations with rules.

これにより、コードの動作がドキュメントと一致するようになります。本障害および修正で変わるのは、MERGE 実行後の影響を受けた行数の出力値、すなわち、psql で「MERGE 10」などと表示され、libpq の PQcmdTuples(res) で取得できる値だけです。

これまで CTE内から SET句で指定した列を参照すると下記のエラーが生じていました。

（修正前バージョンのエラー発生例）
db=# WITH RECURSIVE cte7(x, y) AS (
       SELECT 0, 0 UNION ALL SELECT x, y FROM cte7 AS r WHERE r.is_cycle
	 ) CYCLE x, y SET is_cycle USING path
	 SELECT * FROM cte7;
ERROR:  cache lookup failed for type 0

保留中のインサートがすぐに外部テーブルラッパー(FDW)にフラッシュされず、BEFORE ROWトリガで本来見えるはずの行が見えないなど、論理的な不整合が発生することがありました。

本障害により、結果としてトリガによる誤った更新が生じる可能性がありました。

pg_dump が REPLICA IDENTITY と印付けされたパーティションインデックスをダンプする時、パーティションインデックスが有効となる前に「REPLICA IDENTITY」を適用するコマンド実行順で生成され、リストア失敗の原因となっていました。 この順序で実行することを禁止する正当な理由はないと判断され、許可するようになりました。インデックスが有効になるまで、REPLICA IDENTITY の印付けは何の効果も持ちません。

DEFAULT指定箇所を適切なデフォルト値の式に置き換えられず、「ERROR: unrecognized node type」が発生することがありました。

（修正前バージョンの誤動作例）
db=# CREATE TABLE t10 (val int);
db=# INSERT INTO t10 VALUES (100);
db=# CREATE TABLE t10_log (ts timestamptz DEFAULT now(), val int, dsc text);
db=# CREATE RULE r10 AS ON UPDATE TO t10
       DO ALSO INSERT INTO t10_log VALUES
         (DEFAULT, OLD.val, 'old'), (DEFAULT, NEW.val, 'new');
db=# UPDATE t10 SET val = 101 WHERE val = 100;
ERROR:  unrecognized node type: 148

jsonpath の一致演算子ではパスパターンに未定義の変数があるとエラーになりますが、存在演算子ではエラーや警告を出さずに一致するものとして扱っていました。

（正しい動作）
db=# SELECT jsonb_path_match('[{"a": 1}]', '$undefined_var');
ERROR:  could not find jsonpath variable "undefined_var"

（修正前バージョンの誤動作例、jsonb_path_match と同様にエラーとなるべき）
db=# SELECT jsonb_path_exists('[{"a": 1}]', '$undefined_var');
 jsonb_path_exists
-------------------
 t
(1 row)

テーブルから直接フェッチされた長いテキスト値を jsonb 添え字として使用すると、エラーを起こす可能性がありました。フェッチ（値の取り出し）では、たいてい一致する要素を見つけられません。この問題を引き起こすほどの長いキーはフィールドではおそらく稀ですが、代入ではガベージキーを使用して値を格納できました。

（修正前バージョンの誤動作例）
db=# CREATE TABLE t12 (id text, test_json jsonb);
db=# INSERT INTO t12 VALUES ('foo', '{"foo": "bar"}');
db=# INSERT INTO t12
       SELECT s, ('{"' || s || '": "bar"}')::jsonb FROM repeat('longsub', 500) s;

（添え字に対する値が見つけられない結果になる）
db1=# SELECT substr(id, 1, 20), test_json[id] FROM t12;
        substr        | test_json
----------------------+-----------
 foo                  | *null*
 longsublongsublongsu | *null*
(2 rows)

一時ファイルに書き出される大きなタプルの最後のチャンクがちょうど 32760バイトである場合、境界バグにより破損する可能性がありました。典型的には後に問い合わせがデータ破損の症状でエラーを出します。例えば（何らかデータ長を示す部分の値が壊れていることによる）「ERROR: XX000: invalid memory alloc request size 1702125924」が出るケースが報告されました。

ここでのデータ破損はメモリ上や一時ファイルで生じるものです。しかし、更新をする並列問い合わせでデータ破損を含む処理がエラーを起こさずに実行されてしまう可能性が無いとは確認されていません。

checkpoint_completion_target の変更後に内部状態が更新されなかったため、特に設定を reload で変更した場合、チェックポイント I/O の実行が設定値に基づいて期待されるよりも高速または低速になることがありました。

recovery_target_inclusive = "off" で recovery_target_xid 設定に基づいてリカバリを終了すると「LOG: recovery stopping before ... transaction」のログメッセージに誤ったタイムスタンプ（常に 2000-01-01）が出力されました。

短くしか読めなかった場合について正しく報告するようになりました。不適切なエラーコードに基づくメッセージではなく、期待されたバイト数と読んだバイト数が出力されるようになります。ロジカルレプリケーションやベースバックアップに関するコードで修正が適用されました。

以前は、これらの型の入力関数は 100 以上の要素を拒否してきました。論理レプリケーションの列をリスト指定できる仕様の導入に伴って、int2vector が最大で 1600列分の要素を受け付ける必要が生じました。

列数の多いテーブルに対して、論理レプリケーションが「ERROR: int2vector has too many elements」エラーを出して、止まってしまう動作が報告されました。

明示的なトランザクション開始命令（BEGIN TRANSACTION など）が無い場合、ANALYZE は勝手にコミットしていました。これはパイプライン化された一連のコマンドの中では望ましくないと判断されました。

これまで、長さが短いキャンセルリクエストも処理されていて、割り当てられたバッファの最後を超えた読み込みが発生していました。理論的にはセグメンテーション違反が起きる可能性がありましたが、そのバッファはメモリ末尾にとても近いため、実際にはほとんど発生しません。良く起きることは、間違ったバックエンド PID やキャンセルコードを指摘するでたらめなログメッセージを出力してしまうことです。

本修正でキャンセルリクエストについても間違った長さであることを示す「LOG: invalid length of startup packet」が報告されるようになりました。

これにより「ERROR: WindowFunc not found in subplan target lists」のようなプランナのエラーが出力されていました。

実際には、実行条件の最適化は int8 を返すいくつかのウィンドウ関数にのみ適用されるので、32-bit でビルドされた時のみの問題です。

作りこまれた問い合わせにより、結果として深い再帰になって、サブクエリの平坦化を試みるのに不合理に長時間を費やす可能性がありました。

これに対する適切な修正は後方適用するには修正量が大きくなります。本修正では、スタックの深さチェックと、問い合わせをキャンセルするための割り込み検査を加えています。

本障害により、Memoize が利用可能なときでも使われない劣った実行計画や、場合よっては誤った実行計画が生じる可能性がありました。

本障害により「ERROR: could not devise a query plan for the given query」というエラーが生じることがありました。エラーを出すのではなく、パーティション横断の結合をしない実行計画を選択するようになりました。

get_actual_variable_range は最大値・最小値を調べる PostgreSQLの内部実装関数で、プランナで使われます。

プランナは、インデックスの最後に現れる大量のタプルを削除した後にこれらのインデックスエントリに killedビットをセットする膨大な仕事をしなければならないことがありました。

本修正で 1つのクエリでの処理量が 100 ヒープページに制限されました。最終的には全てのタプルの削除は必要ですが、これにより突然の大幅な性能低下は回避できます。

テーブルをビューに変更するとクラッシュやアサート失敗になる可能性がありました。

これは「AT TIME ZONE」の引数自体が式になっているルールやビューに対するダンプ/リストアの失敗をもたらしました。

（誤動作例、括弧が外れてしまっている）
db=# CREATE VIEW v27 AS
       SELECT ('2022-12-01'::date + '1 day'::interval) AT TIME ZONE 'Europe/Paris';

db=# SELECT pg_catalog.pg_get_viewdef('v27'::regclass, true);
                                         pg_get_viewdef                         
-------------------------------------------------------------------------------------------------
  SELECT ('2022-12-01'::date + '1 day'::interval AT TIME ZONE 'Europe/Paris'::text) AS timezone;
(1 row)

SQL言語の関数が同じユーティリティコマンドを 1つの問い合わせの中で複数回実行した場合、クラッシュやアサート失敗、「ERROR: unrecognized node type: ..」のような奇妙なエラーが引き起こされる可能性がありました。

（アサート失敗が報告されたSQL実行例）
db=# CREATE FUNCTION f28() RETURNS INT LANGUAGE SQL AS $$
       CREATE TABLE t28 (col0 INT CHECK ('x' = 'x')); SELECT 1; $$;
db=# SELECT f28() FROM (VALUES (1), (1)) AS a0;

これは、ワーカで論理レプリケーションスロットを作成する際に、割り込みをブロックするという不用意な選択によって引き起こされていました。

バージョン15 では検出されないデッドロックをもたらす可能性がありました。バージョン14 ではデッドロックは観測されていませんが、ネットワークI/O を待っている間に割り込みをブロックすることは、やはり望ましくありません。

以前のコードでは接続オブジェクトをリークしていました。 バックグラウンドのコードパスでは呼び出し元のプロセスが終了してしまうので無害です。 しかし、CREATE SUBSCRIPTION のようなコマンドでは、このような失敗により、セッション内での小さなメモリリークが発生していました。

KnownAssignedXids配列のクリーンアップが不十分な場合、特にスタンバイ側で max_connections が大きな値に設定されている場合、性能が低下する可能性がありました。

レプリケーションスロットは、max_slot_wal_keep_size を超過して無効となった後も、システムカタログ内のデッドタプルのクリーンアップを妨げることができました。そのため、レプリケーションの消費者に障害が発生すると、カタログが際限なく肥大化する可能性がありました。

サーバ再起動の後、再起動の直前に発生したトランザクションの変更を再ストリームします。 これらのトランザクションのいくつかは、完了しませんでした。理由は、1つのトランザクションが完了しなかったことに気づいたとき、関連するデコーディング状態をそのサーバでは捨てますが、それについてサブスクライバに伝えていなかったからです。そのため、サブスクライバは、次に再起動するまで、無駄なストリーミングファイルを保持することになっていました。

いくつかのケースで論理デコードの再開時に解放済の XID データの再利用を試み、予測不可能な動作を引き起こすことがありました。

2フェーズトランザクションに関するデータを更新する際に、適切なロックを取得していなかったため、他プロセスから不整合データを見られる可能性がありました。

UPDATE と DELETE のイベントは設定された列一覧に注意を払わないため、予想以上に多くのデータを送信していました。 この問題はレシーバが組み込みの論理レプリケーションコードである場合は発生しませんが、他のレシーバを混乱させる可能性があり、いずれにしてもネットワーク帯域幅を無駄にするものでした。

これを行わなかった場合、スタンバイサーバとプライマリサーバでページが異なる可能性があり、LSN が変更されるタイミングに関する他のいくつかの想定に反しました。 PostgreSQL自体に関する限り、これは理論的な危険性だけであるように思えますが、サードパーティツールを混乱させる可能性がありました。

この関数はその第2引数における一部の値で誤動作していました。 PostgreSQL本体ではそのような使用法は存在していませんが、外部モジュールでは明らかに危険でしたので、修正されました。

epollベースおよび kqueueベースでの実装は、その内部バッファのサイズが呼び出し元の出力バッファのサイズと異なる場合、カーネルにあまりにも多くのイベントを要求する可能性がありました。

このケースはリリース済みの PostgreSQL のバージョンでは発生しないことが知られていますが、この誤りは外部モジュールや将来のバグ修正にとって有害です。

clang の未定義動作サニタイザは、アラインメントが取れていないポインタの使用についてエラーを出します。これが非デバッグビルドで問題を起こす可能性は非常に低いですが、テストのために修正する価値があると判断されました。

このアサートは過度に厳密でした。アサート無しビルドでは無害です。

問い合わせ実行で予期せぬアサート失敗が報告されました。

原理的には、このエラーに到達することはありませんが、それらのいくつかは間違ったタイプのオブジェクトを報告していました（cache lookup failed for schema とすべきところがcache lookup failed for function となる等）。

これまで publicスキーマにデフォルト(pg_database_owner)以外の所有者がいる場合、pg_dump で --if-exists オプションを使用すると、ダンプ出力自体には問題はありませんが、以下のような警告メッセージが表示されていました。

pg_dump: 警告: 文"-- *not* dropping schema, since initdb creates it
"中に IF EXISTS を挿入すべき場所が見つかりませんでした

pg_dump: warning: could not find where to insert IF EXISTS in statement "--
*not* dropping schema, since initdb creates it
"

これらのコマンドは、SQL標準の構文を使用したときに関数本体の開始を誤認していました。

SQL標準の関数本体とは、文字列定数ではなく単一の RETURN 文やBEGIN ATOMIC ～ END のブロックで記述したものを指します。

セッションの一時テーブルは並列ワーカからアクセスできないため、これらの関数のいずれかを使用して一時テーブルを調べる場合に、パラレル実行で結果が取得できない可能性がありました。

以前のパッチでは、対象のすべてのプラットフォームで snprintf() に対応していると想定されていましたが、MSVC 2013 ではまだ完全に対応されていません。MSVC 2013 では sprintf() を使用するように戻されました。

このような組み合わせで、以前は「loadable library and perl binaries are mismatched」というエラーでPL/Perl のロードに失敗することがありました。

推奨しているコンパイラオプションは、Perl のヘッダファイルの最近のバージョンで構造についての警告を引き起こします。 gcc を使用する場合、プラグマを使用してこれらの警告を抑制することができます。

注目すべき点としては、新しいタイムゾーン America/Ciudad_Juarez が America/Ojinaga から分割されました。

rd_smgr は PostgreSQL内部実装における RelationData構造体のメンバ変数です。

必要に応じて再計算する関数で rd_smgr のすべての使用をラップすることにより、一連の操作で rd_smgr が有効であり続けるというさまざまな仮定を取り除きます。これにより、一連の処理の途中で予期しないキャッシュフラッシュが発生した場合に発生するバグが防止されました。

pg_dump は、調べているテーブルが同時に削除されると失敗する可能性のあるいくつかのサーバ関数を使用します。テーブルのプロパティを深く調べる前にアクセス共有ロックを取得し、ダンプするつもりのないテーブルにそのような関数を適用しないようにすることで、この種の失敗が回避されました。

これは、VACUUM が現在のデータベースの datfrozenxid値を更新する必要があり、datacl値が行外に押し出されるほどデータベースに大量の権限付与がある場合に、発生していました。

正常な外部テーブルへの問い合わせでアサート失敗することがありました。

PostgreSQL は大きなテーブルを複数のファイル（通常 1ファイルあたり 1GB のファイル）に分割します。 テーブルを削除するロジックが壊れており、一時テーブルの削除と、通常テーブルを削除する WAL の再生の 2つのケースで、そのようなファイルの最初のファイル以外を削除しそこなうことがありました。 数ギガバイトの一時テーブルを日常的に作成するアプリケーションは、重大なディスク領域のリークを被る可能性がありました。

孤立した一時テーブルファイルは postmaster の起動時に削除されるため、15.1 に更新するだけで、一時テーブルのストレージのリークが解消されます。しかし、15.0 を使用中にデータベースがクラッシュし、その直前に大きなテーブルが削除された可能性がある場合、データベースディレクトリに「NNNN.NN」というパターンに従った名前のファイルがないか確認することが推奨されます。「NNNN」（「.NN」サフィックスなし）という名前の一致するファイルがない場合、これらのファイルは手動で削除する必要があります。

この障害により、「ERROR: cache lookup failed for type ..」エラーが発生したり、古いブランチではクラッシュの原因になることもありました。

（障害発生例）
db=# CREATE TABLE t2 (a int, b text);
db=# CREATE TABLE t2_hist (ts timestamptz DEFAULT now(), a int, b text);
db=# CREATE VIEW v2 AS SELECT * FROM t2;
db=# CREATE RULE r_t2_log AS ON INSERT TO v2
       DO ALSO INSERT INTO t2_hist (a,b) VALUES (NEW.a, NEW.b);
db=# INSERT INTO v2 VALUES (1, DEFAULT), (10, DEFAULT);
ERROR:  cache lookup failed for type 0

これにより、ビューの「ON SELECT」ルールと他のルールとの間の混乱が回避されます。

（問い合わせ自体は実行できる）
db=# WITH RECURSIVE cte4 AS (
       SELECT 1 AS x UNION ALL SELECT x + 1 FROM cte4
     ) SEARCH BREADTH FIRST BY x SET y
     SELECT * FROM cte4 LIMIT 3;
 x |   y
---+-------
 1 | (0,1)
 2 | (1,2)
 3 | (2,3)
(3 rows)

（explain verbose を付けるとエラーになる）
db=# explain (verbose) WITH RECURSIVE cte4 AS (
       SELECT 1 AS x UNION ALL SELECT x + 1 FROM cte4
     ) SEARCH BREADTH FIRST BY x SET y
     SELECT * FROM cte4 LIMIT 3;
ERROR:  record type has not been registered

MERGE で外部テーブルを直接ターゲットにすることは既に禁止されていましたが、このケースはサポートされておらず、理解できないエラーが発生していました。

「ERROR: unexpected operation: ...」のようなエラーが出ることが報告されました。修正により「ERROR: cannot execute MERGE on relation ...」が出るようになります。

以前は、新しく追加されたパーティションに対して、不正確または重複した制約が作成されることがありました。

問い合わせ実行に対して「ERROR: cache lookup failed for statistics object」というエラーが発生する場合がありました。

この間違いは、PostgreSQLのコア部分で悪影響を与えることは知られていませんが、一部の拡張機能で問題が発生していました。

これらのエラーは、デバッグビルドでのアサート失敗や、メモリリークを引き起こす可能性がありました。

これにより、レプリケーションワーカのシャットダウンが遅いという問題が改善されます。

パーティションテーブルは外部テーブルをパーティションとすることができますが、そのようなパーティションへの論理レプリケーションは今のところサポートされていません。実行しようとすると論理レプリケーションワーカのプロセスはこれまでクラッシュしていましたが、エラーを出すようになりました。

論理レプリケーションワーカで実行された SQL言語または PL/pgSQL言語のCREATE FUNCTION または DO コマンドで構文エラーが発生した場合、ワーカプロセスは nullポインターの逆参照またはアサート失敗でクラッシュしていました。

サブスクリプション側にそのようなトリガを定義した場合に現象が報告されました。

これにより、例えば「ON SELECT」ルールが欠落しているビューの使用など、一部のカタログ破損シナリオにおけるクラッシュが防止されます。そのような場合には「ERROR: cannot open relation ...」が出るようになりました。

postmasterプロセスは、共有メモリが破損した場合にも存続し、データベースの再起動を行うはずですが、コードのある 1箇所で対応が不十分でした。

パイプラインモードも有効である場合、単一行フラグが正しいタイミングでリセットされませんでした。

クエリがキャンセルされた場合、「psql -c query」は正常終了していました。他のエラーの場合と同様に、ゼロ以外のステータスで終了するようになりました。

--tablespace-mapping のリモートパスを Unixスタイルまたは Windowsスタイルの絶対パスにすることができるようになりました。これは、ソースサーバがローカルシステムとは異なる OS 上にある可能性があるためです。

このパラメータの最大値を見落としにより、ソースインストールにそれより大きい OID を持つデータベースが含まれている場合、pg_upgrade が成功しませんでした。

これは、拡張問い合わせプロトコルで発行された ROLLBACK コマンドをトラックしている時に発生します。デバッグビルドでは、これによりアサート失敗が発生しました。製品ビルドでは、目立った問題は発生しません。しかし、解放されたメモリが既に再利用されていた場合、クエリ文字列にゴミデータが格納される結果になると考えられます。

この GCC ビルトイン関数をサポートしているコンパイラを使っていさえすれば、新しいマシンアーキテクチャへポーティングが簡単になります。

また、Europe/Kiev ゾーンは Europe/Kyiv にリネームされました。さらに、以下のゾーンは 1970年以来承認されている時計のある人口の多い近傍のゾーンに併合されました:

Antarctica/Vostok、Asia/Brunei、Asia/Kuala_Lumpur、Atlantic/Reykjavik、
Europe/Amsterdam、Europe/Copenhagen、Europe/Luxembourg、Europe/Monaco、
Europe/Oslo、Europe/Stockholm、
Indian/Christmas、Indian/Cocos、Indian/Kerguelen、Indian/Mahe、Indian/Reunion、
Pacific/Chuuk、Pacific/Funafuti、Pacific/Majuro、Pacific/Pohnpei、
Pacific/Wake、Pacific/Wallis

（これは Arctic/Longyearbyen、Atlantic/Jan_Mayen、Iceland、Pacific/Ponape、Pacific/Truk、Pacific/Yap のうちの一つに既にリンクされているゾーンにも、間接的に影響します。）1970年以降に主張されたこれらゾーンとの差異が誤りであるようだと判明した後、America/Nipigon、America/Rainy_River、America/Thunder_Bay、Europe/Uzhgorod、Europe/Zaporozhye も近傍のゾーンに併合されました。

これらの全てのケースでは以前のゾーンの名前は別名として残されています。しかし、実際のデータはマージされたゾーンにあります。これらのゾーン併合は 1970年以前のタイムゾーンの歴史を失うことになります。これは timestamptz 表示の一貫性を期待するアプリケーションには問題となるかもしれません。例えば、保存されている値が「1944-06-01 12:00 UTC」の場合、以前は「1944-06-01 13:00:00+01」と表示されましたが、Europe/Stockholm が選択されている場合は「1944-06-01 14:00:00+02」となります。

より古いゾーンデータをリストアするオプションを付けたタイムゾーンデータファイルを作ることも可能ですが、この選択はたくさんの他の古い（かつ典型的には証明に乏しい） ゾーンデータを追加してしまうことになります。結果として、この上位変更を受け入れる場合よりも、以前のリリースの全体の変更は多くなってしまいます。

PostgreSQL は tzdb の移行を推奨してきましたが、知る限りではほとんどの主要なオペレーティングシステムのディストリビューションでも同様のことをやっています。しかしながら、もしこれらの変更があなたのアプリケーションに重要な問題を起こすならば、可能性のある解決方法は tzdb の後方互換オプションを使ってタイムゾーンデータファイルをローカルにビルドしてインストールする方法です（PACKRATDATAオプションと PACKRATLISTオプションを見てください）。

並行する VACUUM が UPDATE または DELETE で更新中のページの全ての可視フラグビットをセットするなら、その更新コマンドはそのビットをもう一度クリアする必要があります。しかし、いくつかのコードパスはそれに失敗し、PANIC で終了していました。

これはバージョン 14 と 15 で起きる可能性があることが知られています。それより前のブランチでは顕在化しないかもしれません。

正常な状態において「ERROR: tupdesc reference ... is not owned by resource owner ...」というエラーが出た後、「PANIC: ERRORDATA_STACK_SIZE exceeded」によるサービス全体の停止または再起動が発生しました。

最初に与えられた名前がそのパーティションの何らかの制約として既に使われていたら、新しい制約名が選ばれますが、意図した名前になっていませんでした。誤って「リレーション名__fkey」という制約名が生じていました。

パーティションテーブルにインデックスを作るときに、定義が一致する各パーティション上の既存インデックスを識別して、それを子インデックスとして取り込みしようとします。このとき、式の照合が正しく行われず、パーティション上の利用可能な既存インデックスが無視されて、重複したインデックスが作成されることがありました。

アーカイブリカバリ中の（スタンバイモードではない）PostgreSQLインスタンスが昇格するときに、最後に読み込もうとした WALセグメントが部分レコードで終わっていた場合、新しいタイムライン上に無効な WAL セグメントを書き込んでいました。

システムカタログを変更するトランザクションの途中でデコードが開始されると、デコーダがそれを認識できないことがあり、その結果、カタログ検索でそのトランザクションが進行中として扱われませんでした。

重要なのはリーフパーティションのレプリカアイデンティティの設定であり、それが親テーブルに設定されていない場合にエラーを投げる必要はありません。

インライン化されていない SQL関数が 2つ以上の場所で引数を使用し、そのうちの 1箇所で読み書き可能なデータムを上書きで変更できると期待した場合、後でそのパラメータを使用した時に間違った値が観測されました。

配列を引数に取る再帰的な SQL関数の実行で、誤った問い合わせ結果が生じるケースが報告されました。PostgreSQL本体内では拡張データム機構は、配列と複合型の値に対してのみ使用されています。

左側の円の半径が浮動小数点数の NaN であった場合、中心座標が同じで任意の半径を持つ円と等しいと見なされるようになりました。

入力単語が 1000バイトを超える場合、Snowballコードを通すのではなく、大文字小文字を揃えた後、そのまま返すようになりました。

この制限は、トルコ語の語幹機能における recursion-to-stack-overflow への既知問題から保護し、Snowballの語幹機能におけるその他の安全性や性能の問題に対する良い保険になると考えられます。

文字列比較関数の不適切なメモリ管理により、もはや割り当てられていないバッファに書き込みが生じて、そのメモリを現在使用している何かが壊れる可能性がありました。

これは、かなり長い文字列（1kB以上）で ICU照合順序が使用されている場合にのみ、発生しました。

巨大な SQL文で「ERROR: stack depth limit exceeded」のエラーを出さずに、バックエンドプロセスがクラッシュする動作が報告されていました。

以前からのバグであるにもかかわらず現場からの報告がないことから、この問題はバージョン15 より前のブランチでは顕在化しないと思われますが、確かではないため、各バージョン系列にバックパッチが行われました。

多相パラメータに対して行うのと同じように、セッション中に RECORDパラメータに渡される各具象型に対して、個別の関数キャッシュ項目を構築するようになりました。これにより、以前は「ERROR: type of parameter ... does not match that when preparing the plan」などのエラーで失敗していたいくつかの使用法が動作するようになりました。

libpq の関数は、NULL の PGconn 引数を検査して、クラッシュする代わりにエラーを出す、という慣習があります。PQflush() と PQisnonblocking() でこれが守られていなかったため修正されました。

これまで「static varchar str1[10], str2[20], str3[30];」を以下のように変換していました。

（不適切な出力例）
static struct varchar_1  { int len; char arr[ 10 ]; }  str1 ;
       struct varchar_2  { int len; char arr[ 20 ]; }  str2 ;
       struct varchar_3  { int len; char arr[ 30 ]; }  str3 ;

これにより「ERROR: variable not found in subplan target list」エラーが防止されます。EvalPlanQual は READ COMMITTED 隔離レベルの問い合わせで使われる処理です。

uuid-osspモジュールでは libc の uuid_create() がバージョン1 の UUID を生成すると期待していますが、最近の NetBSD のリリースでは、代わりにバージョン4 の (ランダムな) UUID を生成します。これを検査して、そうであればエラーを出すようになりました。

ドキュメントの、NetBSD の実装が uuid-ossp に使用可能という記載も削除されました。（バージョン4 の UUID が必要な場合には、uuid-ossp モジュールではなく、本体付属の関数 gen_random_uuid() を使ってください。）

PostgreSQL/Test/Cluster.pm と PostgreSQL/Test/Utils.pm をバージョン15 より前のブランチの標準インストールファイルに追加しました。これは、古いブランチで新しく書かれたテストコードを使いたい拡張のためです。

これにより、NetBSD 10 におけるダイナミックリンカでのデッドロックの危険性を回避できるようになりました。

エラーを投げるのではなく、むしろ問題を記録し、空のページを削除せずに続行するようになりました。以前は、バグのある演算子クラスまたは破損したインデックスにより、インデックスのバキューム処理がいつまでも完了せず、最終的に XID周回の問題につながっていました。

以下メッセージが ERROR から LOG に変更されます。「failed to re-find parent key in index ... for deletion target page ...」

構文 UPDATE tab SET (c1, ...) = (SELECT ... ) を継承テーブルやパーティション化された対象テーブルに使用すると、子テーブルが十分に異なっている場合、失敗することがありました。

これは通常、エグゼキュータでの一貫性チェックの失敗のエラーとして現れます。しかし、クラッシュや不正なデータ更新（すなわち論理的なデータ破損）も起こり得ます。

本構文の UPDATE に対して、「ERROR: invalid attribute number ...」などの予期せぬエラーの発生が報告されました。

この誤りは、アサート失敗や「ERROR: variable not found in subplan target list」 などのプランナエラーにつながる可能性があります。