永続オブジェクトの作成、削除ができる攻撃者により、SQLコードのインジェクションが可能でした。そのコードは pg_dump を起動するロール（しばしばスーパーユーザです）の権限で、並列 pg_dump のセッションから実行されます。シーケンスのようなオブジェクトを悪意のコードを実行するビューや外部テーブルで置き換えることで、攻撃が行われます。これを防ぐため、ビルトインでないビューの展開および外部テーブルへのアクセスを無効にできる新たな設定パラメータ restrict_nonsystem_relation_kind が導入されました。デフォルトは ''（空文字列）で、カンマ区切りで view や foreign-table を指定します。この設定が pg_dumpコマンド内で SET で指定されるようになります。攻撃を防ぐにはサーバと pg_dumpコマンドの両方のアップデートが必要です。(CVE-2024-7348)

内側のリレーションが制約でユニークな結合キーを持つと分かっている場合に、外側のリレーションに結合キーの重複した行があるとき、マージが誤動作を起こす可能性がありました。

（誤動作例）
db1=# CREATE TABLE t2 (a int UNIQUE, b int);
db1=# INSERT INTO t2 SELECT g, g % 100 FROM generate_series(1,1000) g;
db1=# CREATE INDEX ON t2 (b);
db1=# ANALYZE t2;
db1=# SET enable_hashjoin TO off;
db1=# SET enable_nestloop TO off;
db1=# SELECT * FROM t2 t2out WHERE NOT EXISTS
        (SELECT 1 FROM t2 t2in WHERE t2in.b = t2out.a) AND t2out.b < 2;

→ Nested Loop Anti Join や Hash Right Anti Join の場合には正しく動作するが、
   Merge Right Anti Join を使った実行プランでは少ない件数が返る。

長時間実行中のトランザクションを伴う切断されたスタンバイサーバがプライマリサーバに再接続した後に、プライマリでの VACUUM 処理が、どのタプルが除去可能かについて混乱する可能性があり、その結果、無限ループに陥ることがありました。

アサート失敗が報告されました。アサートを無効にした実稼働むけビルドでは、クラッシュや誤動作が生じる可能性があります。

（障害発生例）
db1=# CREATE TABLE t_inh_p (a int);
db1=# CREATE TABLE t_inh_c () INHERITS (t_inh_p);
db1=# DROP TABLE t_inh_c;
db1=# CREATE TABLE pt (a int) PARTITION BY LIST (a);
db1=# ALTER TABLE pt ATTACH PARTITION t_inh_p FOR VALUES IN (1);
db1=# INSERT INTO t_inh_p VALUES (1);
db1=# UPDATE t_inh_p SET a = 2 WHERE a = 1;
→ ここでアサート失敗が生じる（正常動作はパーティション制約違反のエラー）

パーティションテーブル（親テーブル）に制約と関連付かないインデックスがあって、そのパーティション（子テーブル）に同等の制約のインデックスがある場合、パーティションをデタッチするときにアサート失敗が生じたり、システムテーブル pg_constraint の coninhcount列が誤った値になりました。

db1=# CREATE TABLE pt5 (a int) PARTITION BY LIST (a);
db1=# CREATE TABLE p5 PARTITION OF pt5 FOR VALUES IN (1);
db1=# ALTER TABLE p5 ADD PRIMARY KEY (a);
db1=# CREATE UNIQUE INDEX ON pt5 (a);
db1=# ALTER TABLE pt5 DETACH PARTITION p5;
→ ここでアサート失敗か、以下が 0 ではなく -1 になる。
db1=# SELECT coninhcount FROM pg_constraint WHERE conname = 'p5_pkey';

エグゼキュータはプラン作成と実行の間でパーティションがデタッチされないと想定していましたが、CONCURRENTLY指定を使う場合にはその前提は成り立ちません。パーティションテーブルに対する問い合わせ実行で、そのようなタイミングのときに、アサート失敗や以下のようなエラーが発生しました。

ERROR:  missing relpartbound for relation ..
ERROR:  could not match partition child tables to plan elements

パーティションが無くなったパーティションテーブルに対する最初の ANALYZE でrelhassubclass = f の変更をするときに reltuples = 0 の変更が失われていました。

SQL の CALL文は多様OUT引数に対して正しいデータ型を解決できず、「ERROR: cannot display a value of type anyelement」などのエラーや、クラッシュを引き起こしました。

なお、PL/pgSQL 内の CALL は問題ありません。

（障害動作例）
db1=# CREATE PROCEDURE pro1 (i1 IN anynonarray, o1 OUT anynonarray)
        LANGUAGE sql AS $$ SELECT i1; $$;
db1=# CALL pro1('aa'::text, NULL);
ERROR:  cannot display a value of type anynonarray

CALL が、トランザクションブロック内のアトミックなコンテキストで実行された場合に、誤って外側トランザクションの開始時点のスナップショットが STABLE関数に渡されて、古い値が参照されていました。

（誤動作例）
db1=# CREATE TABLE t9 AS SELECT 0 AS x;
db1=# CREATE FUNCTION f_get_x() RETURNS int STABLE LANGUAGE plpgsql AS
      $$ DECLARE r int; BEGIN SELECT x INTO r FROM t9; RETURN r; END; $$;
db1=# CREATE PROCEDURE f_print_x(x int) LANGUAGE plpgsql AS 
      $$ BEGIN RAISE NOTICE 'f_print_x(%)', x; END; $$;
db1=# BEGIN;
db1=# DO $$ BEGIN
            UPDATE t9 SET x = x + 1;
            RAISE NOTICE 'f_get_x(%)', f_get_x();
            CALL f_print_x(f_get_x());
            UPDATE t9 SET x = x + 1;
            RAISE NOTICE 'f_get_x(%)', f_get_x();
            CALL f_print_x(f_get_x());
            END $$;
NOTICE:  f_get_x(1)
NOTICE:  f_print_x(0)   （← 正しくは 1）
NOTICE:  f_get_x(2)
NOTICE:  f_print_x(0)   （← 正しくは 2）
db1=# ROLLBACK;

'T12:34:56' のような書き方を再び許容するようになりました。PostgreSQL 15.x 以前では受け入れられていましたが、16.0 以降で「ERROR: invalid input syntax for type ...」のエラーになっていました。

money型に対する算術関数はこれまでオーバーフロー検査をしていませんでした。そのため、オーバーフローする場合に誤った問い合わせ結果が生じていました。

（誤動作例）
db1=# SELECT '92233720368547758.07'::money + '0.01'::money;
          ?column?
-----------------------------
 -$92,233,720,368,547,758.08
(1 row)
→ 修正後は「ERROR:  money out of range」エラーが出る。

これまでスケール引数は（文書に記載なく）正負 2000桁までに制限されていて、それを越える場合には、誤った問い合わせ結果が返っていました。numeric型の上限に合わせた桁数を上限とするように修正されました。

（誤動作例 - 本来全て「1000」にならないといけない）
db1=# SELECT substr(round(1.234e1999, -1999)::text, 1, 4);
 substr
--------
 1000
(1 row)

db1=# SELECT substr(round(1.234e2000, -2000)::text, 1, 4);
 substr
--------
 1000
(1 row)

db1=# SELECT substr(round(1.234e2001, -2001)::text, 1, 4);
 substr
--------
 1200
(1 row)

（誤動作ケース - 期待される正しい出力は「-8192PB」）
db1=# SELECT pg_size_pretty('-9223372036854775808'::bigint);
       pg_size_pretty
----------------------------
 -9223372036854775808 bytes
(1 row)

このような場合に、これからは NULL を返すようになります。本関数は pg_sequences ビューの中で使われるもので文書化されていません。

（プライマリサーバで実行 - これで UNLOGGED のシーケンスが作られる）
db1=# CREATE UNLOGGED TABLE t14 (id serial);

（スタンバイサーバで実行 - 修正前バージョンではエラーになる）
db1=# SELECT * FROM pg_sequences ;
ERROR:  could not open file "base/18077/18108": No such file or directory

マニュアルでは websearch_to_tsquery() の入力中の記号は、ダッシュ(-) と引用符(") の特別な場合を除き無視されることになっています。しかしながら、括弧といくつかの記号が or の直前に現れた場合、or が演算子ではなく or という単語として扱われる動作がありました。

（or は引用符で囲わない限り演算子）
db1=# select websearch_to_tsquery('simple', 'cat or dog');
 websearch_to_tsquery
----------------------
 'cat' | 'dog'
(1 row)

（誤動作例 - 括弧があると or が演算子として扱われない）
db1=# select websearch_to_tsquery('simple', '(tom cat) or dog');
     websearch_to_tsquery
------------------------------
 'tom' & 'cat' & 'or' & 'dog'
(1 row)

以下の INSERT が正しくエラーになるようになりました。

（修正前バージョンでは a = '{}' で行が挿入される）
db1=# CREATE TABLE t16 (a int[]);
db1=# INSERT INTO t16 (a[-2147483648:2147483647]) VALUES ('{}');
ERROR:  array size exceeds the maximum allowed (134217727)

バージョン 16.1、15.5、14.10、13.13、12.17、11.22 で修正された、CVE-2023-5869 の件と似ていますが、本障害では配列は空で終わるので無害です。

一部のコードパスでは、非決定的な照合順序の使用において「ERROR: pg_strnxfrm() returned unexpected result」のエラーが発生する可能性がありました。

TOASTテーブルを持つシステムカタログにインプレース更新を行う場合に問題が発生します。該当するのは pg_database だけです。pg_database の情報を使う SQL (例えば GRANT .. ON DATABASE .. など) で古い情報が使われてしまう可能性がありました。

対象の列が更新不能である場合、その旨のエラーを出すべきですが、検査が漏れており、後のコードから「ERROR: attribute number N not found in view targetlist」という意味が理解しにくいエラーメッセージが生じていました。

（修正前の動作例）
db1=# CREATE TABLE t19 (id int);
db1=# CREATE VIEW v19 AS SELECT id, id * 2 AS c_2id FROM t19;
db1=# INSERT INTO v19 VALUES (1, 2);
ERROR:  cannot insert into column "c_2id" of view "v19"
DETAIL:  View columns that are not columns of their base relation are not updatable.
db1=# INSERT INTO v19 VALUES (1, DEFAULT);
ERROR:  attribute number 2 not found in view targetlist

これまで、WITH RECURSIVE の問い合わせで UNION の 2つ目の枝に自己参照が無いけれども ORDER BY のような別の場所に自己参照がある場合に、役に立たない内部的なエラーメッセージが出ていました。

（修正前の動作例）
db1=# WITH RECURSIVE x(n) AS (WITH x1 AS (SELECT 1 FROM x)
        SELECT 0 UNION SELECT * FROM x1) SELECT * FROM x;
ERROR:  missing recursive reference
（→ 修正後のメッセージは以下）
ERROR:  recursive reference to query "x" must not appear within a subquery

db1=# WITH RECURSIVE x(n) AS (
        SELECT 0 UNION SELECT 1 ORDER BY (SELECT n FROM x)) SELECT * FROM x;
ERROR:  missing recursive reference
（→ 修正後のメッセージは以下）
ERROR:  ORDER BY in a recursive query is not implemented

このコマンドは（通常は serial型の列により）テーブルに紐づくシーケンスについても LOGGED と UNLOGGED の切り替えを行いますが、シーケンスについてロック取得されていませんでした。このため、同時に実行される nextval() の結果が失われる可能性がありました。

トランザクションで遅延された AFTERトリガを発生させる操作を実行して、その後、トリガ実行に至る前にそのトリガが DROP された場合に該当します。これまでは「ERROR: could not find trigger NNNN」エラーを出していましたが、動作が変更されました。この場合は何もしない方が良いと判断されました。

ある拡張が作成したテーブルの列単位権限を GRANT した場合に、関連する pg_init_privs のエントリが拡張を削除した後にも残っていました。これはテーブルの OID が再利用されない限りは無害です。pg_init_privs に残ったエントリは、OID が一致するテーブルの pg_dump 出力に影響を与える可能性があります。

問い合わせ（INSERT）が更新可能ビューを通してターゲットテーブルにON CONFLICT を用いたアクセスする場合、利用可能なインデックスがある場合でも、それが無いというエラーが生じていました。

（エラー発生例）
db1=# CREATE TABLE t24 (js jsonb);
db1=# CREATE UNIQUE INDEX ON t24 ((js ->> 'key'));
db1=# CREATE VIEW v24 AS SELECT * FROM t24;
db1=# INSERT INTO v24 VALUES ('{"key": "value"}')
        ON CONFLICT ((js ->> 'key')) DO NOTHING;
ERROR:  there is no unique or exclusion constraint matching the ON CONFLICT specification

権限チェックにより、通常は他セッションの一時テーブルの行を参照・更新することは防止されますが、ALTER TABLE で定義変更をすることは可能でした。永続テーブルを継承する一時テーブルを作ることで、スキーマ pg_temp_NNN を指定することなく、他セッション一時テーブルの ALTER TABLE を試みることができてしまいました。

（現象再現例）
db1=> CREATE TABLE t25(i int);
db1=> CREATE TEMP TABLE t25tt () INHERITS (t25);

（別セッションで実行）
db1=> ALTER TABLE t25 ADD c text;
ERROR:  could not open file "base/18077/18239": No such file or directory
　→ アサート有のビルドならアサート失敗／列追加に成功してしまう場合もある

（修正後のエラー）
ERROR:  cannot alter temporary tables of other sessions

このような CREATEコマンドは、統計情報の式の列参照で列番号を適切に調整できませんでした。その結果、無効な統計オブジェクトが作られて、後で問題が生じました。典型的には元テーブルが削除された列を持っていて、列番号の付け直しが必要になる場合です。

（障害発生例）
db1=# CREATE TABLE t26s (a text, b text, c text);
db1=# CREATE STATISTICS es26 ON (a || c) FROM t26s;
db1=# ALTER TABLE t26s DROP COLUMN b;
db1=# CREATE TABLE t26t (LIKE t26s INCLUDING STATISTICS);
db1=# \d t26t
ERROR:  invalid attnum 3 for relation "t26t"

一部の場合では、外側の問い合わせのある行で計算された集約結果が、後の行でそうすべきでないときに再利用されるおそれがありました。これは外側の問い合わせがハッシュ集約で実装された DISTINCT を用いているときだけ起きると見られていますが、他の場合もありえます。

本障害により誤った問い合わせ結果が生じます。

（誤動作例 - min も 1、2、3 となるのが正しい結果）
db1(5432)=# CREATE TABLE t27 (f1 int4);
db1(5432)=# INSERT INTO t27 VALUES (1),(2),(3);
db1(5432)=# SET enable_sort TO off;
db1(5432)=# SELECT f1, (SELECT DISTINCT min(t27in.f1) FROM t27 t27in
              WHERE t27in.f1 = t27out.f1) FROM t27 t27out;
 f1 | min
----+-----
  1 |   1
  2 |   1
  3 |   1
(3 rows)

バージョン 16.0 で整数リテラルがアンダースコアを含むことが可能になりました。この変更で「$1_234」などを単一トークンとして扱うようになりましたが、これは正しく機能しませんでした。位置パラメータのシンボルは $ とそれに続く数字のみに戻されました。

エラー状態は（エラー位置を示す文字列のために）JITコンパイルされたコードを持つ動的にロードされたモジュールへのポインタを含むことができます。一部のコードパスでモジュールはエラー報告が処理される前にモジュールがアンロードされる可能性があり、エラー位置を示す文字列にアクセスがあったとき、SIGSEGV がもたらされました。

報告されたエラーがそれだけでない限り、libxml2 からの「chunk is not well balanced」エラーを抑止するようになりました。これにより 2.13.x とそれ以前のバージョンとのエラー報告の一貫性を保ちます。以前のバージョンではこのメッセージは冗長であったり、完全に間違っていたりしたので、2.13.x では報告されるケースの数が大幅に減りました。

シャットダウン時のチェックポイント の WALレコードでスタンバイのリプレイを開始すると、プライマリで準備されているがまだコミットされていないトランザクションは、進行中であると正しく認識されます。しかし、サブトランザクション（セーブポイントまたは PL/pgSQL の例外ブロックで生じる）については考慮されず、中止されたものとして扱われていました。

これにより、準備されたトランザクションが後でコミットされた場合に、コミットされた内容が REPEATABLE READ 分離レベルの別トランザクションにおいて途中から参照可能になる、といった不整合が発生していました。

場合によっては、WALストリーム内のレプリケーションスロットの開始ポイントがトランザクション内のポイントに設定され、アサート失敗が発生したり、デコード結果が不正確になったりすることがありました。

同時にスロットの作成・削除を行うとタイミングによって現象が発生しました。アサートが有効なビルドではアサート失敗も発生します。

パーティションテーブル（親テーブル）が、列が追加されている等、物理的に異なる行タイプのパーティション（子テーブル）を持つとして、そのようなパーティションテーブルの変更をパブリッシュするときに、wal sender プロセスでメモリリークが生じました。

これらのイベントの処理関数では現在メモリコンテキストを TopMemoryContext に切り替える可能性があり、その結果、切り替え前に割り当てられたデータについて、セッション存続期間でのリークが発生しました。少なくとも、受信した問い合わせと Bind メッセージに付加されたパラメータのエンコード変換でリークが観察されました。

統計情報の共有メモリにアタッチされた新しいバックエンドプロセスは参照カウントを増加させましたが、終了時にカウントを減少させていませんでした。2^32 セッションが作られた後、参照カウントが 0 にオーバーフローして、その後のバックエンドプロセス起動が「ERROR: could not attach to ...」エラーで失敗する可能性がありました。

SLRUセグメントを削除しようとするプロセスは、checkpointerプロセスとデッドロックする可能性がありました。

Windowsは接続のリモート側が切断された後に FD_CLOSE イベントを1回だけ報告します。タイミングが悪いと、その報告を見逃し、さらに入力を期待して無期限に、または少なくともタイムアウトが経過するまで待機する可能性がありました。

結果としてクライアント側が切断したことの検知が遅れて、「FATAL: sorry, too many clients already」などが生じる原因となりました。

最後のバイトが不完全なマルチバイト文字で構成されている場合、入力バッファの末尾から数バイト離れる可能性がありました。通常は無害ですが、原理的にはクラッシュを引き起こす可能性がありました。

セッションチケットの受信が TLSセッション再開がサポートされていることを意味すると考えるクライアントで発生するおそれのある障害を、これにより回避できます。

これまでも無効にしていましたが、OpenSSL 1.1.1 以降の TLSv1.3 に対応した無効化の指定が必要でした。

参照された関数を削除して集約として再作成するなど、大がかりな変更を行った際に、「ERROR: unexpected plan node type ..」などの予期せぬエラーが発生する可能性がありました。

（障害動作例 - 単純なSQL関数を PL/pgSQL関数から呼び出す）
db1=# CREATE FUNCTION f41() RETURNS int LANGUAGE sql AS $$ SELECT 1 + 1 $$;
db1=# CREATE FUNCTION f41caller() RETURNS int LANGUAGE plpgsql AS $$
        DECLARE x int; BEGIN x := f41simple(); RETURN x; END $$;
db1=# SELECT f41caller();
 f41caller
-----------
         2
(1 row)

（単純な関数を作り直して同セッション内で再度実行するとエラーになる）
db1=# DROP FUNCTION f41;
db1=# CREATE FUNCTION f41() RETURNS SETOF int LANGUAGE sql AS
        $$ SELECT g FROM (VALUES (1),(2)) AS g (g) LIMIT 1; $$;
db1=# SELECT f41caller();
ERROR:  unexpected plan node type: 311
CONTEXT:  PL/pgSQL function f41caller() line 1 at assignment

PostgreSQL 16.x では整数リテラルにアンダースコアを含めることができますが、PL/pgSQL は「FOR i IN 1_001..1_003」ような文を正しく処理できていませんでした。

（エラー発生例 - 「1_001」と「..」の間に空白がない場合にエラーとなる）
db1=# CREATE FUNCTION test(cnt int) RETURNS int LANGUAGE plpgsql AS $$
      DECLARE i integer;
      BEGIN
        FOR i IN 1_001..1_005 LOOP
          cnt := cnt + 1;
        END LOOP;
        RETURN cnt;
     END; $$;
ERROR:  syntax error at or near "1_001."

AS句で異なる列定義リストを渡す関数内で、その関数の再帰的な呼び出しを行った場合、内部呼び出しによって外部呼び出しの返す行型を上書きしてしまうため、エラーが発生しました。

（障害発生例 - 内部で int型列のレコードを返す再帰呼び出しがある）
db1=# CREATE FUNCTION f43(t text) RETURNS record LANGUAGE plpython3u AS $$
      if t == "text":
          plpy.execute("SELECT * FROM f43('int') AS (a int)");
          return { "a": "x" }
      elif t == "int":
          return { "a": 1 }
      $$;

db1=# SELECT * FROM f43('text') AS (a text);
ERROR:  invalid input syntax for type integer: "x"
CONTEXT:  while creating return value
PL/Python function "f43"
→ 修正後は列名a、値「x」を持つレコードが返る

PL/Python のトリガーによって別のトリガーが呼び出された場合、内側のトリガー用に作成された TD辞書によって外側のトリガーの TD辞書が上書きされてしまっていました。

TD辞書はトリガとして PL/Python 関数を使用した場合に、関連する値を格納するために使われます。

これにより、クラッシュが生じたり、以前の Tclエラーを指す誤ったコンテキスト情報が出力されたりする可能性がありました。

マルチスレッドアプリケーションにおいて、OpenSSL から返るエラーメッセージがおかしくなる可能性がありました。

（以下のようにメッセージがエラーコード表示になってしまうケースが報告された）
FATAL:  could not load root certificate file "root_ca.crl": SSL error code 2147483650

pg_dump で --binary-upgrade オプションを指定した場合に該当します。通常、このオプションを使用するのは pg_upgrade コマンドだけです。

pg_restore の「-l」が「-n」や「-N」などの選択的なリストアのオプションと共に指定された場合、コメントなど依存しているオブジェクトが、実際にはダンプに含まれていてリストアされるものであっても、TOC エントリ一覧から省かれていました。

SQL言語の関数のエグゼキュータは、ユーティリティ命令（SELECT/INSERT/UPDATE/DELETE/MERGE 以外）に対して計算したクエリID を伝えそこなっていました。

リモートサーバが PostgreSQL 15 以降であって、リモートの単純ではないビューに対して作った外部テーブルを参照する場合に、本エラーが発生します。

リモートサーバはこの構文を実装していないか、ローカルサーバとは異なる解釈をするかもしれないため、あえてリモートサーバでの実行を試みることはないと判断されました。

本構文がサポートされたのは PostgreSQL 13.x 以降です。

maxOS バージョン 15 以降でのコンパイル失敗が修正されます。

この修正は 9.2.x から 11.x のリポジトリでも修正適用されています。

これらのビューは、アクセスするユーザに読み取り権限の無い列を伴う式の統計情報を隠していませんでした。most_common_vals などのビュー列でデータ露出が生じていました。潜在的な影響は完全には明らかになっていないため、安全性の観点から、これらのビューは関連するテーブルの所有者にしか表示されないものとなりました。

この修正では、新たに initdb で作成されたデータベースクラスタにしか修正の影響が及びません。既存のデータベースクラスタに対して適用するには、以下の手順が必要です。

インストール先 share ディレクトリ下の fix-CVE-2024-4317.sql を
スーパーユーザ（下記例では postgres）で各データベースに対して実行する。

  $ psql -U postgres -d 《DB名》 -f "fix-CVE-2024-4317.sql"

このとき template0 データベースも対象にする。
template0 に対して SQLスクリプトを実行するには、
以下のように一時的に接続を許可して行う。

  $ psql -U postgres -c "ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;"
  $ psql -U postgres -d template0 -f "fix-CVE-2024-4317.sql"
  $ psql -U postgres -c "ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;"

このような場合に、予期せぬデータ型の不一致のエラーか、奇妙な INSERT結果（誤った問い合わせ結果）が生じることがありました。

（エラー発生例：1行 INSERT では成功するものが 2行 INSERT で失敗する）
db1=# CREATE typ2 AS (e1 int, e2 text);
db1=# CREATE DOMAIN dom2 AS typ2;
db1=# CREATE TABLE t2 (c1 int, c2 dom2);
db1=# INSERT INTO t2 (c2.e1, c2.e2) VALUES (1, 'A');
db1=# INSERT INTO t2 (c2.e1, c2.e2) VALUES (2, 'B'), (3, 'C');
ERROR:  subfield "e1" is of type integer but expression is of type dom2

これにより特別なケースでの問題を回避します。「MERGE INTO t3 USING (SELECT 1) ON (true) WHEN MATCHED THEN DO NOTHING」のような形の問い合わせでアサート失敗が生じる場合が報告されました。仕様変更となりますが、実用的な MERGE文の動作に影響は無いと考えられます。

ターゲット行が 2行以上のソース行と結合する場合には、SQL標準に従って、エラーを出すようになりました。これまでの実装では同時更新を伴う場合に本条件を無視することがありました。

また、BEFOREトリガや VOLATILE の関数が問い合わせで使われていることで、ターゲット行が同トランザクションのコマンドで既に更新されていた場合に、誤解を招かないエラーメッセージを出すようになりました。

（新たに出るようになったエラーメッセージ）
ERROR:  tuple to be updated or deleted was already modified by an operation triggered by the current command
HINT:  Consider using an AFTER trigger instead of a BEFORE trigger to propagate changes to other rows.

「《NULL値》 IS NOT FALSE」のような条件に対して、予期せぬエラーや誤った問い合わせ結果が生じました。

（RANGE、HASHパーティションでは予期せぬエラーが発生）
db1=# CREATE TABLE t5 (b boolean, i int) PARTITION BY RANGE (b, i);
db1=# CREATE TABLE t5p PARTITION OF t5 FOR VALUES FROM (false, 0) TO (false, 1);
db1=# SELECT * FROM t5 WHERE b IS NOT true;
ERROR:  invalid strategy number 0

（LISTパーティションの場合、NULLのパーティションが読み飛ばされる）
db1=# CREATE TABLE t5l (b bool, i int) PARTITION BY LIST (b);
db1=# CREATE TABLE t5lp PARTITION OF t5l FOR VALUES IN (NULL);
db1=# INSERT INTO t5lp VALUES (NULL, 0);
db1=# SELECT * FROM t5l WHERE b IS NOT true;
 b | i
---+---
(0 rows)

通常のテーブルを新しいスキーマに移動すると、そのテーブルが所有するシーケンスも（インデックスと制約とともに）そのスキーマに移動されます。 しかし、外部テーブルではこのシーケンスの移動が見落とされていました。

CREATE UNLOGGED TABLE を使用すると、所有されているシーケンスもWAL出力されなくなります。 ALTER TABLE はこの点を考慮していなかったため、追加された IDENTITY列はWAL記録されたシーケンスが含まれることになりますが、これは無意味であると判断されました。

db1=# CREATE TABLE t(a int);
db1=# CREATE PUBLICATION p FOR TABLE t WHERE (a > 0);
db1=# ALTER TABLE t ALTER COLUMN a TYPE bigint;
(以前発生していたエラーメッセージ)
ERROR:  unexpected object depending on column: publication of table t in publication p
(改善されたエラーメッセージ)
ERROR:  cannot alter type of a column used by a publication WHERE clause
DETAIL:  publication of table t in publication p depends on column "a"

以前は、可視タプルを含まないヒープページはカウントされていませんでしたが、Bitmap Index Scan によって返されるすべてのページをカウントする方がより一貫性があると判断されました。

プランツリーの他の部分にある変数を参照する SubPlan のパラメータが適切に表示されないことがありました。EXPLAIN出力中に問い合わせに含まれない ctid列が出現する誤動作が報告されました。

一時テーブルを作成するセッションがテーブルを削除せずにクラッシュした場合、自動バキュームが最終的に孤児テーブルを削除しようとします。 ただし、同じ一時名前空間が割り当てられているセッションでも同様に削除しようとします。一時テーブルに依存関係（所有シーケンスなど）がある場合、これら 2つのクリーンアップ試行の間でデッドロックが発生する可能性がありました。

このデッドロックは「ERROR: deadlock detected ...」エラーで検出されます。

見落としにより、この動作モードではすべてのヒープページがダーティになり、過剰な I/O が発生していました。また、誤って設定された可視性マップビットもクリアされませんでした。

VACUUM によるリレーションごとの値からのデータベースごとの凍結XID値の計算が、別の VACUUM によるこれらの値の同時更新によって混乱する可能性がありました。

並列ワーカによって実行されたバッファアクセスが VERBOSEモードで報告される統計にカウントされませんでした。

PostgreSQL 16 より前のバージョンでは、生成された条件が外部結合の上（後）で評価されるべき時に、外部結合の下で評価される可能性があり、誤った問い合わせ結果が発生する可能性がありました。一部の SELECTアームの結合列に定数出力を持つ UNION ALL ツリーへの結合を検討する場合には、16.x を含む全バージョンに同様の危険性がありました。

これは PostgreSQL 16.1 で適用された修正（31番の項目）に似ていますが、本修正では並列プランに対して問題解決します。

非定数引数を使用した ntile() および count() の Run Condition の最適化を無効にするようになりました。これにより副問合せで発生する可能性のある誤動作が回避されます。誤動作で典型的には「ERROR: WindowFunc not found in subplan target lists」のようなエラーが生じます。

通常の集約関数がウィンドウ関数として使用されて、ウィンドウフレームの開始が UNBOUNDED PRECEDING として指定されている場合、そのフレームの先頭位置は移動できないため、特別な (そしてより高価な) 移動集計モードを使用する必要はありません。この最適化は当初から意図されていましたが、コーディングエラーのために働いていませんでした。

通常これはクラッシュまたは予期せぬエラーメッセージを引き起こします。

運用ビルドでは、解放されたデータは使用前に上書きされない可能性が高いため、このエラーは頻繁には問題を引き起こしませんでした。潜在的にはクラッシュを引き起こす可能性があります。

エラー発生時に「X」部分が誤って出力されていました。

この変更により、何千ものロールを持つインストレーションにおけるいくつかの操作で報告された性能問題（GRANT ROLE で数十秒かかる等）が解決されます。

このような関数呼び出しの出力列は、列名とデータ型を指定する AS句によって定義する必要があります。実際の関数の出力値がそれと一致しない場合、実行時にエラーになるはずです。

しかし、一部のコードパスでは実際の値が通常より早くに検査され、不一致のときに、奇妙なエラーが発行されたり、エラーにならなかったり、アサート失敗が発生したりする可能性がありました。

（修正前バージョンでは結果が返るが、列数不一致でエラーになるのが正しい）
db1=# WITH a(b) AS (VALUES (ROW(1,2,3)))
        SELECT * FROM a, coalesce(b) AS c(d int, e int);
    b    | d | e
---------+---+---
 (1,2,3) | 1 | 2
(1 row)

単一の複合型列を返す SQL言語で実装されたプロシージャでは、アサート失敗またはコアダンプが発生する可能性がありました。

（クラッシュ動作例）
db1=# CREATE TYPE typ AS (a INT, b INT);
db1=# CREATE PROCEDURE p_udt(OUT typ) LANGUAGE SQL AS $$ SELECT (1, 2); $$;
db1=# CALL p_udt(NULL);
server closed the connection unexpectedly

関数 date_bin(stride, source, origin) で、source のタイムスタンプが origin のタイムスタンプより前にあり、それらの差がすでに stride の正確な倍数になっている場合、コードは stride を誤って減算していました。誤った問い合わせ結果が発生します。

（誤動作例）
db1=# select date_bin('30 minutes'::interval, '2024-01-01 15:00:00'::timestamp, '2024-01-01 17:00:00'::timestamp);
      date_bin
---------------------
 2024-01-01 14:30:00

また、整数オーバーフローも検出するようになりました。いずれも誤った問い合わせ結果の原因となります。

timestamp型の範囲を越えていて「ERROR: timestamp out-of-range」を出すべき一部の場合で、ERROR ではなく誤った問い合わせ結果を返していました。

引数によって参照されるリレーションが同時に削除された場合、関数は NULL を返すべきところですが、エラーになっていました。

2^31 を超える過去のトランザクションID が最近のものとして誤認され、pg_xact_status() または txid_status() の誤動作につながる可能性がありました。

フリースペースマップ（空き領域マップ）は WAL に記録されないため、OS のクラッシュ、レプリカの昇格、PITR リストアなどのエッジケースで、「ERROR: could not read block」が発生する可能性がありました。

WaitEventSetWait は PostgreSQL の内部実装関数です。

実装内部の状態として、待機条件が設定されていない場合に発生します。実際の障害発生例は報告されていませんが、エラー処理で奇妙な動作やクラッシュが生じる可能性が考えられます。

以前は単なるアサーションチェックでしたが、通常の実行時エラーに昇格しました。また、テーブルにアクセスするユーザ定義関数を含む式インデックスを再作成するときに、より的確なエラーメッセージ「ERROR: cannot access index ... while it is being reindexed」が出ます。

（以前のエラー発生例）
db1=# CREATE TABLE t34(i int PRIMARY KEY);
db1=# CREATE FUNCTION f34(i int) RETURNS int IMMUTABLE LANGUAGE SQL
        AS $$ SELECT i FROM t34 WHERE i = $1 $$;
db1=# CREATE INDEX idx34 ON t34 ( f34(i) );
db1=# INSERT INTO t34 VALUES (1);
db1=# REINDEX INDEX idx34;
ERROR:  could not read block 0 in file "base/26295/26339": read only 0 of 8192 bytes
CONTEXT:  SQL function "f34" during startup

以前は、インデックスに物理的に格納されている値ではなく、その値へのポインタが呼び出し元に返されていました。これが valgrind でテストしたときに不適切なメモリアクセスとして検出されました。理論的にはクラッシュが発生する可能性がありますが、実際の発生は報告されません。

これにより誤った競合原因を報告する可能性がありました。

サブスクライバがどのテーブルを同期する必要があるかを特定している間に到着した無効化イベントが忘れられていて、新たに同期が必要なテーブルがタイムリーに処理されない可能性がありました。

理論的にはブロッキングモードのソケットで操作することも可能でしたが、長い間完全には機能していませんでした。後で誤動作するよりは接続開始時に失敗した方がよい判断されました。

OpenSSL によって、システムより報告されたエラーを PostgreSQL は、読み取り可能なものではなく、数値のエラーコードで報告していました。

マルチスレッドの libpq クライアントプログラムは、ネットワークルックアップの失敗後に、誤った、あるいは破損したエラーメッセージを受け取る可能性がありました。

GNU gettext の実装では同時呼び出しは問題ないようですが、Windows で利用可能なバージョンではそうではありません。

プログラムがプリプロセッサのコマンド行で定義されたマクロを再定義しようとした場合に発生します。

サーバはパラメータ名の大文字と小文字を区別せずに処理するため、このコードも同様に処理する必要があります。これにより、生成された postgresql.conf ファイルに冗長なエントリが追加されることを回避します。

この問題は「\;」で区切られたクエリ文字列内の、最後のクエリでないクエリのキャンセルの場合にのみ発生していました。

これにより Finder がそのようなファイルを作成するときの問題が回避されます。

この間違いにより、このようなコメントが PL/pgSQL CASE ステートメントの「WHEN」式の後に続く場合、解析エラーが発生していました。

（エラー発生例）
db1=# CREATE FUNCTION f50(p1 int) RETURNS text LANGUAGE plpgsql AS $$
      BEGIN
        CASE p1
        WHEN 1 -- comment before THEN
          THEN RETURN 'one';
        ELSE RETURN 'other';
        END CASE;
      END; $$;

db1=# SELECT f50(1);
ERROR:  syntax error at end of input
LINE 1: SELECT "__Case__Variable_2__" IN (1 -- comment before THEN)
                                                                   ^
QUERY:  SELECT "__Case__Variable_2__" IN (1 -- comment before THEN)
CONTEXT:  PL/pgSQL function f50(integer) line 3 at CASE

ヒープタプルやインデックスタプルの可変長データは、作成時に適用された圧縮パラメータに応じて、短いヘッダか長いヘッダを持つことができます。これらのケースで違いがある場合にエラーを出すのではなく、同等なものとして扱うようになりました。

（エラー例：論理的には同じ 2タプルがあり、ヘッダ長が 1バイトと 4バイトで異なる）
db1=# CREATE TABLE t51 (v text);
db1=# ALTER TABLE t51 ALTER COLUMN v SET STORAGE PLAIN;
db1=# INSERT INTO t51 VALUES ('x');
db1=# COPY t51 TO '/tmp/t51.dat';
db1=# COPY t51 FROM '/tmp/t51.dat';
db1=# CREATE INDEX t51_idx ON t51(v);
db1=# CREATE EXTENSION IF NOT EXISTS amcheck;
db1=# SELECT bt_index_check('t51_idx', true);
ERROR:  heap tuple (0,2) from table "t51" lacks matching index tuple within index "t51_idx"

これらの出力関数は、contrib/pageinspect でインデックスエントリを表示するためにのみ使用されるため、誤りが実際に問題になることはほとんどありません。

これは、定数発行サブクエリと「UNION ALL」が関係する場合に発生する可能性がありました。もちろん、定数による並べ替えは無意味ですが、リモートサーバーによって誤って解釈され、「ERROR: ORDER BY position N is not in select list」が発生する危険性もありました。

これは実用上は同じ結果になるはずです。しかし、「GMT」はサーバ内のハードウェアに組み込まれているコードによって認識されますが、「UTC」はタイムゾーンデータベースで検索されます。 そのため、リモートサーバのタイムゾーンデータベースにエントリが欠落しているという万が一の事態が発生した場合、古いコードでは失敗する可能性がありました。

これにより、クラッシュの可能性が回避されました。

（クラッシュ例: 変換対象の t2 が同コマンド内の外側で参照されている）
db1=# CREATE TABLE t1 (id int, v text);
db1=# CREATE TABLE t2 (id int, v text);
db1=# CREATE FUNCTION convert_tbl2view() RETURNS SETOF t1 LANGUAGE plpgsql AS
      $$ BEGIN EXECUTE
         'CREATE RULE "_RETURN" AS ON SELECT TO t2 DO INSTEAD SELECT * FROM t1';
         RETURN QUERY EXECUTE 'SELECT * FROM t1 LIMIT 0'; END; $$;
db1=# SELECT * FROM t2 UNION ALL SELECT * FROM convert_tbl2view();
server closed the connection unexpectedly