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 オプションを使用したレプリケーションは失敗していました。

改変されたサーバや信頼できない中間者は、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値が行外に押し出されるほどデータベースに大量の権限付与がある場合に、発生していました。

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