これまでこの検査が省略されており、テーブル所有者は任意のスキーマに拡張統計情報を作ることができて、予期せぬ名前衝突をもたらすおそれがありました。(CVE-2025-12817)

（バージョンアップ後は最後のuser1によるCREATE STATISTICSはエラーになる）
db1=# CREATE SCHEMA scm1;
db1=# CREATE TABLE public.tbl1 (id int, c1 text, c2 text);
db1=# ALTER TABLE public.tbl1 OWNER TO user1;
db1=# \c db1 user1
You are now connected to database "db1" as user "user1".
db1=> CREATE STATISTICS scm1.tbl1_c1_c2_stat ON c1, c2 FROM public.tbl1;

§ § § § § §

libpqのいくつかの個所で検査が欠けていました。巨大な入力に対して整数オーバーフローが起きると小さすぎるバッファ確保となって、バッファ終端を超えた書き出しを引き起こしました。(CVE-2025-12818)

§ § § § § §

（エラー発生例）
db1=# SELECT JSON_VALUE('{"a":"1","b":"2"}', '$.c' RETURNING text 
                        DEFAULT '0' COLLATE "C" ON EMPTY);
ERROR:  unrecognized node type: 31

§ § § §

ここでのグルーピングセットはGROUPING SETS、ROLLUP、CUBEを含みます。また、列指定の無いHAVING句とは「HAVING false」のような指定です。本障害で誤った問い合わせ結果が発生します。

（誤動作例：この場合の正しいSELECT結果は0行です）
db1=# CREATE TABLE t4 (id int, c1 int, c2 int);
db1=# INSERT INTO t4 VALUES (1,1,10), (2,2,20), (3,3,30), (4,4,40);
db1=# SELECT c1, c2, count(*) c FROM t4 GROUP BY CUBE(c1, c2) HAVING false;
 c1 | c2 | c
----+----+---
    |    | 0
(1 row)

§ §

この場合、結合で共有されるハッシュテーブルの更新で競合状態が生じるため、信頼できる動作が得られないと判断されました。

§

この誤りにより、劣ったプランが選択されたり、デバッグ用ビルドであればアサート失敗が発生しました。

§

本障害で予期せぬエラー「ERROR: no data returned for index-only scan」が発生しました。これは組み込みのインデックスタイプでは発生しませんが、一部の拡張で問題となりました。

§

インデックススキャンでのアサート失敗が報告されました。

§ § § § § §

§

これまでは、VACUUM時の自動サマライズが式インデックスで失敗して、プレースホルダのインデックスタプルが置き去りになって、BRINインデックスが時間とともに肥大化する原因となりました。

自動VACUUMで以下のエラーが発生するケースが報告されました。

ERROR:  cannot execute SQL without an outer snapshot or portal

§ § § § § § § § § § § §

この問題により、無限ループに陥ったり、不要なページを余計にスキャンしてしまう可能性がありました。

§ § § § § §

JITを使用しない場合はゼロ拡張ではなく符号拡張が行われるため、小さい整数データ型のDatumの表現がJIT使用時と一致しない場合がありました。多くの場合は問題になりませんが、プランノードがMemoizeの場合にエラー「ERROR: could not find memoization table entry」が発生する事例が確認されています。

§ § § § § §

§

これにより、ハッシュ結合が必要以上のメモリを消費したり、メモリの割り当てが非効率になることがありました。

§

テーブルにロックを取得する前に権限チェックが行われるようになりました。対象は以下の関数です。

pg_restore_relation_stats()
pg_clear_relation_stats()
pg_restore_attribute_stats()
pg_clear_attribute_stats()

§ §

パーティションとその親テーブルで列構成が物理的に一致していない場合に、クラッシュする可能性がありました。

§ § § §

EvalPlanQualによる再チェックは主としてREAD COMMITTED隔離レベルの問合せで使われる処理です。

§

本来は、代替プランが用意されていない場合、FDWまたはカスタムのアクセスメソッドを通常どおり呼び出す必要がありますが、それが行われずクラッシュすることがありました。

EvalPlanQualによる再チェックは主としてREAD COMMIMTTED隔離レベルの問合せで使われる処理です。

§ § § § § §

従来はALTER TABLE DETACH PARTITION CONCURRENTLYは、DETACHされた側のパーティションにパーティション制約のコピーを追加していました。この動作は、ハッシュパーティションの場合、DETACH後には関係がなくなったパーティションテーブルのOIDを保持したままとなるため問題がありました。具体的には、pg_dumpで取得したデータのリストアに失敗したり、パーティションテーブル削除後にDETACHしたテーブルへの操作が失敗するなどの問題が発生しました。

予期せぬ「ERROR: could not open relation with OID 16384」や「ERROR: could not open relation with OID 16990」というエラーの発生が報告されています。

次期メジャーバージョンであるPostgreSQL 19以降では、これらの制約コピーは一切行われないようにする予定ですが、18以前では、影響を最小化するためハッシュパーティションの場合のみ制約のコピーをスキップするよう修正されました。

§ § § § §

もともと生成列をパーティションキーに使うことは許可されていませんでしたが、行全体を参照させた場合など一部ケースでチェック漏れがあり、それらも禁止されるようになりました。

§ § § § § §

これまでは、そのような列を参照しようとすると、不正な動作か分かりにくいエラー「ERROR: unexpected virtual generated column reference」が発生していました。これは、生成列がまだ計算されていない段階でWHEREフィルタが実行されていたためです。

§ § § § § §

識別列はNOT NULLである必要がありますが、そのチェックがこの特殊なケースを見逃していました。修正後は以下のようにエラーメッセージが表示されるようになりました。

(18.1での実行例)
db1=# CREATE TABLE notnull_tbl (a int, b int);
db1=# INSERT INTO notnull_tbl VALUES (NULL, 1), (200, 2);
db1=# ALTER TABLE notnull_tbl ADD CONSTRAINT nn NOT NULL a NOT VALID;
ALTER TABLE
db1=# ALTER TABLE notnull_tbl ALTER COLUMN a ADD GENERATED ALWAYS AS IDENTITY;
ERROR:  incompatible NOT VALID constraint "nn" on relation "notnull_tbl"
HINT:  You might need to validate it using ALTER TABLE ... VALIDATE CONSTRAINT.

§

このバグは通常のビルドでは影響が生じないようですが、理論的には危険となり得るものです。

§ §

一時スキーマにある統計オブジェクトは、スキーマ修飾なしでは名前を指定できませんが、pg_statistics_obj_is_visible()はこの点を見落としており、状況に関わらずtrueを返す可能性がありました。その結果、psqlの\dXが誤ってpg_temp内の統計オブジェクトを一覧表示したり、pg_describe_object()などの関数が期待されるようにオブジェクト名をスキーマ修飾できないことがありました。

§ § § § § §

§ § § §

いずれかのスタンバイサーバのリプレイLSNが進まなくなった場合、write_lagおよびflush_lag列が、最終的に更新されなくなることがありました。

§ § § § § §

以前は、primary_slot_nameに無効なスロット名が設定された状態で設定ファイルをリロードすると、postmasterだけでなく、すべてのバックエンドプロセスがWARNINGを出力してしまい、大量の重複ログが生成される可能性がありました。

§ § § § § §

以前は、サーバ起動時に存在しないスロットを指定してもチェックされず、後でパラレルクエリ実行時にエラーとなる可能性がありました。

§ §

これまでは、ディスク容量不足などで書き込みに失敗すると、一時ファイルであるstate.tmpが残されてしまいました。これは、その後の状態書き込みをすべて妨げ、手動でのクリーンアップが必要になるという問題を引き起こしていました。

§ § § § § §

これまでは、同じシグナル番号がワーカのシャットダウンとロックタイムアウトの両方に使用されており、混乱を招いていました。

§ § §

タイムライン変更中、スタンバイサーバのWALレシーバは新しいWALストリーミングの開始点を待機するために稼働し続ける必要があります。ところが、以前はシャットダウンと再起動を繰り返していたため、pg_stat_wal_receiverのstatus列が正しく出力されないなどのレプリケーション状態を正しく把握できない問題が発生する可能性がありました。

§ § § § § §

論理デコーディング中にエラーが発生すると、同じセッション内での次回以降の論理デコーディング実行時にクラッシュが起こる可能性がありました。この問題は、pgoutputをpg_logical_slot_get_binary_changes()のようなSQL関数経由で呼び出した場合にのみ発生します。

§ § § §

以前は、スロットが競合状態から非競合状態に移行しても無効化が行われる場合があり、不要な無効化が発生していました。

§ § §

この修正により、データベース選択前のバックエンド起動初期に共有カタログへアクセスする際にエラーが発生してしまう問題が修正されました。PostgreSQLのコアコードで問題は確認されていませんが、一部の拡張では問題となっていました。

§

以前は、この処理でクラッシュするか、少なくとも役に立たないメッセージが表示される可能性がありました。ただし、実際にこのようなケースが報告されたことはないため、この問題が発生するのは極めて稀です。

§ § § § § §

§ § §

§ § § § § §

DISTINCTオプションがパーサで記録されず、コマンドが通常のGROUP BYと同じように扱われていました。今回の修正により、DISTINCTが正しく認識されるようになりました。

§ § § § §

以前のマイナーリリースで導入された修正によって、セッション存続期間メモリが解放されない問題がありました。今回の修正でメモリリークが回避されるようになりました。

§ § § § § §

以前は、GSSAPIを使ったデータの暗号化／復号処理で、接続ソケットのエラーを正しく認識できず、Windows上で接続に失敗する場合がありました。今回の修正により、Windows特有のエラー報告に対応し、接続が正しく行われるようになりました。

§ § § § § §

18より前のバージョンのサーバからのダンプで、そのような制約定義の出力が欠損していました。

§ §

これにより、他のオブジェクト種別と同様に、外部キー制約も一貫した順序で出力されるようになりました。これまでは制約名ではなくOID番号の順になっていました。

§ § § § § §

いくつかの箇所でエラーチェックが欠落または不正確であり、さらに、ビッグエンディアンのハードウェア環境下では移植性の問題が発生することもありました。

この問題は、ディレクトリ形式ダンプ内のTOCファイルを手動で圧縮した場合にのみ発生します。そのため、通常の利用ではほとんど遭遇しないはずです。

§ § § § § § § § § § §

pgbenchは仕様としてCOPYに対応していませんが、これまでエラー処理が完備されておらず、無限ループに陥っていました。

§ § § § § §

これまでは2回連続でPQgetResult呼び出しが失敗した場合、pgbenchが誤ったエラーメッセージを報告する可能性がありました。

§ § § § § §

§ § § §

テーブル等のオブジェクト数が多いときに影響があります。

§ §

これまで一部のコードパスで、割り込みを確認せずに長時間処理が続く可能性がありました。

§ § § § § §

pg_prewarm()関数は、プリウォーム対象のリレーションに対して「SELECT」権限を必要とします。しかし、インデックス自体にはSQL権限が存在しないため、非スーパーユーザーはインデックスをプリウォームできませんでした。これを解決するために、今後はインデックスが属するテーブルに対する「SELECT」権限を確認するようになりました。

§ § § § § § § § §

特に「WHERE x IN ($1 /*, ... */)」のようにカンマ区切りの値の列挙を短縮している場合に問題が発生しました。

§

すべてゼロのページは空き領域として数え、無効なインデックスページ（ページの特殊領域サイズチェックに基づいて判断される）は無視するようになりました。

これまでは、すべてゼロのページは、Btreeインデックスでは空き領域として数え、hashとGiSTインデックスではエラーが発生し、一貫性がありませんでした。また、無効なインデックスページではエラーが発生していました。

§ § § § § §

Cコンパイラによるメモリアクセスの並べ替えを防ぐために、メモリバリアとして__atomic_thread_fence()関数が利用できると想定されていましたが、Clangでは十分なバリアになりませんでした。

少なくともRISC-V、MIPS、LoongArchのマシンで誤ったコードが生成される可能性がありました。本修正でClangでも問題なく利用できる明示的なコンパイラバリアが追加されました。

§ § § § § §

これまで「make USE_PGXS=1 update-po」が正しく動作しませんでした。

§ § § § § §

これらの関数は、1つ以上のnull入力があっても、null以外の結果を返す場合があるので非STRICTです。これまでプランナはこれらの関数をSTRICTであると誤って分類してクエリ変換を行う可能性がありました。そのため、誤った問い合わせ結果が生じる可能性がありました。

§ §

「SIMILAR TO」パターンマッチング式からPOSIX形式の正規表現への変換について、直近前バージョンでの修正において特殊なケースについて不具合がありました。

不具合により、開き括弧の直後にエスケープ文字があり、エスケープシーケンスの直後に閉じ括弧がある場合（例：[\w]）、閉じ括弧が文字クラスの終了として認識されなくなっていました。

§ § § § §

このようなCTE参照は、外側のクエリの列参照のように動作する必要がありますが、それが考慮されておらず、プランナやエグゼキュータで不明瞭なエラーを引き起こしていました。

「ERROR: could not find CTE ...」が発生するケース、クラッシュするケース、アサート失敗するケースが報告されました。また、誤った問い合わせ結果が生じる場合もありました。

§ § § § §

§ § § § §

発生するケースは、パーティションを展開する際に最後の有効なパーティションが並行する別プロセスから同時に削除(DROP)された場合に限られます。

§ § §

GINインデックスは一致しないエントリを除くスキャン条件（例えば、tsqueryの「!term」句など）を処理できます。これまで、そのような条件がスキャン条件の配列の先頭にあると、そのような条件と通常の条件が混在するクエリが無限ループになることがありました。

§ § § § §

一部のコードパスで長時間割り込みを検査せずに実行される可能性がありました。

§ § § § §

この遺漏により、同時UPDATEでctid条件が再評価されない可能性があり、その時に選択されたプランタイプに応じて、UPDATEの振る舞いが変わる可能性がありました。

EvalPlanQual再チェックは主としてREAD COMMITTED隔離レベルの問い合わせで実行される内部処理です。ctidは現在の物理的なタプル位置をあらわすテーブルのシステム列です。

§ § § § § § § § §

is_temporaryはオブジェクトが一時オブジェクトであるかどうかを示すものです。一時テーブルに属している列のデフォルト値、トリガ、RLS ポリシーが削除された場合にもtrueを返すように修正されました。このような場合にこれまでfalseを返していました。

§ § § § § §

タプルのハッシュの計算で使われた全てのメモリが問合せ終了まで残り続けるメモリリークとなっていました。一例として、ハッシュされる値がTOAST展開を要求する時にこの不具合が発生すると考えられます。

§ § § § §

長時間実行されるスタンバイサーバでは、不要になったエントリを解放する処理がなかったため、これらのオブジェクトを保持するハッシュテーブルが大幅に肥大化する可能性がありました。

SMgrRelationはファイルハンドルを管理する実装コード内の構造体です。

§

新しいハッシュテーブルエントリの作成中にメモリ不足エラーが発生すると、壊れたエントリが残され、その後の他のセッションで予期せぬエラーやクラッシュが発生する可能性がありました。

§ § §

MERGE UPDATE実行時に、対象行に対して複数の同時更新が発生した場合、ロックとリトライの処理が対象タプルの最新バージョンを誤って識別し、誤った結果を返すことがありました。

§ § §

MERGEで更新または削除動作が必要になり、かつ更新または削除のターゲットテーブルが論理レプリケーションのパブリケーション対象である場合、そのテーブルにREPLICA IDENTITYが定義されている必要があります。これを必須としないと、レプリケーションが静かに中断される可能性があります。同様に、UPDATEオプション付きのINSERTでは、ターゲットテーブルが挿入または更新を発行するならばREPLICA IDENTITYが必須となります。

§ § § § § § § § § § § § §

§ § § § §

この発生確率の低い問題は、エラー「ERROR: unexpected duplicate for tablespace X, relfilenode Y」のような一時的なエラーとして発生していました。contrib/autoprewarmも影響を受けていました。この修正の副作用として、SQL関数のpg_filenode_relation()は一時テーブルを無視するようになりました。

§ § § § §

§ § § § §

既存のセットが要求したセマフォ数より少ない場合、これらのプラットフォームはコードが期待するEEXISTではなくEINVALを返すため、データベースの起動に失敗していました。

§ § § § §

charが符号付きとみなされるプラットフォームでは、出力に余計な\xffffffが含まれていました。

§ § § §

これらのオブジェクトタイプのラベルは、これまで除外されていました。

§ § § § §

他のオブジェクトタイプと同様に、これらのデータベースオブジェクトタイプの一貫した順序付けが確保されるようになりました。以前は順序が不安定であるほか、アサート失敗する可能性がありました。

§ § § § § § § § § § § § § § § §

以前は制約に対するコメントはドメインに依存させていました。このためpg_restoreを並列に実行した場合、 制約が復元される前にコメントの復元を試行してしまい、リストアが失敗する可能性がありました。

§ § § § §

--no-publicationsまたは--no-subscriptionsが指定されている場合、これらのオブジェクトに対するCOMMENTまたはSECURITY LABELコマンドは出力されません。

§ § § § § § § § § §

§ § § § §

makefileが長年おこなってきたことと一致させるため、両ファイルで-ftree-vectorizeを使用し、checksum.cでは-funroll-loopsを使用します。

§ § § §

CVE-2017-7484に対する修正およびその後の追加修正は、呼び出し元ユーザーに読み取り権限のない列の統計データに対して、情報漏洩の可能性がある関数が適用されるのを防ぐことを目的としていました。しかし、その対策には見落とされていた点が2つありました。

1つ目の見落としは、パーティションや継承階層に関するもので、テーブルに設定されたRLSポリシーが統計データへのアクセスを制限すべき状況で、実際には制限されていませんでした。

2つ目は、クエリがビューを介してテーブルにアクセスするケースです。この場合、ビューの所有者はビューの基になるテーブルの読み取り権限を持っていても、呼び出し元のユーザーがそのビューに対する権限を持っていないことがあります。これまでの実装では、ビューの所有者の権限がセキュリティチェックを通過させてしまい、その結果、呼び出し元ユーザーのビューに対する権限を確認する前に、基になるテーブルの統計情報に情報漏洩の可能性がある関数が適用されることがありました。この問題は、プランニングの開始時点でビューに対するセキュリティチェックを行うようにすることで修正されました。これにより、以前よりも早い段階で権限エラーが発生する可能性があります。(CVE-2025-8713)

§ § § § § §

ダンプ／リストア操作では通常、SQLコマンドがスーパーユーザーとして実行されるため、ターゲットのデータベース環境は、ソースサーバーを信頼している必要があります。しかしそれは、リストアを実行するためにpsqlを使うOS上のユーザーが、ソースサーバーを信頼しなければならないことを意味するわけではありません。ここでのリスクは、攻撃者がソースサーバー上でスーパーユーザー権限を得ていた場合に、psqlのメタコマンドとして解釈されるようなテキストを出力させることができる点です。これにより、ターゲットデータベースへのアクセスとは無関係に、リストアを実行しているユーザーのアカウントに対し、シェルレベルのアクセスが可能になる恐れがあります。

このような事態が発生しないことを確実にするため、psqlに\restrictコマンドを追加し、それ以降のメタコマンドの実行を禁止できるようにしました。また、pg_dumpがソースサーバーからのデータよりも前にこのコマンドを出力するようにしました。(CVE-2025-8714)

§ § § § § § § §

改行文字を含むオブジェクト名があると、出力スクリプト内に任意のSQLコマンドを挿入することが可能になってしまう問題がありました。（CVE-2025-8714の修正がなければ、psqlのメタコマンドをこの方法で注入することも可能でした。）この種の問題は、CVE-2012-0868によって過去に修正されていましたが、その後の開発によって、いくつかのケースが再び入り込んでしまっていました。(CVE-2025-8715)

§ § § § § §

この関数の結果は、64ビット環境では時々誤りが生じ、32ビット環境では大きく誤った値を返すことがありました。ただし、このロジックはあくまで値をどのように範囲へ統合するかを決定するために使われているだけなので、明確なエラーとして現れることはありませんでした。最悪の場合でも、インデックスの効率が悪くなり、サイズが肥大化する程度です。それでも、numeric_minmax_multi_ops演算子クラスを使用しているBRINインデックスについては再インデックスを行うことが推奨されます。

§ § § § §

libxml2の2.13系の初期リリースに存在したバグへの回避策として、10MBを超えるテキストチャンクを拒否するコードパスを使用していましたが、以前のコードではそのような制限はありませんでした。これら初期リリースは現在では実環境で使用されている可能性は低いため、以前のコードに戻しました。

§ § § § § § § § § § § §

MERGEがCTEの内部で実行され、かつ対象のテーブルにBEFORE ROWトリガが定義されている場合に、同時に別のUPDATEやDELETEによって対象行が変更されると、MERGEコマンドが失敗することがありました。具体的には、UPDATEの場合はクラッシュを引き起こし、DELETEの場合は誤ったアクションが実行される可能性がありました。

以下、DELETE実行で誤ったアクションが実行される実行例です。

db1=# SELECT * FROM mergetbl;
 id | num | val
----+-----+------
  1 |  50 | init
(1 row)

(セッション1で上記のデータをUPDATE) 
db1=# BEGIN;
db1=*# UPDATE mergetbl SET num = 150, val = 'updated1' WHERE id = 1;
NOTICE:  UPDATE: (1,50,init) -> (1,150,updated1)

(セッション2から、CTEの内部からMERGEを実行する)
db1=# BEGIN;
db1=*# WITH m AS (
  MERGE INTO mergetbl m
  USING (SELECT 1 as id) s
  ON s.id = m.id
  WHEN MATCHED AND num < 100 THEN
    DELETE
  WHEN MATCHED AND num < 200 THEN
    UPDATE SET val = 'updated2'
  RETURNING *
)
SELECT * FROM m;

(セッション1を閉じる)
db1=*# COMMIT;

(セッション2で以下が返る)
NOTICE:  DELETE: (1,150,updated1)
 id | id | num | val
----+----+-----+------
  1 |  1 |  50 | init
(1 row)
→セッション1でnum = 150にしているので、正しくはUPDATEアクションが実行されるべき

(17.6では正しいアクションが実行される)
NOTICE:  UPDATE: (1,150,updated1) (1,150,updated2)
 id | id | num |   val
----+----+-----+----------
  1 |  1 | 150 | updated2
(1 row)

§ §

継承の親テーブルへの挿入は、WITH CHECK OPTIONおよびRETURNINGアクションの処理に失敗することで、クラッシュを引き起こしたり、不正確なクエリ結果を生成したりする可能性がありました。

db1=# CREATE TABLE merge_parent (
  id int, value int);
db1=# CREATE TABLE merge_child () INHERITS (merge_parent);
db1=# CREATE VIEW merge_view WITH (security_barrier) AS
SELECT * FROM merge_parent WHERE value >= 0
WITH CHECK OPTION;

(17.5以前は、以下のようにエラーは返ってこず0行として返ってくる)
MERGE INTO merge_view tgt
USING (VALUES (2, -5)) AS src(id, value)
ON tgt.id = src.id
WHEN NOT MATCHED THEN
  INSERT (id, value) VALUES (src.id, src.value)
  RETURNING *;
 id | value | id | value
----+-------+----+-------
(0 rows)

MERGE 0

(17.6では以下のエラーが返ってくる)
ERROR:  new row violates check option for view "merge_view"
DETAIL:  Failing row contains (2, -5).

§ § §

遷移テーブルを伴う行レベルのトリガは、パーティションや継承の子テーブルでは許可されていません。なぜなら、継承ツリー全体に対する操作では、各子テーブルごとに個別の遷移テーブルを管理しなければならないためです。しかし、この問題は文レベルのトリガには当てはまりません。文レベルのトリガは親テーブルのものだけが実行されるからです。それにもかかわらず、既存のテーブルがパーティションや継承の子テーブルになれるかを判断するコードは、両方の種類のトリガを一律に拒否していました。

§ § § § § §

PostgreSQLでは、外部テーブルに対して遷移テーブル付きのトリガはサポートされていません。しかし、パーティションや継承の子テーブルが外部テーブルである場合については、これまで見落とされていました。親テーブルに遷移テーブル付きのトリガがあると、外部テーブルである子テーブルから誤った遷移タプルが収集されてしまうことがありました。このようなケースはサポートされていないため、明示的に禁止するようにしました。この修正により、このような場合は、エラー「ERROR: cannot collect transition tuplesfrom child foreign tables」が発生するようになりました。

以下に再現例を示します。

(パーティションの子テーブルが外部テーブルである場合)
db1=# \d
                  List of relations
 Schema |     Name     |       Type        |  Owner
--------+--------------+-------------------+----------
 public | foreigntable | foreign table     | postgres
 public | parenttable  | partitioned table | postgres
(2 rows)

db1=# ALTER TABLE parenttable ATTACH PARTITION foreigntable FOR VALUES IN ('AAA');

(parenttable に対してAFTER INSERT 文レベルトリガ作成)
db1=# CREATE FUNCTION trigger_func() RETURNS trigger AS $$
BEGIN
  RAISE NOTICE 'trigger fired';
  RETURN NULL;
END;
$$ LANGUAGE plpgsql;

db1=# CREATE TRIGGER parenttable_insert_trig
  AFTER INSERT ON parenttable
  REFERENCING NEW TABLE AS new_table
  FOR EACH STATEMENT
  EXECUTE PROCEDURE trigger_func();

db1=# INSERT INTO parenttable VALUES ('AAA', 100);
ERROR:  cannot collect transition tuples from child foreign tables

(17.5 で実行するとエラーは発生しない)
db1=# INSERT INTO parenttable VALUES ('AAA', 100);
NOTICE:  trigger fired
INSERT 0 1

§ § § § § §

以前は、ALTER DATABASEやALTER ROLE、ALTER SYSTEMを使って保存されたパラメータ設定について、そのパラメータが不明なパラメータであっても、予約済みのプレフィックスを持っていた場合、その設定を削除することができませんでした。このようなケースは、拡張がかつて使用していたパラメータが、拡張のアップグレードで削除された場合などに発生する可能性がありました。

§ § § §

レプリケーションのオリジンを削除する時に、サーバープロセスがカタログロックを一貫した順序で取得するようにして、デッドロックの可能性を防ぐようになりました。

§ § § § §

インデックスの自動生成名を決定する際、すでに有効なエントリとの競合と同様に、未コミットのエントリとの競合も回避するようになりました。これにより、他のトランザクションで並行してCREATE INDEXが実行されている場合に、まだインデックスの作成中であったり、作成は完了していてもトランザクションがコミットされていない場合に、同じインデックス名を誤って選んでしまう可能性を防げるようになりました。依然として競合が発生する可能性はありますが、これは新しいインデックスのパラメータを検証し、pg_classへの行挿入が完了するまでの短時間だけです。

§ § § § §

あるテーブルに対して指定されたTRUNCATE、INDEX_CLEANUPオプションが、他のテーブルにも誤って適用されてしまうことがありました。

§ § § § §

以前の最適化により、そインデックスのないテーブルでは空き領域マップのVACUUM処理がスキップされてしまうことがありました。

§ §

SIMILAR TOパターンマッチング式をPOSIX形式の正規表現に変換するコードは、角括弧 [] がネストされ得ることを考慮していませんでした。例として、[[:alpha:]%_]というパターンでは、%と_の文字がリテラルとして扱われるべきですが、コードはそれらをメタ文字として扱っていました。

(17.6では[[:digit:]%]で t が返る)
db=# SELECT '%' SIMILAR TO '[[:digit:]%]',
            '%' SIMILAR TO '[%[:digit:]]';
 ?column? | ?column?
----------+----------
 t        | t
(1 row)

(17.5では f が返る)
db=# SELECT '%' SIMILAR TO '[[:digit:]%]',
            '%' SIMILAR TO '[%[:digit:]]';
 ?column? | ?column?
----------+----------
 f        | t
(1 row)

[%_[:alpha:]]のように前に%_を記述した場合は、修正以前も期待どおりの結果が返ってきていました。

§ § § § § § § § § § § § § § § § §

単純でない式は括弧で囲む必要がありますが、型キャスト付きの値などを誤って単純な式と見なし、括弧で囲まず、構文として誤ったSQLを生成する可能性がありました。

(エラー発生例)
$ psql -c "CREATE VIEW v1 AS SELECT * FROM generate_series(1, 10) AS c1 ORDER BY c1 FETCH FIRST (5::bigint) ROWS WITH TIES;" db1
$ createdb db2
$ pg_dump db1 | psql db2
(省略)
ERROR:  syntax error at or near "::"
行 5:  FETCH FIRST (5)::bigint ROWS WITH TIES;
                      ^

shared_buffersの設定が非常に大きい場合、checkpointerプロセスがfsyncリクエストキューに1GBを越える領域を割り当てようとし、「invalid memory alloc request size」エラーが発生し、リトライを繰り返し、無限ループが発生していました。

§ § § § § § § § § § § §

複数ページにまたがるWALレコードの最初の部分を書き込んだ後にサーバがクラッシュした場合、ロジカルデコーティングではWALストリームから次ページのデータが到着するのを待機します。しかし、データが到着することはなく、無限に待機し続けていました。

§ § § § § §

pg_wait_eventsとpg_stat_activityで待機イベント名が異なっており、これらのビューを結合する監視問い合わせが機能しない可能性がありました。

§ §

引用符の付け方はロケールに依存していたため、異なる環境に移行する際に移植性の問題が発生する可能性がありました。(pg_dumpではこの問題の影響はありませんが、他のツールでは影響する可能性があります。)一貫性を確保するため、出力時に非ASCII文字を常に引用符で囲むようになりました。ただし、下位互換性を維持するため、入力時に非ASCII文字を引用符で囲む必要はありません。

§ § § § § §

このようなオプション名に明確な使用例はなく、許容すると「name=value」という内部形式で格納する際に曖昧さが発生するため、使用できないように修正されました。

§ § § § §

この問題は圧縮率の低い入力データのみで発生するようで、これまで検出されなかった可能性があります。

§ § § §

この問題は、マージ結合に伴うスキャンで、同じページに同時に挿入・削除されたエントリがある場合に発生する可能性があり、正しい行が取得できないことや不要なリソースが保持されることがありました。

§ § § § §

以前のマイナーリリースでプロセス間のキャッシュ無効化メッセージに正しく応答するように修正され、更新適用中に古いカタログを参照しないようになりました。しかし、その際に意図せずメッセージを再送信してしまい、メッセージ数が急増し、メモリ割り当てエラーが発生する可能性がありました。

§ § § § § §

sync_replication_slotsがtrue、かつ、wal_levelがlogical未満の場合、postmasterプロセスはエラーを報告し、停止していました。本来の意図は単にスロット同期を無効にするだけのため、エラーメッセージのレベルを下げ、postmasterプロセスが停止しないようになりました。

§ §

チェックポイント処理中にレプリケーションスロットのリスタートポイントが進行すると、不要になったWALセグメントの早まった削除がなされ、その後すぐにデータベースがクラッシュした場合、リカバリに失敗する可能性がありました。 WALセグメントをチェックポイント1サイクル分、追加で保持するよう修正されました。

§ § § § §

場合によっては、レプリケーションクライアントが永続的に保存したLSNよりも過去のLSNを確認し、再起動後に古いLSNを送信する可能性がありました。 クライアントが2つのポイント間のWALに対して何もする必要がないなら、これはバグとは言えません。ただし、データ重複を避けるため、そのWALを再送信すべきではありません。そのため、作成されたスロットに対しては常に最新の確認済みLSNを信頼するようになりました。

論理レプリケーションで予期せぬデータ重複コンフリクトが出る障害例が報告されました。

§ § § § §

場合によっては、論理レプリケーションランチャーが新しいワーカを起動する前に、設定されたwal_retrieve_retry_intervalよりもかなり長い時間スリープすることがありました。

§ §

これにより、進捗状況の報告が不正確になる可能性があり、非常に運が悪ければ、wal senderプロセスがクラッシュする可能性がありました。

§ § §

スタンバイサーバでのレプリケーションスロットの作成には、プライマリサーバでのアクティブなトランザクションが終了し、その後スタンバイサーバでリプレイされるまで待機する必要がある場合がありました。これは無期限の待機となる可能性があるため、操作をキャンセルできるようにすることが望ましいのですが、ループ内でクエリのキャンセルがチェックされていませんでした。

§ § § § §

以前は未リプレイでもフラッシュ済のデータを送信しようとしていました。そのためにスタンバイサーバのシャットダウンに際して、startupプロセスが停止してWALリプレイがそれ以上進まないために、論理wal senderが無限に待機することがありました。

§ §

§ § §

§ § § § §

§

これにより、アサート失敗が発生したり、エラー「ERROR: cannot fetch toast data without an active snapshot」が発生する可能性がありました。

§ § § § §

例えば、アサートを有効にした環境では以下のクエリを実行するとアサート失敗が発生していました。

(修正前のアサート失敗発生例)

=# CREATE TABLE t1(a int);
=# CREATE TABLE t2(b t1 CHECK ((b).a IS NOT NULL));
=# ALTER TABLE t1 ALTER COLUMN a TYPE numeric;

§ § § § § § § § § § §

このアサートは、空のプリペアドステートメントの実行などの特殊なケースで失敗していました。

§ § § § § §

XMLTABLE式では、列にNOT NULLを指定することが可能であり、これを表現するために、パーサーは内部的に「is_not_null」というオプション名を生成していました。しかし、パーサーはユーザーが任意のオプション名を指定できるようにもしているため、ユーザーが同名の「is_not_null」を明示的に使い、真偽値以外の値を割り当てた場合、内部の前提が崩れてアサートが失敗してしまう問題が発生していました。

今回の修正では、ユーザーが指定したオプション名が内部の予約名と衝突していないかをチェックし、衝突していた場合はエラーを出すようになりました。さらに、内部で使うオプション名を「__pg__is_not_null」に変更することで、ユーザー定義名との衝突リスクも低減されています。

§ § §

この機能は以前は利用可能でしたが、過去のバグ修正によって意図せず無効化されてしまっていました。

§ § § § § §

Pythonからのエラーを報告する際にメモリ不足が発生すると、Python オブジェクトの参照カウントを適切に減らす処理が失敗する可能性がありました。その結果、セッション全体にわたってメモリが解放されずに残存してしまう問題が起こることがありました。

§ § § § § § § § § §

これまではPQcancelCreate()が生成したキャンセル用のオブジェクトを実際に使用するとlibpq がセグメンテーション違反によりクラッシュする問題がありました。

§ §

これは仕様として文書化されていますが、バージョン10以降のlibpq ではユーザーがポートを指定しなかった場合にNULL を返すケースがありました。この挙動が仕様どおりに戻され、NULLを渡された場合には空文字列""を返すようになりました。 ただし、バージョン18以降では、コンパイル時に設定されたデフォルトのポート番号として、通常は5432が返されるようになります。

§ § § § § §

Active Directoryのグループに多数所属しているユーザーでは、より大きな認証パケットが必要ですが、16kBをパケットサイズの上限としていました。 この制限により、エラー 「GSSAPI context establishment error:The routine must be called again to complete its function: Unknownerror」などが発生し、接続が失敗するケースがありました。

§ § § § §

SSLまたはGSSAPIでの暗号化をノンブロッキングモードで使用している場合、エラー「SSL error: bad length」または、エラー「GSSAPI callerfailed to retransmit all data needing to be retried」というメッセージを出力し、処理が失敗することがありました。

§ § § § §

この問題は、接続名がNULLの接続と非NULL接続少なくとも2つの接続が存在する状況で発生する可能性がありました。

§ § § § § §

COPY FROM とCOPY TOで同じオプションが提示されていましたが、これからは FROMかTO かを区別して、適したオプションだけ提示するようになります。

§ § § § §

これはパイプラインモードを使用する場合の問題です。

§ § § §

サブスクライバのリカバリ中に処理された最後のトランザクションが、通常のレプリケーションが開始されたときに再送されてしまう可能性がありました。

§ §

§ §

これまで、制約を作成する前にそのコメントを付与するコマンドがあらわれる場合がありました。

§ § § § § §

pg_dumpは依存性に基づく並び替えをする前に、オブジェクトをその論理名でソートしますが、ルールや制約などいくつかのオブジェクト種別については、OIDでのソートが行なわれており、論理的に同じデータベースで異なる出力順になる可能性がありました。このため、ダンプ出力を比較してオブジェクト差異を調べることが難しくなっていました。

§ § § § § § § § § § § § § § § § §

キーワードとして次の空白文字までを解釈すべきところ、次にアルファベット、数字、アンダースコア以外の文字が現れるところまでを解釈していました。このため、「table_data」を誤って「table-data」と書いた場合にエラーにならずに「table」と解釈される、といった動作が生じていました。

§ §

（修正前のエラー発生例）
$ pg_restore -d db1 db1.d
pg_restore: error: could not open large object TOC file "db1.d/3210.dat" for input: No such file or directory

§

PostgreSQL 18 より前のバージョンでは、継承された列のNOT NULL制約を除去できました。しかしながら、これはリストア不能な定義をもたらし、pg_upgradeが失敗しました。このような場合をpg_upgradeが事前検査で検出できるようになりました。

§ § § § § § § § § § § § § § § § § § § § § § § § § § § §

これまではデフォルトの -1 であることが必要でした。

§ §

§ § § § § §

§ § §

新たな接続オブジェクトを作るときにout of memoryエラーを起こした場合に、オープンされたリモートサーバへの接続がローカルサーバへのセッションが終了するまでの間、リークして、リモートサーバ上でアイドルセッションが残りました。

§ § § § §

これまではshared_buffersがおよそ5000万ページ（400GB）を超えるとき、自動プレウォームでメモリ割り当てエラーが発生して動作しませんでした。

§ § § § §

ストレージを持たないビューなどのリレーションに対してpg_prewarm()を実行すると、アサート付きビルドでは失敗していました。非アサートビルド時では実害はありませんでしたが、このようなケースをエラーとして拒否するよう修正されました。

§

(欠番が発生する例)
=# SELECT WHERE '1' IN ('2'::int, '3'::int::text);
=# SELECT query from pg_stat_statements WHERE query LIKE '%SELECT WHERE%';
                            query
--------------------------------------------------------------
 SELECT WHERE $1 IN ($3::int, $4::int::text)
(1 row)

§ § § § §

DirectModifyメソッドの呼び出しの途中でクエリが失敗した場合に、リモート側の更新コマンドの結果を保持するPGresultがセッション終了まで解放されないメモリリークが発生していました。これはRETURNING句でデータを処理する際に起こる可能性がありました。

なお、DirectModifyメソッドとは外部テーブルにUPDATE等のDMLコマンドを実行できるようにする内部実装コードです。

§ § § § §

これらのオプションを利用する一般的な理由は、ユーザがビルドしたライブラリをシステムが提供するライブラリより優先して使えるようにするためです。しかし、makefileが発行するコマンドのオプション順序が不適切だったため、一部の環境ではこの目的のために使えませんでした。

§ § § § § §

これらのWindows固有の関数をconfigureが正しく検出できなかったために利用されず、ハードウェア命令の利用可否を確認できずにCRC計算が本来より遅くなる問題がありました。ただし、Windowsでの商用環境向けのビルドでは、通常はAutoconfツールチェーンを使用しないため、この不具合の影響は限定的です。

§ § § § § §

Solarisでは、PAM認証のAPIが他のUNIX系プラットフォームと異なっており、その結果inconsistent pointerというコンパイラ警告が出力されていました。これまでは警告であるため対応されていませんでしたが、GCC 14以降では警告ではなくデフォルトでエラー扱いとなるため、修正されました。

§ § § § § §

GNU Hurdでは、他のUnix系OSで一般的に定義されているIOV_MAXやO_RDONLYが存在しない点が考慮されていませんでした。IOV_MAXが未定義の場合には16とみなす旧来の処理を復活させるなど、GNU Hurd環境に対応する修正が行われました。

§ § § § § § § § §

これにより一部のプラットフォームでのコンパイル失敗が回避されました。

§ § § § § §

§ §

§ § § § § §

§ § § § § §

PostgreSQLのヘッダファイルは、C++で書かれた拡張からインクルードできるように、通常は「extern "C" { ... }」 で囲む必要がありますが、pg_locale.hではlibicuのヘッダを使用しているためにこれが失敗していました。libicuヘッダ内のC++専用の宣言を利用しないようにすることで修正されました。

C++で書かれた拡張でlibicuのC++ API を利用したい場合は、pg_locale.hより前にlibicuのヘッダをインクルードする必要があります。

§ § § § § §