最上位レベル以外のテーブル参照にRLSが適用される場合、キャッシュされた実行計画が呼び出し元のロールに依存するものとしてマークされるようになりました。 (Nathan Bossart) §

問い合わせ内のCTE、サブクエリ、サブリンク、セキュリティ呼び出し元ビュー、または強制射影が行レベルセキュリティポリシーを持つテーブルを参照する場合、結果の実行計画がどのロールで実行しているかに依存する可能性があるとマークされていませんでした。 これにより、同じセッションで後に実行された問い合わせが間違った実行計画で実行され、本来非表示にする必要があった行が返されたり、返すべき行が非表示になったりする可能性がありました。

PostgreSQLプロジェクトは、本問題を報告してくれたWolfgang Waltherに感謝します。 (CVE-2024-10976)

libpqがSSLまたはGSSプロトコルのネゴシエーション中に受信したエラーメッセージを廃棄するように修正されました。 (Jacob Champion) §

暗号化ネゴシエーションが完了する前に受け取ったエラーメッセージは、実際のサーバの出力ではなく、中間者攻撃によって挿入された可能性があります。 これを報告すると、さまざまなセキュリティ上の危険が生じる可能性があります。 例えば、このメッセージによって問い合わせの結果を偽装して、不注意なユーザが正しい出力と勘違いする可能性があります。 最良の解決策は、このようなデータを破棄し、libpq自身の接続失敗の報告のみに頼ることです。

PostgreSQLプロジェクトは、本問題を報告してくれたJacob Championに感謝します。 (CVE-2024-10977)

SET SESSION AUTHORIZATIONとSET ROLEの間の意図しない相互作用が修正されました。 (Tom Lane) § §

標準SQLでは、SET SESSION AUTHORIZATIONが副作用としてSET ROLE NONEを実行することを義務付けています。 この実装には欠陥があり、2つの設定間に意図した以上の相互作用が発生していました。 特に、SET SESSION AUTHORIZATIONを実行したトランザクションをロールバックすると、以前の状態ではなかったとしてもROLEがNONEに戻ってしまうことがありました。そのため実効ユーザIDがトランザクションの前とは異なる場合がありました。 関数のSET句でsession_authorizationを一時的に設定しても、同様の影響がありました。 関連するバグとして、パラレルワーカーがcurrent_setting('role')を検査した場合、他の値を参照すべきときでもnoneと認識される問題がありました。

PostgreSQLプロジェクトは、本問題を報告してくれたTom Laneに感謝します。 (CVE-2024-10978)

信頼されたPL/Perlコードが環境変数を変更できないように修正されました。 (Andrew Dunstan, Noah Misch) § § §

PATHなどのプロセス環境変数を操作する機能は、攻撃者に任意のコードを実行する機会を与えます。 したがって、「信頼された」PLはそれを行う機能を提供してはなりません。 plperlは、%ENVを、変更の試みを警告で拒否する結びつけられたハッシュに置き換えるよう修正されました。 信頼されていないplperluは、環境を変更する機能を保持します。

PostgreSQLプロジェクトは、本問題を報告してくれたCoby Abramsに感謝します。 (CVE-2024-10979)

テーブルパーティションをアタッチまたはデタッチする際の、外部キーの制約のカタログ状態の更新が修正されました。 (Jehan-Guillaume de Rorthais, Tender Wang, Álvaro Herrera) § §

参照先テーブルがパーティションテーブルの場合、参照元テーブルがスタンドアローンの場合とパーティションの場合で、異なるカタログエントリが必要になります。 ATTACH/DETACH PARTITIONコマンドはこの変換を正しく実行できませんでした。 特に、DETACH後、スタンドアローンになったテーブルには、外部キー強制トリガが欠落するため、その結果、外部キー制約に違反する行がテーブルに含まれる可能性がありました。 その後の再ATTACHも、予期しないエラーで失敗する可能性がありました。

この問題を解決するには、スタンドアローンになったテーブルで問題のある制約ごとにALTER TABLE DROP CONSTRAINTを実行し、その後制約を再度追加します。 制約の再追加に失敗した場合は、誤ったデータが入り込んでいます。 参照元テーブルと参照先テーブル間の整合性を手動で再確立し、制約を再度追加する必要があります。

このクエリを使用して、破損した制約を識別し、それらを再作成するために必要なコマンドを作成することができます。

SELECT conrelid::pg_catalog.regclass AS "constrained table",
       conname AS constraint,
       confrelid::pg_catalog.regclass AS "references",
       pg_catalog.format('ALTER TABLE %s DROP CONSTRAINT %I;',
                         conrelid::pg_catalog.regclass, conname) AS "drop",
       pg_catalog.format('ALTER TABLE %s ADD CONSTRAINT %I %s;',
                         conrelid::pg_catalog.regclass, conname,
                         pg_catalog.pg_get_constraintdef(oid)) AS "add"
FROM pg_catalog.pg_constraint c
WHERE contype = 'f' AND conparentid = 0 AND
   (SELECT count(*) FROM pg_catalog.pg_constraint c2
    WHERE c2.conparentid = c.oid) <>
   (SELECT count(*) FROM pg_catalog.pg_inherits i
    WHERE (i.inhparent = c.conrelid OR i.inhparent = c.confrelid) AND
      EXISTS (SELECT 1 FROM pg_catalog.pg_partitioned_table
              WHERE partrelid = i.inhparent));

ADD CONSTRAINTの1つ以上のステップが失敗する可能性があるため、問い合わせの出力をファイルに保存してから、各ステップの実行を試行する必要があります。

LC_COLLATEがLC_CTYPEと異なる場合のCロケールのテストが修正されました。 (Jeff Davis) §

デフォルトの照合順序プロバイダとしてlibcを使用している場合、照合順序にCロケールが使用されているかどうかを確認するテストが、誤ってLC_COLLATEではなくLC_CTYPEをチェックしていました。 これらの設定が同じである一般的なケース、または両方がC（またはその別名であるPOSIX）でない場合は、この問題は発生しません。 ただし、LC_CTYPEがCで、LC_COLLATEが他のロケールである場合、問い合わせの応答が間違っていたり、文字列のインデックスが破損する可能性がありました。 このような設定を持つデータベースのユーザは、この更新をインストールした後に、影響を受けるインデックスを再作成する必要があります。 逆にLC_COLLATEがCでLC_CTYPEが他のロケールである場合は、パフォーマンスは低下しますが、実際のエラーは発生しません。

キー列の問い合わせの照合順序がパーティションキーの照合順序と一致しない場合は、パーティション同士の結合またはグループ化を使用しないようになりました。 (Jian He, Webbo Han) § §

このような計画は、間違った結果を生成する可能性がありました。

NOT NULL列のIS NULLテストをFALSE定数に変換した後のプランナ失敗が回避されました。 (Richard Guo) §

このバグは典型的には、「variable not found in subplan target lists」などのエラーを引き起こしました。

引数に特定の配列関連の構成が含まれるSQL関数をインライン化する際に、プランナがクラッシュする可能性が回避されました。 (Tom Lane, Nathan Bossart) §

MERGE ... WHEN NOT MATCHED BY SOURCEアクションで発生する可能性のある、間違った応答または「wrong varnullingrels」プランナエラーが修正されました。 (Dean Rasheed) § §

UNION ALLメンバ問い合わせの出力をソートする必要があり、ソート列が式である場合に発生する可能性のある「could not find pathkey item to sort」エラーが修正されました。 (Andrei Lepikhov, Tom Lane) §

B-treeのScalarArrayOpを使うインデックススキャンの稀な不具合が修正されました。 (Peter Geoghegan) §

この種のプランを持つスクロール可能なカーソルを開始点まで巻き戻した後、再び前方に実行した場合、誤った問い合わせ結果が生じる可能性がありました。

問い合わせがDO INSTEAD NOTIFYの規則によって書き換えられた場合に発生する、COPY (query) TO ...のアサーションエラーまたは紛らわしいエラーメッセージが修正されました。 (Tender Wang, Tom Lane) §

COPYのFORCE_NOT_NULLオプションとFORCE_NULLオプションの検証が修正されました。 (Joel Jacobson) §

一部の誤った使用法は、適切に拒否されるようになりました。

json_objectagg()呼び出しにVOLATILE関数が含まれている場合に発生するサーバクラッシュが修正されました。 (Amit Langote) §

パラレルハッシュ結合中の偏ったデータ検出が修正されました。 (Thomas Munro) §

1つのパーティションにタプルが蓄積されすぎたため、ハッシュ結合の内側を再分割した後、すべてのパーティションのタプルが同じ子パーティションに入ったかどうかを確認します。これは、すべてのタプルが同じハッシュ値を持つため、さらに再分割しても改善は問題にならないことを示唆しています。 このチェックは場合によっては誤動作し、無駄な再分割が繰り返され、最終的にはリソース不足のエラーになることがありました。

ALTER DATABASE SETを使用して、default_text_search_configなどのサーチパスベースの検索を必要とするパラメータを設定した場合のクラッシュが回避されました。 (Jeff Davis) §

パーティションテーブルに新しいインデックスを作成する際の、opclassesと照合順序の繰り返し検索が回避されました。 (Tom Lane) §

これは主に一部の検索が制限されたsearch_pathで実行されるため、CREATE INDEXコマンドがpg_catalog外のオブジェクトを参照した場合に予期せぬエラーが発生する問題がありました。

この修正により、親パーティションインデックスのコメントが子インデックスにコピーされるのも防止されます。

パーティションテーブルからCREATE TABLE ... USINGで指定された非組み込みアクセスメソッドへの欠落した依存性が追加されました。 (Michael Paquier) §

アクセスメソッドに依存するテーブルが存在する場合は、アクセスメソッドの削除はブロックされる必要がありますが、そうではなかっため、その後に異常な動作が発生する可能性がありました。 この修正は、この更新の後に作成されたパーティションテーブルの問題のみを防止することに注意してください。

非ASCII文字を含むロケール名が許可されなくなりました。 (Thomas Munro) §

このようなロケール名は他の場所では使用されていないため、これはWindowsだけの問題です。 このような名前がどのエンコーディングで表現されるのかが非常に不明確であるため、問題があります（ロケール自体が使用するエンコーディングを定義するため）。 最近のPostgreSQLリリースでは、その混乱によりWindowsランタイムライブラリのアボートが発生する可能性がありました。

新しいエラーメッセージに遭遇した場合は、Windows Locale Builderを使用してASCII文字のみの名前で新しい複製ロケールを作成するか、tr-TRのようなBCP 47準拠のロケール名の使用を検討してください。

シリアライザブルトランザクションをコミットする際の競合状態が修正されました。 (Heikki Linnakangas) §

最近コミットされたトランザクションの処理を誤って、アサーションエラーまたは「could not access status of transaction」エラーにつながる可能性がありました。

孤立した二相コミット(2PC)ファイルが生成されていたCOMMIT PREPAREDで競合条件が修正されました。 (wuchengwen) §

同時実行のPREPARE TRANSACTIONにより、COMMIT PREPAREDが完了したトランザクションのディスク上の二相状態ファイルが削除されない原因となる可能性がありました。 すぐに悪影響はありませんでしたが、その後のクラッシュとリカバリが「could not access status of transaction」というエラーで、サービス復旧には孤立したファイルを手動で削除する必要がありました。

VACUUM FULL中に無効なTOASTインデックスをスキップした後の無効なメモリアクセスが回避されました。 (Tender Wang) §

このコードパスでは、まだ再構築されていないインデックスを追跡しているリストが適切に更新されず、後でアサーションエラーやクラッシュが発生する危険性がありました。

「インプレース」でのカタログ更新が失われる可能性のある方法が修正されました。 (Noah Misch) § § § § § § §

通常の行更新では、トランザクションのロールバック可能性を維持するために行の新しいバージョンが書き込まれます。 ただし、一部のシステムカタログ更新は意図的にトランザクションではなく、行のインプレース更新で行われます。 これらのパッチは、インプレース更新の効果が失われる原因となる競合状態を修正します。 例えば、pg_class.relhasindexをtrueに設定し忘れると、新しいインデックスの更新が妨げられ、インデックスの破損を引き起こす可能性がありました。

リカバリの終了時にカタログキャッシュをリセットするようになりました。 (Noah Misch) §

これにより、カタログキャッシュからの古いデータを使用することで、インプレイスカタログ更新が失われるシナリオが回避されます。

割り込みを保留している間は、パラレルクエリを使用しないようになりました。 (Francesco Degrassi, Noah Misch, Tom Lane) § §

この状況は通常は発生しませんが、SQL言語関数をB-treeサポートとして使用するなどのテストシナリオでは発生する可能性があります（これは実稼働環境での使用には遅すぎます）。 このような状況が発生した場合、無期限の待機が発生しました。

pg_cursorsビューで未定義のポータルを無視するようになりました。 (Tom Lane) §

新しいカーソルの設定中に、このビューを検査するユーザ定義コードが呼び出される可能性があり、その場合NULLポインタ間接参照が発生します。 設定が不完全なカーソルを除外するようにビューを定義することでこの問題が回避されます。

列のデフォルト値の挿入を含むトランザクションのデコード中に、「unexpected table_index_fetch_tuple call during logical decoding」エラーが発生しなくなりました。 (Takeshi Ideriha, Hou Zhijie) § §

ロジカルデコーディングのメモリ使用量が削減されました。 (Masahiko Sawada) §

論理レプリケーション中に受信したタプルデータを格納するために、より小さいデフォルトブロックサイズを使用するようになりました。 これにより、メモリ不足の障害につながることもあると報告されている、長時間実行されるトランザクション処理中の深刻なメモリ浪費が削減されます。

PL/pgSQLのEXCEPTIONブロック内でCALL文の引数リストから呼び出されるSTABLE関数の動作が修正されました。 (Tom Lane) §

以前の四半期リリースでの同様の修正と同様に、今回のケースでは、このような関数に間違ったスナップショットが渡され、外部トランザクションの開始以降に変更された行の古い値を参照する可能性がありました。

libpqのkeepalives接続オプションを、他の整数値オプションと同様に解析するようになりました。 (Yuto Sasaki) §

ここで使用されたコーディングでは、他の場合とは異なり、オプション値の末尾の空白文字が拒否されていました。 これは、例えばecpgの使用時に問題となることが判明しました。

ecpglibが、不正なdatetime入力を解析する際に範囲外の読み取りをしないよう修正されました。 (Bruce Momjian, Pavel Nekrasov) §

定数配列の開始直前の位置を読み取ろうとする可能性がありました。 しかしながら、実世界での影響は最小限にとどまると思われます。

psqlのdescribeコマンドが9.4以前のサーバで再び動作するように修正されました。 (Tom Lane) §

ACL（権限）列の表示を含むコマンドは、非常に古いPostgreSQLサーバでこれらのバージョンには存在しない関数を使用していたため失敗していました。

psqlの\watchコマンドで1ミリ秒未満の間隔が指定された場合のハングアップが回避されました。 (Andrey Borodin, Michael Paquier) §

代わりに、間隔ゼロ（実行間の待ち時間なし）と同じように扱われます。

~/.pgpassでレプリケーションパスワードが見つからない問題が修正されました。 (Tom Lane) §

pg_basebackupとpg_receivewalは、-dまたは--dbnameスイッチが指定されていない場合、データベース名フィールドにreplicationを含む~/.pgpassのエントリとの一致に失敗していました。 その結果、予期しないパスワードプロンプトが表示されていました。

pg_combinebackupで、フルバックアップが格納されているディレクトリに増分バックアップファイルが存在する場合、エラーを発生するよう修正されました。 (Robert Haas) §

pg_combinebackupで、二重スラッシュを含むファイル名を作成しなくなりました。 (Robert Haas) §

これにより機能的な問題は発生しませんでしたが、重複したスラッシュがエラーメッセージに表示されるため、混乱が生じる可能性がありました。

vacuumdbおよびパラレルreindexdbにおいて、一時テーブルとインデックスのインデックス再構築を試みないようになりました。 (VaibhaveS, Michael Paquier, Fujii Masao, Nathan Bossart) § § §

他のセッションの一時テーブルのインデックス再構築は機能しませんが、一部のコードパスでそれらをスキップするチェックが欠落していたため、不要な障害が発生していました。

ARM64プラットフォームでLLVMが生成するコードの誤りが修正されました。 (Thomas Munro, Anthonin Bonnefoy) §

ARMプラットフォームでJITコンパイルを使用する場合、生成されたコードは32ビットを超える再配置距離をサポートできず、生成されたコードの配置ミスにより、大容量メモリシステムでサーバクラッシュが発生する可能性がありました。

time_tとして表現されるプロセス開始時刻がlong値に収まると想定していたいくつかの個所が修正されました。 (Max Johnson, Nathan Bossart) §

longが32ビットのプラットフォーム（特にWindows）では、このコーディングは2038年以降で失敗します。 ほとんどの失敗は表面的な問題にすぎませんが、特にpg_ctl startがハングする可能性がありました。

タイムゾーンデータファイルをtzdataリリース2024bに更新しました。 (Tom Lane) § §

このtzdataリリースでは、古いSystem-V互換性ゾーン名を変更して、対応する地理的ゾーンを複製します。 例えばPST8PDTはAmerica/Los_Angelesの別名になります。 目に見える主な結果は、標準化されたタイムゾーンが導入される前のタイムスタンプの場合、そのゾーンは指定された場所のローカル平均太陽時を表すと見なされることです。 例えばPST8PDTでは、timestamptzの入力値1801-01-01 00:00は、以前は1801-01-01 00:00:00-08としてレンダリングされていましたが、現在は1801-01-01 00:00:00-07:52:58としてレンダリングされます。

また、メキシコ、モンゴル、ポルトガルの歴史的修正がおこなわれています。 特に、Asia/Choibalsanは現在、独立したゾーンではなく、Asia/Ulaanbaatarの別名となっています。 これは主に、これらのゾーン間の違いが信頼できないデータに基づいていることが判明したためです。