これらのビューは、アクセスするユーザに読み取り権限の無い列を伴う式の統計情報を隠していませんでした。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

同時リフレッシュのある一段階が弱いセキュリティ制限のもとで実行されていました。マテリアライズドビューの所有者が、何らか説きつけて、スーパーユーザや他の高権限ユーザにそのビューの同時リフレッシュをさせた場合、REFRESH を実行したユーザの権限でコードを実行させることができました。

全てのユーザ定義コードはマテビュー所有者として実行されるように修正されました。これが期待される動作でした。

この誤りを使った権限奪取は PostgreSQL 16.x では実施できないことが知られていて、おそらく 16.x では実際には脆弱性が無いと見られます。(CVE-2024-0985)

多数の JITコンパイルの後にバックエンドプロセスがメモリ不足状態になることが報告されていました。

LATERAL参照を伴うまれな状況で、不正な実行プランが作られる可能性がありました。影響を受ける場合には、誤った問い合わせ結果が返る、「ERROR: variable not found in subplan target list」などの奇妙なエラーになる、あるいは、エグゼキュータでプロセスがクラッシュする可能性がありました。

サブクエリが、外部結合の下にあって、外部結合のスコープ外にあるものを LATERAL参照する出力列を持っているとき、誤った問い合わせ結果が生じる可能性がありました。外部結合により生じるべき出力列の NULL が、異なる値になる可能性がありました。

PlaceHolderVar はプランナの実装コードにおいて別のプランノード結果から値が充当される変数を意味します。

本誤りにより予期せぬエラー「ERROR: WindowFunc not found in subplan target lists」が生じるおそれがありました。

この誤りにより「ERROR: cache entry already complete」が生じるおそれがありました。

「ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2」といった予期せぬエラーが発生することがありました。

varnullingrels はプランナの実装コードにおける変数ノードの修飾情報の一つです。

パーティションテーブルに対して MERGE UPDATE 動作をするときに、パーティションキーを変更するために UPDATE が DELETE と INSERT に置き換えられる場合に「AFTER UPDATE ROW」トリガを発効しないようになりました。RLS 検査などの他の UPDATE 後のアクションも同様に行われなくなります。

これらのアクションは一般的には失敗します。このことは通常の UPDATE で実行しない理由であり、MERGE でも実行すべきではありません。

このようなトリガが NULL を返すことで更新を妨げようとした場合、MERGE がエラーやアサート失敗を引き起こしていました。

「ERROR: could not open file "base/16384/16393.1" (target block 3081245700): previous segment is only 1 blocks」というエラーが出るケースが報告されました。

更新中タプルが別セッションによって更新されて別ページに移動されたばかりの場合、バッファへの PINなしに新しいタプルバージョンからデータを取得しようとするタイミングがありました。これにより原理的には、新タプルの未更新列にガベージデータが表示される可能性がありました。

実際に問題が生じる可能性は低いと見られます。

上限値が大きすぎたために、予想ハッシュテーブルサイズが大きい場合に「ERROR: invalid DSA memory alloc request size ..」エラーが発生することがありました。

ディスク不足時にエラーが生じた後、アサート失敗が生じるケースが報告されました。

この誤りにより、エグゼキュータで「ERROR: attribute 1 of type record has wrong type」などのエラーが生じる可能性がありました。

（エラー発生例）
db1=# SELECT
        string_agg(DISTINCT 'a', ','),
        sum((SELECT sum(1) FROM (VALUES(1)) b(id) WHERE a.id = b.id))
        FROM unnest(array[1]) a(id);
ERROR:  attribute 1 of type record has wrong type
DETAIL:  Table has type text, but query expects integer.

（正しい応答）
 string_agg | sum
------------+-----
 a          |   1
(1 row)

この誤りはアサートを無効にした実運用むけビルドでは、何ら影響はありません。

孫テーブルが複数の中間の親テーブルを通して新たな列を継承した場合、「ERROR: tuple already updated by self」エラーが生じました。

これまでは「ERROR: tuple already updated by self」が発生していました。

これまでは「ERROR: tuple already updated by self」が発生していましたが、これからは重複した指定を無視してエラーを出さないようになります。

（これまでのエラー例）
db1=# CREATE ROLE u;
db1=# DROP ROLE u, u;
ERROR:  tuple already updated by self

ロック取得不足のため、DROP STATISTICS を ANALYZE と同時に実行した場合に、「ERROR: tuple concurrently deleted」が発生していました。

これらの場所では、関数のデフォルト引数に VOLATILE 関数が指定されているのを検出できなかったり、使われる具体的なデータ型について実際には IMMUTABLE であるのに多様関数を VOLATILE と判断したりする可能性がありました。

これにより GENERATED句を不適切に拒否または受け入れしたり、ALTER TABLE .. ADD COLUMN で定数デフォルト値の最適化を誤って適用したりする可能性がありました。

カタログタプルの行外フィールドは何であれ、カタログキャッシュに挿入する前に、TOAST展開されます。これはカタログキャッシュエントリを無効化するかもしれないデータベースアクセスと関わりますが、新たなエントリはまだキャッシュに存在していません。その結果、既に古くなったキャッシュエントリが作られて永続化するかもしれないという競合動作になります。これにより（例えば DDL の同時実行で稀に）予期せぬ振る舞いがもたらされました。

TOAST展開後にタプルの可視性を再チェックすることで修正されました。

「0 - INT64_MIN」の計算はオーバーフローエラーとなるべきで、大部分のプラットフォームではそうなっています。しかしながら、組み込みの整数オーバーフローが無く、128-bit整数も無いプラットフォームの場合、オーバーフローを検知できず、INT64_MIN の値を返していました。

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

interval型の値の掛け算と割り算で、「ERROR: interval out of range」を出すべき一部ケースで、ERROR ではなく誤った問い合わせ結果を返していました。

大きな scram_iterations（イテレーション回数が多い）場合に、本関数は時間を要します。本関数は例えば password_encryption が scram-sha-256 であるときに ALTER ROLE ... PASSWORD '...' でパスワード変更するときに使われます。本修正により本関数実行中に問い合わせのキャンセルが可能になりました。

一部のコードパスで、古い統計情報が返される可能性がありました。本修正は以下のビューの応答に影響があります。

 pg_stat_archiver
 pg_stat_bgwriter
 pg_stat_checkpointer
 pg_stat_io
 pg_stat_slru
 pg_stat_wal

これまで、該当の設定パラメータについて無効な値であっても error列に何も出力されませんでした。

(16.x での該当設定パラメータ)
 ignore_system_indexes
 jit_debugging_support
 jit_profiling_support
 log_connections
 log_disconnections
 post_auth_delay

これまではパーティションキーの対応する要素から、異なる照合順序を持つインデックスも受け入れていて、誤動作を引き起こす可能性がありました。

予期せぬ「ERROR: could not open relation with OID」が発生していました。

バッファへの（排他ロックではなく）共有ロックでこれを行おうとしていましたが、二つのプロセスが同時にクリーンアップを行おうとするとインデックス破損が生じる可能性がありました。

インデックスのルートページの分割が自身の挿入と同時に生じると、「ERROR: buffer NNNN is not owned by resource owner」になる可能性がありました。

このようなインデックスを使用しようとして、「ERROR: could not open file "pg_tblspc/0/PG_16_202307071/0/0": No such file or directory」といったエラーが生じる可能性がありました。

所有者権限が必要なラージオブジェクト操作（例えば GRANT や COMMENT）で、所有者ユーザであってもスーパーユーザでない限り、「ERROR: unrecognized class ID: 2613」といったエラーが出て失敗しました。

何もしない ALTER LARGE OBJECT OWNER コマンド（元の所有者を指定するなど）が、誤った class ID を PostAlterHook に渡していました。本フックを使っている拡張に混乱をもたらしていたと考えられます。

「shared/local」ラベルの数は実際には共有バッファだけを参照していました。本修正で、このラベルは「shared」に変更されました。

これまで、CREATE DATABASE の実行中や直後に OSクラッシュが生じた場合、リカバリに失敗したり、起動後にそのデータベースへの接続に失敗する可能性がありました。同様のタイミングでベースバックアップを取得した場合にも、そのバックアップを使用する時に似た問題が起きる可能性がありました。症状としては、データベースディレクトリや PG_VERSIONファイル、pg_filenode.mapファイルが欠損するか空になります。

リカバリの問題を診断するのに役立つ追加情報がマスタプロセスのログとして提供されます。具体的には以下のメッセージです。

LOG:  starting backup recovery with redo LSN XX/XXXXXXXX, checkpoint LSN XX/XXXXXXXX, on timeline ID NN
LOG:  restarting backup recovery with redo LSN XX/XXXXXXXX
LOG:  completed backup recovery with redo LSN XX/XXXXXXXX and end LSN XX/XXXXXXXX

実装においてサブトランザクションで startedInRecoveryフラグが正しく設定されていませんでした。これはデッドインデックスタプルの処理にのみ影響があります。この誤りにより、サブトランザクション中の問い合わせが返すべき（プライマリではデッドだがスタンバイでは未だ有効な）インデックスエントリを無視してしまう可能性があり、誤った問い合わせ結果が生じます。あるいは、未だプライマリではデッドになっていないインデックスエントリにデッドと早すぎる印付けをしてしまう可能性がありました。後者は深刻な結果になるか明らかではありませんが、想定された動作ではありません。

レプリケーション接続確立まで待つ間、walreceiver を SIGTERM に応答しないようにした変更を、旧に戻しました。以前の変更内容では、スタンバイ昇格が妨げられることがありました。

このバグは 64-bitプラットフォーム上で 32-bit ビルドした PostgreSQL を稼働させる場合を除き、顕在化しないと考えられます。

このデッドロックの一端はロック待ちと無関係であるため、デッドロックに陥ると自動では検出できず、（コマンドキャンセルやプロセス停止など）手動で介入しない限り永続的に止まってしまいます。

tablesync worker はロジカルレプリケーションのテーブル初期同期を行うものです。apply worker は変更差分の適用を行います。

新しい列にデフォルトの定数値を持つ ALTER TABLE ... ADD COLUMN ... は、既存のタプルの書き換えをせず、代わりにタプルの読み取りコードが正しいデフォルト値を挿入することを期待していました。

その後、そのテーブルでレプリケーションが開始された場合、pgoutput は正しいデフォルト値の代わりに NULL を送信し、サブスクライバで不正なレプリケーションを引き起こしていました。

このケースでは、不適切な形式の COPY コマンドが生成されていました。

これは、password_required=true のサブスクリプションがスーパーユーザを所有者として接続文字列にパスワードなしで作成されたけれども、その後に所有者が非スーパーユーザに変更されたケースを検出することを目的としています。

これまではパスワードファイルや PGPASSWORD環境変数でパスワードが供給されれば、接続文字列にパスワードの無いサブスクリプションを一般ユーザで利用可能でした。

CheckPWChallengeAuth は PostgreSQL実装内部の関数です。これまで一部ケースでこの場合をログ出力されるエラーとして扱っていました。これは意図したものではなく、psql のような一般的なクライアントで頻繁にある動作であるため、ログスパムの生成につながっていました。

また、この誤りは ClientAuthentication_hook を使用する拡張を混乱させたかもしれません。

「data」フィールドの使用に代えて BIO「app_data」フィールドを使用するようになりました。以前のバージョンでは問題ありませんでしたが、3.2 ではクラッシュや二重解放のエラーを引き起こしていました。

「LOG: could not accept SSL connection: Socket operation on non-socket」というエラーが出てSSL接続に失敗するケースが報告されました。

以前の実装では、errno が設定されていない場合、報告されたエラーの原因は EOF の読み込みだと決めつけていました。 これにより「could not accept SSL connection: Success」のような奇妙なエラー報告が稀に発生していました。

外部テーブルから構成されたパーティションテーブルへの問い合わせなどで、非同期実行が使われたときに ERROR を出す場合に、該当している可能性があります。

以前は、関数本体にセミコロンが含まれているため、構文エラーとなっていました。

（本マイナーバージョンから実行可能になった PL/pgSQL の例）
db1=# DO LANGUAGE plpgsql $$
      BEGIN
        CREATE FUNCTION f1() RETURNS int
          BEGIN ATOMIC
            SELECT 1;
          END;
        END $$;

（以前は以下のようなエラーになった）
ERROR:  syntax error at end of input
LINE 5:             SELECT 1;

クエリの問題以外の理由 (接続が失われた場合など) でエラーが返された場合、パイプラインの状態が同期しなくなる可能性があります。これにより、呼び出し側のアプリケーションでビジーループが発生する可能性がありました。

パイプラインモードでも、引き続き PQflush() を呼び出す必要がある場合がありますが、この変更により一部の不整合が解消されます。

ノンブロッキングモードで GSSAPI 暗号化を使用すると、libpq が「GSSAPI caller failed to retransmit all data needing to be retried」というエラーを出して、サーバへのデータ送出に失敗することがありました。

initdb は V16以前は postgresql.conf の「lc_...」パラメータのコメントを常に解除していて、本マイナーバージョンアップで再び元の動作に戻されました。16.0 の変更により、initdb の --no-locale オプションがlc_messages に意図した効果を及ぼさなくなっていました。

以前は、コマンドがこれらのプロパティを設定するためダンプに含まれていましたが、これらのプロパティは拡張機能の内部事項として考慮される必要があるため、全く誤った動作でした。さらに、復元するユーザにはそれらを設定するための十分な権限がない可能性があり、（RLSポリシーをダンプするにはテーブルのロックを取得する必要があるため）ダンプするユーザにもそれらをダンプするための十分な権限がない可能性がありました。

典型的には「--exclude-table」などの指定で一部テーブルを除外したときに、除外したテーブルの拡張統計オブジェクトも除外するということです。これはインデックスなどの他の依存オブジェクトの動作に準拠します。

以前は、\startpipeline コマンドに一致する\endpipeline がない場合、pgbench は奇妙な動作をしていました。これは、pgbench が適切に処理する必要があるケースというよりは、スクリプトのミスのように見えるため、エラーを投げるようになりました。

false_positive_rate パラメータに最大値を指定したときに、アサート失敗が生じる動作が報告されました。

「ERROR: could not open file "....": No such file or directory」といったエラーが生じる動作が報告されました。

「ERROR: could not open file "....": No such file or directory」といったエラーが生じる動作が報告されました。

cmd.exe 経由で子プロセスを起動するときは、/D フラグを渡して、レジストリで指定された自動実行コマンドが実行されないようになりました。これにより予想外の副作用が回避できます。

この変更により、pg_wchar.h で「include 」を行う必要がなくなりました。一部のサードパーティコードで問題が発生していました。

PostgreSQL のビルドで選択されるコンパイラオプションは、Python のヘッダファイルの最新バージョンに含まれる構造体に関する警告を引き起こしました。gcc を使用する場合、プラグマを使用してこれらの警告を抑制するようになります。

グリーンランド、カザフスタン、パレスチナの夏時間法の変更、南極観測点のケーシーとボストークの修正、ベトナム、トロント、ミクロン島の歴史的修正が含まれます。

これにより、待ちリストが長い場合の O(N^2) の動作が修正されました。一部のユースケースでは、これによりスループットが大幅に向上します。

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

この修正は、トップレベルのトランザクションにはすでにカタログ変更が含まれているとマークされているけれども、そのサブトランザクションにはマークがついていない場合に対処します。

「ERROR: could not map filenode "..." to relation OID」という奇妙なエラーメッセージが出るケースが報告されました。