PostgreSQL 17 – SRA OSS Tech Blog

PostgreSQL 17.11 に関する技術情報

データベース技術グループ — Tue, 01 Sep 2026 04:34:01 +0000

このリリースは 17.10 からの修正リリース（2026年 8月 13日リリース）です。
17.X からのアップデートではダンプ、リストアは不要です。

しかしながら、最初の 3項目のセキュリティ修正は、設定の修正やデータのクリーンアップが必要となるかもしれません。また、以下に記載の修正項目に該当する GiSTインデックスがある場合には、インデックス再構築が必要となります。

さらに、17.6 よりも前のバージョンからアップデートする場合には、17.6のリリース情報も参照してください。

PostgreSQL 17.10 から 17.11 への変更点

18.6, 17.11, 16.15, 15.19, 14.24 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。

ロジカルデコーディングの出力プラグインが厳格化されました。新たな設定パラメータoutput_plugin_librariesでの指定が必要となりました。(CVE-2026-6471) (Jacob Champion) (18)(17)(16)(15)(14)

これまでは、レプリケーションユーザがロジカルデコーディングむけに任意のライブラリを選ぶことができて（プラグイン名になどフルパス指定も可能）、さまざまな攻撃が可能でした。仕組みを変えずにこれを防げるようにするため、許可された出力プラグインのホワイトリストが導入されました。

PostgreSQL本体同梱のpgoutput（ロジカルレプリケーション用）とtest_decoding（単純なテキスト書き出し用）がデフォルトでoutput_plugin_librariesに含まれます。

加えて、pg_upgrade --checkで、新クラスタのoutput_plugin_librariesが旧クラスタ（バージョン 17.x 以降）のレプリケーションスロットで使っているプラグインライブラリを許可していない場合、失敗するようになりました。

§ § § § § § § § §

contrib/pgcryptoのPGP暗号化がサポートされない暗号化方式を検出するように、修正されました。(CVE-2026-14663) (Daniel Gustafsson) (18)(17)(16)(15)(14)

これまでは、OpenSSLが要求された暗号化方式を（例えば、FIPSモードであるため、あるいは、古いプロバイダがロードされていないために）拒否した場合に、pgcryptoはその失敗を知らせず、プレーンテキストを含む暗号化されないブロックに単にXORを適用していて、その「暗号化」は容易に解読可能でした。これは典型的には非推奨や非FIPSの暗号化アルゴリズム（cipher-algoオプション指定が blowfish/bf, twofish, cast5, 3des などの場合）で発生します。

これからはデフォルトでは、OpenSSLでサポートされない方式でのPGP暗号化がエラーになり、これまでの動作により不適切に暗号化されたメッセージの復号もエラーになります。pgp_pub_decrypt()関数、pgp_sym_decrypt()関数などのオプション引数の新たなオプションignore_cipher_failureに1を指定して実行すると、従来通りの振る舞いに戻ります。

前述の理由で不適切に暗号化されたメッセージを、'ignore-cipher-failure=1'オプションを指定して復号する場合には、OpenSSLの動作がそのメッセージを作成したときと同じでなければなりません。サポートされない暗号化方式が異なっている場合にはうまくいきません。

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

psqlがスクリプト化された「COPY ... FROM STDIN」コマンドに続くインラインデータを、COPY開始時のエラーであっても、読み飛ばすように修正されました。(CVE-2026-6464) (Tom Lane) (18)(17)(16)(15)(14)

これまでは「COPY」コマンドが行の読み込みを始める前に（例えば、対象のテーブルが無い、などで）エラーを起こした場合、psqlはこのことを認識できず、続くインラインデータを読んでSQLとして処理しました。これは良くて誤りであり、悪くするとSQLインジェクションを起こします。

これまでも、COPY開始処理が完了してサーバが「PGRES_COPY_IN」を返した後であれば、途中の行読み込みでエラーを起こしても、残りを読み飛ばすように動作していました。

本修正が実運用SQLスクリプトに影響を及ぼすことは無いと考えられますが、テスト用スクリプトでは意図的に「COPY ... FROM STDIN」コマンドが失敗するように作られている場合があります。そのような場合には各コマンドの後に「\.」というデータ区切り行を追加する必要があります。さもないと、読み飛ばす行が多すぎる結果になるかもしれません。

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

EXECUTEやFETCHを実行するポータルの出力行型についてクロスチェックを行うようになりました。(CVE-2026-16239) (Robert Haas) (18)(17)(16)(15)(14)

EXECUTEとFETCHは2つのポータルを使います。外側の1つはそのステートメント自身のためで、内側の1つはクエリを代わって実行します。これまで、宣言された2つのポータルの行型を異なるものにできて、これを利用してサーバメモリ暴露や任意コード実行を引き起こせました。

§ § § § § §

to_char()で、長いタイムゾーン省略形によるバッファオーバーランが修正されました。(CVE-2026-14669) (Tom Lane) (18)(17)(16)(15)(14)

これは容易にバックエンドプロセスのクラッシュができて、任意コード実行をもたらす攻撃も報告されました。

§ § § § § §

正規表現によるマッチ、分割の関数で、バッファオーバーランが修正されました。(CVE-2026-14664) (Masahiko Sawada) (18)(17)(16)(15)(14)

不正な文字エンコーディングのデータを渡すと、変換バッファの終端を過ぎた位置に書き込みが行なわれる可能性がありました。regexp_match()、regexp_matches()、regexp_split_to_table()、regexp_split_to_array()の各関数の動作が修正されました。

§ § § § § §

ascii()関数が不正な入力に対して頑健になりました。(CVE-2026-18024) (Michael Paquier) (18)(17)(16)(15)(14)

不正な文字エンコーディングのデータが入力されることで、騙されて読むべきでない何バイトかを読んで返す可能性がありました。アサートが有効なビルドでは、アサート失敗も発生します。

§ § § § § §

pg_restore_attribute_stats()関数でのマルチ範囲型の処理が修正されました。(CVE-2026-16238) (OpenAI Security Research Team) (18)(17)(16)(15)(14)

pg_restore_attribute_stats()はプランナ統計情報のダンプ、リストアで使われる関数です。

pg_restore_attribute_stats()はマルチ範囲型を元となる範囲型と単純に同様に扱っていました。これは境界ヒストグラムについては有効でしたが、他の種類の統計情報に対しては誤っていました。

誤った統計情報のリストアにより、不適切なプラン選択による問合せ実行の遅延や潜在的なプランナ誤動作の可能性が考えられます。

§ § §

scalarineqsel()が、tid型と想定される定数を実際にそうであるか検査するようになりました。(CVE-2026-14668) (Tom Lane) (18)(17)(16)(15)(14)

この想定は組み込みの演算子については成り立ちますが、悪意で作られた演算子には通用せず、クラッシュやサーバメモリ暴露を引き起こします。

scalarineqsel()は選択率の見積を返すプランナの内部実装関数の1つです。

§ § § § § §

tsvector型とtsquery型の実装コードが（個々の要素、全体の長さの両面で）きわめて長い値に対して頑健になりました。(CVE-2026-14662) (Tom Lane) (18)(17)(16)(15)(14)

ドキュメントに記載されていた上限が、全てのコードパスで必ずしも強制されていませんでした。

本マイナーバージョンアップで、これまで許容されていたデータについて、以下のようなエラーが出るようになる可能性があり、仕様通りであるものの非互換変更ともいえます。

ERROR:  lexeme is too long for tsvector ...
ERROR:  string is too long for tsvector ...
ERROR:  word is too long to be indexed ...
ERROR:  tsquery is too large

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

「FUNC_MAX_ARGS」を超える関数引数を処理する必要がない、と誤って想定していた様々な箇所が修正されました。(CVE-2026-14679) (Tom Lane) (18)(17)(16)(15)(14)

特に集約関数について、実際の引数の数の上限は「FUNC_MAX_ARGS - 1」ですが、パーサ段階では制限しておらず、後の処理で問題を引き起こしました。潜在的にバッファオーバーランの可能性がありました。

「FUNC_MAX_ARGS」はビルド時指定の定数でデフォルト100です。

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

internal型を引数や戻り値とする関数のSQLからの呼び出しを拒否するようになりました。(CVE-2026-14680) (Tom Lane) (18)(17)(16)(15)(14)

拒否するための既存の仕組みはありましたが、不十分であったため、明示的な検査が追加されました。

また、いくつかの集約関数のcombine処理で入力がNULLである場合に正しくSQLとしてのNULLを返すように修正されました。

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

ALTER TABLEコマンドで再構築されたとき、拡張統計オブジェクトの所有者が保たれるようになりました。(CVE-2026-6469) (Masahiko Sawada) (18)(17)(16)(15)(14)

これまでは拡張統計情報の対象テーブルに、列の型を変えるなどのALTER TABLEコマンドを実行したロールが、拡張統計オブジェクトの所有者になっていましたが、これは不適切な動作と判断されました。

§ § § § § §

EXTRACT()関数呼び出しを逆パースするときに、必要であればフィールド名をクォートするようになりました。(CVE-2026-15741) (Nathan Bossart) (18)(17)(16)(15)(14)

パーサはEXTRACT()のフィールド名としてどのような文字列リテラルも受け付け、検証は実行時まで先送りされます。関数呼び出しを格納して、解析する場合（例えばpg_dumpのとき）、文字列本体が逐語的に吐き戻されて、SQLインジェクションが可能でした。

逆パースはダンプ出力やpsqlでの定義表示で行なわれる処理です。

§ § § § § §

これまで検査ができていなかった個所について、データ型に対する「USAGE」権限を検査するようになりました。(CVE-2026-6470) (Nathan Bossart) (18)(17)(16)(15)(14)

「CREATE TYPE AS RANGE」、「ALTER TABLE OF」、および、格納される式を作成するコマンド（式を伴うビューやチェック制約の定義など）で、検査が行なわれていませんでした。これらの欠落により、「USAGE」権限を持たないロールでもデータ型に依存するオブジェクトを作成できて、データ型の所有者が後でデータ型を変更できなくなる可能性がありました。

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

行単位セキュリティ(RLS)に対して、ロールに依存したキャッシュされたプランを、ロール変更後に無効化するようになりました。(CVE-2026-14666) (Ilya Staroverov, Shinya Kato, Nathan Bossart) (18)(17)(16)(15)(14)

ロールのメンバーシップや属性、データベース所有者の変更は、行単位セキュリティポリシーの振る舞いに影響がありますが、これまでは、キャッシュされた古い状態に基づくプランがそのまま使われていました。

§ § § § § §

直接のSSL接続の後のGSSEncRequestメッセージを拒否するようになりました。(CVE-2026-14681) (Michael Paquier) (18)(17)(16)(15)(14)

これまでサーバは、TLS暗号化接続が確立した後にもGSSAPI暗号化の要求を受け付けていました。これに成功すると、接続はTLS暗号化(SSL)を使っているけれども、pg_hba.confのルールとしてはGSS接続のように見えました。その結果、pg_hba.confでSSLを無効としていても、それを正しく強制できませんでした。

§ § §

モックのSCRAM認証シークレットがより本物らしくなりました。(CVE-2026-14672) (Nathan Bossart) (18)(17)(16)(15)(14)

存在しないロールやSCRAMシークレットを持たないロールに対して、SCRAMログインが試みられた場合、PostgreSQLはモックのシークレットを生成して認証のハンドシェイクをとにかく行ない、攻撃者にそのことが分からないようにします。しかしながら、モックが固定のイテレーションカウントで作られていたため、観測可能な応答の差異がありました。

本修正で、モックにもscram_iterations設定パラメータの値を使って、より実際に使われているシークレットに似せるようになりました。

§ § § §

ecpgアプリケーションでの範囲外書き込みが修正されました。サーバから不正なbytea型データを受け取ることで引き起こされます。(CVE-2026-16241) (Michael Paquier) (18)(17)(16)(15)(14)

ecpgはbytea型の値は「\x」で始まることを検査せずに想定していました。壊れているか悪意のサーバは2バイトよりも短い文字列を送ってくるかもしれず、そのためにアプリケーションでのメモリ上書きが発生しました。

§ § § § § §

psqlの「\unrestrict」コマンドの引数でバッククォート展開をしないようになりました。(CVE-2026-18408) (Nathan Bossart) (18)(17)(16)(15)(14)

\restrict と \unrestrict は 17.6、16.10、15.14、14.19バージョンでのCVE-2025-8714の修正で導入されましたが、その中で見落としがありました。悪意のサーバからの応答で出力されたダンプにより、リストアを実行するユーザに意図せぬシェルコマンド実行をさせること（シェルコマンドインジェクション）ができました。

§ § § § § §

pg_dumpにおいてpg_proc.protrftypesのエントリ数がFUNC_MAX_ARGSを超えないという前提が取り除かれました。(CVE-2026-19385) (Tom Lane) (18)(17)(16)(15)(14)

入力引数と出力引数の両方のエントリが存在する可能性があるため、この配列の長さがFUNC_MAX_ARGS（これは入力引数のみに制限するものです）を超えることは十分にあり得ます。仮にそうでは無いとしても、pg_dumpはサーバがpg_dumpと同じFUNC_MAX_ARGSの値でビルドされたと仮定することはできません。オーバーランが発生すると、pg_dump内部でのメモリ破壊を引き起こす可能性がありました。

pg_procシステムテーブルに関数定義が格納されて、protrftypes列にTRANSFORM句による変換のためのデータ型の配列が格納されます。FUNC_MAX_ARGSは実装内部の定数で、通常100です。

§ § § § § §

tieされたPerlの配列やハッシュに対して、PL/Perlが堅牢化されました。(CVE-2026-14670) (Tom Lane) (18)(17)(16)(15)(14)

通常のオブジェクトとは異なる挙動をするtieされたオブジェクトは、メモリの上書きや、破損した結果配列の生成につながる可能性があり、その結果、後で問題が発生する可能性が高い状況でした。

tieは、配列やハッシュなどの変数に対して操作用のメソッド群を実装したオブジェクトに結びつける Perl の機能です。

§ § § § § §

PL/PerlおよびPL/Tclにおけるメモリ割り当て計算時の整数オーバーフローが修正されました。(CVE-2026-14677) (Heikki Linnakangas) (18)(17)(16)(15)(14)

これはコードの異なる個所で発生していたCVE-2026-6473と同様の問題で、同じ方法で修正されました。

§ § § § § §

contrib/amcheckの関数がインデックス式を実行する前にsearch_pathを制限するようになりました。(CVE-2026-14673) (Noah Misch) (18)(17)(16)(15)(14)

amcheckはそれらのインデックス式をテーブル所有者の権限で実行するため、呼び出し元がsearch_pathに依存する関数を乗っ取り、テーブル所有者の権限で任意のコードを実行できてしまう恐れがありました。デフォルトでは、amcheck関数の呼び出しはスーパーユーザーにのみ許可されているため、これは脆弱性には当たりません。しかし、もしその権限が他のユーザに付与されていた場合、ドキュメントで示されているよりも大きな危険が生じることになります。

§ § § § § §

contrib/fuzzystrmatchのlevenshtein()およびlevenshtein_less_equal()関数における整数オーバーフローが修正されました。(CVE-2026-15742) (Nathan Bossart) (18)(17)(16)(15)(14)

これらの関数に大きなコスト値を渡すと整数オーバーフローが発生し、無意味な結果が生じたり、場合によっては境界外書き込みを引き起こしたりする可能性がありました。

§ § § § § §

contrib/pg_stat_statementsにおけるバッファオーバーランが修正されました。(CVE-2026-14676) (Alvaro Herrera) (18)(17)(16)(15)(14)

クエリの正規化処理において、正規化後の文字列が必要とするサイズが正確に考慮されていませんでした。

§ §

contrib/pg_trgmのGiST picksplit関数におけるデータ型エラーが修正されました。(CVE-2026-14678) (Heikki Linnakangas) (18)(17)(16)(15)(14)

このエラーによりバッファの末尾を超えた読み取りを引き起こし、通常は不適切な分割判断の原因となっており、運が悪ければクラッシュに至る可能性もありました。

§ § § § § §

contrib/refintのプランキャッシュが削除されるようになりました。(CVE-2026-14671) (Ayush Tiwari) (18)(17)(16)(15)(14)

このキャッシュの挙動にはいくつかの深刻なバグがありました。特に、check_foreign_key()がカスケードUPDATEクエリに新しいキー値を埋め込んでしまうため、キャッシュされたプランでは、本来使用すべきキー値ではなく、最初に必要とされたキー値が再利用されてしまう問題がありました。最も簡単な解決策は、これを削除することです。

§ § § § §

並列GINインデックスの構築時に、テーブルのpg_class.reltuples値が正しく更新されるようになりました。 (Jan Nidzwetzki, Tomas Vondra) (18)

並列ワーカーが処理した行数として初期化されていない値を報告する場合があり、その結果、reltuplesがInfinityやNaNといった不正な値になる可能性がありました。このような値が設定されると、その後のautovacuumやautoanalyze操作において、そのテーブルの処理が必要であると判断されなくなる可能性がありました。そうなると、この状態は自動的には解消されません。

reltuplesを正しい値にリセットするには、手動でANALYZEコマンドを実行するか、別のインデックスを作成する必要があります。 GINインデックスを持つテーブルがある場合は、reltuplesの値が妥当かどうかを確認することをお勧めします。以下のようなクエリが役立ちます。

SELECT DISTINCT t.oid::regclass, t.reltuples
FROM pg_class t
  JOIN pg_index i ON t.oid = i.indrelid
  JOIN pg_class ic ON i.indexrelid = ic.oid
WHERE t.relhasindex AND ic.relam = 2742;

§ §

非同期のAppendプランノードを再スキャンする際の、非同期読み取りの不適切な処理が修正されました。 (Alexander Korotkov, Gleb Kashkin, Etsuro Fujita) (18)(17)(16)(15)(14)

上位のプランノードがAppendの出力をすべて読み取る前にAppendを再スキャンする場合、外部サーバー（例えばpostgres_fdwなど）に対して送信済の未完了リクエストをすべて破棄する必要があります。サブプランのパラメータが変更された場合や、次回のスキャンでパーティションプルーニングによってサブプランが破棄される場合、この処理が正しく行われていませんでした。その結果、クエリ結果が不正になったり、無限ループに陥ったり、アサート失敗が発生したりする可能性がありました。

§ § § § § §

RANGEパーティションテーブルにおけるパーティションプルーニングの不具合が修正されました。 (David Rowley) (18)(17)(16)(15)(14)

特定のケースにおいて、本来対象とすべきDEFAULTパーティションがスキップされ、その結果、クエリの結果から行が欠落して、誤った問い合わせ結果となる恐れがありました。

§ § § § § §

結果リレーションのプルーニング後に、ModifyTableプランノード内の外部データラッパーの状態を正しく更新するようになりました。 (Ayush Tiwari, Rafia Sabih) (18)

以前は、実行時のパーティションプルーニングによって、対象のパーティションテーブルの一部のパーティションをスキャンする必要がないと判断された場合、そのテーブルに外部テーブルのパーティションが含まれていると、クラッシュや誤動作が発生する可能性がありました。

§ §

「BEFORE UPDATE」トリガーを持つテーブルに対して、「RETURNING OLD」を指定したUPDATE文で発生していた並行更新の処理漏れが修正されました。 (Dean Rasheed) (18)

対象行が並行して更新された場合、「READ COMMITTED」分離レベルでは、RETURNING句で返される「OLD」値はすべて、更新後の行の値を反映している必要があります。しかし、トリガーが存在する場合、トリガー自体や最終的な出力行では正しい値が参照されていたにもかかわらず、古い値が返されてしまっていました。結果として、誤った問い合わせ結果が生じる可能性があります。

§ §

複数の結合キーと多数のNULL値が存在する場合のハッシュ結合の性能問題が修正されました。 (David Rowley) (18)

NULL値を持つタプルは他のどのタプルとも一致することはないため、ハッシュテーブルに挿入されるべきではありません。これまでのコードでは、最後の結合列以外の列にNULL値が含まれる場合にこの処理が適切に行われていなかったため、NULL値を含む入力が多数あるとハッシュテーブルが著しく肥大化していました。

§ §

RETURNING句の式における括弧で囲まれた「OLD」や「NEW」の解析処理が修正されました。 (Marko Grujic) (18)

「(old).colname」や「(old).*」といった式が誤って処理され、実質的に「NEW」への参照に変換されていました。結果として、誤った問い合わせ結果が生じる可能性がありました。

value IN (array)式に対するプランナのNULL許容性および厳密性チェックが修正されました。 (Ayush Tiwari) (18)(17)(16)(15)(14)

これらのチェックは、配列オペランドが空でないことが既知である場合にのみ成功すべきですが、その点が考慮されておらず、本来適用されるべきではない最適化が適用されてしまう問題がありました。これにより、実際の配列が空であった場合、誤った問い合わせ結果が生じる可能性がありました。

§ § § § § §

不適切な結合削除のロジックが修正されました。 (Matheus Alcantara, Richard Guo) (18)(17)(16)

一部の特殊なケースにおいて、外部結合のNULL許容側由来の定数出力値が、本来NULLに置換されるべき場面でNULLに置換されない問題が発生し、誤った問い合わせ結果が生じる可能性がありました。

§ § § § § § § §

結合の削除処理において、PlaceHolderVarsのクリーンアップがより徹底されるようになりました。 (Richard Guo, Arne Roland) (18)

この修正により、アサート失敗や誤った実行計画の生成（とそれに伴う誤った問い合わせ結果や予期せぬエラー）を招く可能性のあった様々なエッジケースが解消されます。

§ § §

コンテナデータ型（配列、複合型、範囲型）の等価比較におけるハッシュ可能性に関する漏れていたチェックが追加されました。 (Andrei Lepikhov, Tom Lane) (18)(17)(16)(15)(14)

プランナは、ハッシュベースの実行計画を採用する前に、コンテナの構成要素の型のハッシュ化可能かどうかを検証する必要がありました。一部の箇所でこの手順が漏れていたため、実行時に「ERROR: could not identify a hash function for type ...」という予期せぬエラーが発生していました。

§ § § § §

プランナが、異なる等価性ルールを持つグループ化ステップより下位へ、WHERE句をプッシュダウンすることを避けるようになりました。 (Richard Guo) (18)

非決定的照合順序でグループ化される列に対するテストは、その同じ照合順序を使用した比較である場合にのみ、安全にプッシュダウンできます。そうでない場合、グループ化によって統合されるはずだった行がフィルタリングされて、誤った問い合わせ結果が生じる可能性がありました。

§ §

「EXCLUDE」句を指定している、または「ORDER BY」を指定していない、COUNTウィンドウ関数の誤った最適化が修正されました。 (Chengpeng Yan, David Rowley) (18)(17)(16)(15)

これまで、このウィンドウ関数は該当しない場合でも単調増加するものとして扱われていました。そのため、誤った問い合わせ結果が生じる可能性がありました。

（報告された誤動作例）
db1=# CREATE TABLE t41 (id int PRIMARY KEY, k int NOT NULL, v int);
db1=# INSERT INTO t41(id, k, v) VALUES
        (1, 1, 1), (2, 1, NULL), (3, 1, 1), (4, 2, 1);

db1=# SELECT id, count(v) OVER (
        ORDER BY k RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
        EXCLUDE CURRENT ROW) AS c FROM t41;
 id | c
----+---
  1 | 1
  2 | 2
  3 | 1
  4 | 2
(4 rows)

db1=# SELECT * FROM (
        SELECT id, count(v) OVER (
          ORDER BY k RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
          EXCLUDE CURRENT ROW) AS c FROM t41) s WHERE c < 2;
 id | c
----+---
  1 | 1
(1 row)
→ 正しくは id=3 の行も出力されないといけない

§ § § § §

プランナが"char"型の列の統計情報を参照する際に、予期せぬエラー「ERROR: cache lookup failed for collation 0」が発生する障害が修正されました。 (Feng Wu) (18)

"char"型は、一般的に使われるchar(n)型とは別の、主として内部的なシステムカタログで使用されるものです。

複数階層のパーティションが存在する場合でも、ALTER TABLEのALTER COLUMN ... DROP EXPRESSIONが正常に動作するよう修正されました。 (Alberto Piai) (18)(17)(16)(15)(14)

ALTER TABLE ... ALTER COLUMN ... DROP EXPRESSIONは、格納生成列を基本列に変換する構文です。複数階層の子パーティション／子テーブルを持つパーティションテーブルや継承ツリーの親テーブルに対して実行すると、「ERROR: ALTER TABLE / DROP EXPRESSION must be applied to child tables too」というエラーが発生していました。

§ § § § § §

排他制約であるインデックスのパーティションをアタッチする処理の不具合が修正されました。 (Japin Li) (18)(17)

この誤りにより、排他制約を持つパーティションテーブルのダンプ/リストアが正常に動作しなくなっていました。

リストア時に以下のようなエラーが発生します。

ERROR:  cannot attach index "..." as a partition of index "..."
DETAIL:  The index definitions do not match.

§ § §

ALTER CONSTRAINTを使用して、パーティションテーブルのNOT NULL制約にNO INHERITを設定することができないように修正されました。 (Andreas Karlsson) (18)

本来、パーティションテーブルのNOT NULL制約は、すべてのパーティションに継承される仕様であるため、NO INHERITを指定することはできません。これまでは、この仕様は制約を新規作成する際には正しく適用されていましたが、「ALTER TABLE ... ALTER CONSTRAINT」では適用されておらず、NO NULL制約の有無がパーティションごとに異なるようにできました。

ルールの名前を「_RETURN」に変更できないように修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

「_RETURN」という名前は、ビューの「ON SELECT」ルール用に予約されています。これまでは「ON SELECT」以外のルールをALTER RULEで「_RETURN」に名前変更できてしまい、その後の処理で問題を引き起こしていました。

具体的には、ダンプ/リストアで「ERROR: non-view rule for "..." must not be named "_RETURN"」というエラーを起こすことが報告されました。

§ § § § § §

DROP OWNED BYにおいて、ロールメンバーシップへのロックの解放漏れが修正されました。 (Jeff Davis) (18)(17)(16)

この不具合により、トランザクションが終了するまで、ロールメンバーシップ（pg_auth_membersシステムテーブルの対応するエントリであらわされる暗黙的なオブジェクト）へのロックが保持され続けていました。その結果、並行するDDL実行で警告メッセージが出ることがありました。

§ § § §

EXPLAINがSQL/JSONの集約関数をデパースするときに予期せぬエラーを出すことがあり、修正されました。 (Richard Guo) (18)(17)(16)

実行プランの構造によっては、「ERROR: invalid JsonConstructorExpr underlying node type」というエラーが発生していました。

§ § § §

遅延一意性制約のインデックスに対してREINDEX CONCURRENTLYを使用した場合の不具合が修正されました。 (Nitin Motiani) (18)(17)(16)(15)(14)

REINDEX CONCURRENTLYの実行中に一時的に作成されるインデックスのコピーが、誤って即時一意性制約として扱われていました。そのため、実際には制約違反ではない場合でも、制約違反が発生したと誤って報告することがありました。

§ § § § § §

非決定論的照合順序でバックスラッシュ（\）を使用したLIKE句のマッチングの不具合が修正されました。 (Nitin Motiani, Tom Lane) (18)

非決定論的照合順序において、LIKEがエスケープされたバックスラッシュ（\\）を誤って処理し、実質的にバックスラッシュが存在しないものとして扱っていました。

また、通常の文字の前にバックスラッシュが付いている場合も誤った処理をしていました。この場合、バックスラッシュは実質的に無視されるべきですが、実際には後続の通常の文字を完全一致として扱ってしまい、非決定論的照合順序にマッチするかを判断していませんでした。

§ § § §

LIKE句や正規表現の完全一致パターンのインデックススキャン最適化の不具合が修正されました。 (Jelte Fennema-Nio) (18)

非決定論的な照合順序におけるLIKEのリファクタリングによって、LIKE句や正規表現の完全一致パターンを、等価比較のインデックス条件に変換する最適化が誤って壊れていました。これはインデックスの照合順序と式の照合順序が一致しない場合に発生していました。この影響で、psql の「\d tablename」コマンドが大幅に遅くなっていました。

§ §

to_date() におけるローカライズされた月名、曜日名のマッチング処理が修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

大文字・小文字の変換によって文字列のバイト長が変化する場合に、マッチング処理が誤動作していました。月名、曜日名が認識されずに予期せぬエラーが発生する可能性が考えられます。

§ § § § § § §

ギリシャ文字の語末形のシグマに対する大文字小文字の変換のルールが修正されました。 (Jeff Davis) (18)

文字列の直前が大文字小文字を区別しない文字だけで構成されている場合、そのシグマを語末形のシグマとはみなさないようにしました。

§ §

ハングルU+11A7（TBASE）のNFC再合成における誤りが修正されました。 (Diego Frias, Michael Paquier) (18)(17)(16)(15)(14)

この文字は有効なT音節として扱われていましたが、実際にはT音節ではないため、正規化処理中にこの文字が消えてしまっていました。

§ § § § §

大文字小文字を区別しない類義語の辞書において、出力する語彙素が切り捨てられる不具合が修正されました。 (Jeff Davis) (18)(17)(16)(15)(14)

小文字への変換によって語彙素のバイト長が増加した場合、出力時に元のバイト長に誤って切り捨てられていました。

§ § § § §

大文字小文字変換処理において、途中で途切れたUTF-8文字への対処が修正されました。 (Jeff Davis) (18)(17)

§ § §

hash_record_extended()のバグが修正されました。 (Man Zeng) (18)(17)(16)(15)(14)

FunctionCallInvoke()に渡される2番目のisnull引数が初期化されていませんでした。既存の組み込み拡張ハッシュサポート関数では、この値を参照しないため問題はありません。しかし、拡張機能が提供するハッシュ関数が「PG_ARGISNULL(1)」を調べる場合、その影響を受ける可能性がありました。

§ § § § §

公開可能なテーブルが並行して削除された場合に、pg_get_publication_tables()が失敗する不具合が修正されました。 (Bharath Rupireddy) (18)(17)(16)

§ § § §

VARIADIC NULL を指定した場合に、satisfies_hash_partition() がクラッシュする不具合が修正されました。 (Robert Haas) (18)(17)(16)(15)(14)

§ § § § § §

tsvector_filter() および関連する関数で、不正な重みに関するエラーを、より明確かつ一貫した形で報告するよう修正されました。 (Ewan Young) (18)(17)(16)(15)(14)

具体的には、表示可能なASCII文字ではない重み文字については、charout()と同様に8進数形式（"\nnn"）で報告します。これにより、無効なエンコーディングを含むエラーメッセージが生成されるのを防ぎます。

§ § § § §

uundv7()関数で範囲外のタイムスタンプとなるシフト値を拒絶するようになりました。 (Baji Shaik) (18)

v7 UUIDで表現可能な範囲を超えたタイムスタンプになるシフト値は「ERROR: timestamp out of range for UUID version 7」というエラーを出すようになります。有効なタイムスタンプ範囲は、1970-01-01 00:00から10889年くらいまでです。これまでは壊れたUUID値が作られていました。

§ §

xpath()関数でnamestapeノードの処理が修正されました。 (Michael Paquier) (18)(17)(16)(15)(14)

予期せぬ「ERROR: could not copy node」エラーが出ていたものが修正されました。

§ § § § § § § § § §

jsonpathの「.decimal」メソッドが、精度やスケールの指定が正しくない場合でもERRORを出さないように、修正されました。 (Ewan Young) (18)(17)

サイレントモード（json_path_*関数のsilent引数がtrue）では、エラーを抑止すべきですが、そのようになっていませんでした。

§ § § § §

「IS JSON」や「JSON()」等の構文が、text型へのキャストを持たない文字列型の引数を与えられたときの、NULLポインタによるクラッシュが修正されました。 (Ayush Tiwari) (18)(17)(16)

PostgreSQL本体コードには該当するデータ型はありませんが、一部の拡張のデータ型で問題を引き起こす可能性がありました。

§ § §

「SQL/JSON」の「ON EMPTY / ON ERROR DEFAULT」の値に正しい型修飾が確実に適用されるようになりました。 (Ewan Young) (18)(17)

例えば、対象numeric型列の宣言された精度とスケールがデフォルト値に適用されませんでした。

（誤動作例）
db1=# SELECT JSON_VALUE(jsonb '{"b":"1234.5"}', '$.a' 
        RETURNING numeric(4,1) DEFAULT 99999.9 ON EMPTY);
 json_value
------------
    99999.9
(1 row)

（以下エラーが出るのが正しい動作）
ERROR:  numeric field overflow

§ § §

money型の最小値（64bit整数最小値）を-1で割ったときの、マシン依存の振る舞いが回避されました。 (Andrey Rachitskiy) (18)(17)(16)(15)(14)

x86_64アーキテクチャでエラーになるものが、aarch64アーキテクチャではエラーになりませんでした。オーバーフローを起こした場合には必ず「ERROR: money out of range」が出るようになりました。

§ § § § § §

全文検索の辞書に対するキャッシュエントリの作成途中でメモリ不足が生じた後にクラッシュする障害が修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

§ § § § § §

誤ったispell/hunspell辞書ファイルに対する処理でメモリ安全性に問題があり、修正されました。 (Andrey Rachitskiy) (18)(17)(16)(15)(14)

§ § § § § §

他セッションの一時テーブルへのアクセスが防止されました。 (Jim Jones, Daniil Davydov, Alexander Korotkov) (18)(17)(16)

基本的にそのようなアクセスは禁止されていますが、一部のコードパスで防止しきれておらず、干渉されたセッションで誤った問合せ結果が生じるおそれがありました。

§ § § § § §

一時テーブルにアクセスするときの「ERROR: no empty local buffer available」エラーが防止されました。 (Melanie Plageman) (18)

本修正でストリーミング読み取りの仕組みが使用可能なローカルバッファの数が制限されました。これまでは、effective_io_concurrency設定が大きな値の場合に単一のストリームで全バッファを利用可能であったため、本エラーが発生しました。

autovacuumがデータベースを処理する順番が修正されました。 (Rustam Khamidullin) (18)(17)

最高スコアから最低スコアに向かう順で処理されるべきところで、意図せず逆順になっていました。

§ § §

VACUUMのXID周回フェールセーフモードで、共有バッファプールを全使用するように動作が復旧されました。 (Melanie Plageman) (18)

通常のVACUUMは、他の処理に大きな影響を与えないように、共有バッファを少しだけ使うように制限されています。しかしながら、フェールセーフモードではできるだけ早くトランザクションIDを回収する必要があるので、この制限は放棄されることになっていました。この振る舞いがv18のリファクタリングで壊れていて、復旧されました。

§ § § §

パラレルVACUUMワーカーの処理でのメモリリークが修正されました。 (Baji Shaik) (18)(17)

パラレルワーカーからの報告過程で報告ごとに1kB程度のリークがあり、これはワーカープロセスが生きている間は蓄積されていきました。

§ §

問合せのキャンセルとVACUUM遅延が、GINインデックスのポスティングツリーのクリーンアップ中であっても、すぐに行なわれるようになりました。 (Paul Kim, Alexander Korotkov) (18)(17)(16)(15)(14)

よくある値に対するポスティングツリーは大きくなることがあり、ここに割り込みの検査が欠けていたため、処理が長く継続してしまいました。

§ § § § § §

GiSTおよびSP-GiSTのインデックスに対するIndex Only Scanで、インデックスタプルのデコーディングを誤る可能性があり、修正されました。 (Peter Geoghegan) (18)(17)(16)(15)(14)

この障害で壊れたデータが出力されて、誤った問い合わせ結果や予期せぬエラーが発生する可能性がありました。本体コードで影響があるのは、GiSTの演算子クラスrange_opsのみで、その範囲列が最初のインデックス列でない場合にのみ、誤動作が発生します。

（誤動作例）
db1=# CREATE TABLE t75 (a inet, r numrange);
db1=# INSERT INTO t75 VALUES 
      ('::1', numrange(repeat('1', 100)::numeric, repeat('2', 200)::numeric)));
db1=# CREATE INDEX ON t75 USING gist (a inet_ops, r range_ops);
db1=# VACUUM ANALYZE t75;
db1=# SET enable_seqscan TO off;
db1=# SELECT lower(r) = repeat('1', 100)::numeric,
             upper(r) = repeat('2', 200)::numeric FROM t75;
ERROR:  type with OID 860 does not exist

§ § § § § §

バルク拡張されたテーブルの新たな最終ブロックがフリースペースマップに即座に追加されるようになりました。 (Jingtang Zhang) (18)(17)(16)

off-by-one（1つ足りない）誤りで、複数ブロックが追加されたときの最後のブロックがフリースペースマップに登録されませんでした。VACUUMによってやがては正しく登録されますが、それまでの間、最終ブロックが使われませんでした。

§ § § §

トランザクションのアボート時のリソース解放処理で、メモリの二重解放（クラッシュをひきおこします）、または、エラーの再帰的な無限ループが起きる可能性があり、修正されました。 (Tom Lane) (18)(17)

巨大な入力値を伴うSQLがエラーになって、トランザクションアボートが行なわれたケースで問題が報告されました。

§ §

PostgreSQLの処理内でディレクトリを作成するとき、同じディレクトリの同時作成を許容するようになりました。 (Andrew Dunstan, Tom Lane) (18)(17)(16)(15)(14)

他プロセスが同じディレクトリを作っているのであれば、ディレクトリ作成に成功した扱いとすることで、これまで同時実行で発生する可能性のあった「ERROR: could not create directory "...": File exists」といったエラーを回避できます。

§ § § § §

JITコンパイルされたタプルデフォームを行うコードが、仮想生成列を正しく考慮するように修正されました。 (David Rowley) (18)

NOT NULL制約のある仮想生成列を含むテーブルへの問合せで、誤った問い合わせ結果が生じる例が報告されました。

依存されている全てのオブジェクトに共有ロックを取得することにより、宙に浮いたオブジェクト依存関係の生成が防止されました。 (Bertrand Drouvot) (18)(17)(16)(15)(14)

共有ロックは依存されているオブジェクトの削除と衝突しますので、これまであった競合状態を排除することができます。

例えば、これまでは、空スキーマの削除とスキーマ内へのオブジェクト作成の同時実行が両方成功して、無効なオブジェクト定義が残ることがありましたが、これからはどちらかのトランザクションが失敗します。

§ § § § § § § § § §

SERIALIZABLE分離モードに対する衝突の検出での競合状態が修正されました。 (Peter Geoghegan) (18)(17)(16)(15)(14)

初期の空のbtreeインデックスを検査するときに衝突が見過ごされる可能性があり、競合しているトランザクションのコミットを許してしまっていました。

§ § § § § §

バリアイベントの処理で競合状態が修正されました。 (Masahiko Sawada) (18)(17)(16)(15)

この誤りにより、プロセスがハングアップする可能性がありました。典型的には、その際に以下ログメッセージが出力されます。待機イベントとしてはIPC型のProcSignalBarrierの待機となります。

LOG:  still waiting for backend with PID %d to accept ProcSignalBarrier

近年追加されたオンラインWALレベル変更などの機能によって、この問題がより目立つようになっています。

§ § § §

同じロックグループに属するプロセス集合が同時に終了したときの競合状態が修正されました。 (Vlad Lesin) (18)(17)(16)(15)(14)

この誤りは「PANIC: latch already owned by PID ..」によるサービスのPANIC終了を引き起こす可能性があります。PostgreSQL本体の通常のパラレル問合せでは、リーダープロセスがワーカープロセスの終了を待たずに終了することが無いため、この問題は起きませんが、何らかの拡張で該当する可能性がありました。

§ § § § § § § § § §

テーブルのビジビリティマップ(VM)でビットをクリアする操作のWAL出力が修正されました。 (Melanie Plageman, Andres Freund) (18)(17)

このようなVM変更がWALサマライズ処理で見落とされていて、誤ったインクリメンタルバックアップをもたらす可能性がありました。また、このようなVMページの必要時のフルページイメージWAL出力も行なわれておらず、壊れたページ書き込みが修正されないままとなる可能性がありました。これは後にIndex Only Scanでの誤った問い合わせ結果が生じるなどの、誤動作を引き起こすおそれがあります。

既存のバックアップやアーカイブWALに潜在的にデータ破損が含まれていることに留意してください。

§ § § § § § § § §

WALサマライズ処理でのタイムライン変更時のハングアップが防止されました。 (Robert Haas) (18)(17)

スタンバイサーバで、以下のログメッセージがwalsummarizerプロセスから継続的に出力される動作が報告されました。

ERROR:  could not read WAL from timeline .. at ...: invalid record length ...

§ § § § § §

スタンバイ昇格のときのロジカルデコーディングのタイムライン選択で、競合状態が修正されました。 (Bertrand Drouvot) (18)(17)(16)

スタンバイ側で実行中のロジカルデコーディングが「ERROR: requested WAL segment has already been removed」で失敗する可能性がありました。再試行すれば成功するため恒久的な問題はありませんが、可用性としては有害でした。

§ § § § § § §

タイムラインを切替するときのwalreceiverの接続文字列の露出が回避されました。 (Chao Li) (18)(17)(16)(15)(14)

pg_stat_wal_receiverビューは機微なデータを除いてサニタイズされた接続文字列を見せるべきです。しかし、タイムライン切替に際して既存のwalreceiverプロセスを再利用するときに、一時的に完全な接続文字列を見せてしまっていました。

§ § § § §

ロジカルレプリケーションで受け取ったタプルの列数が正しいかの検証を、アサートではなく実行時チェックで行うようになりました。 (Varik Matevosyan) (18)(17)(16)(15)(14)

悪意の、または、壊れたパブリッシャは一貫性のない列数を送出するかもしれません。これによる深刻な悪影響をおよぼすシナリオは見つからなかったものの、より注意を払うべきと判断されました。

§ § § § §

レプリケーションコマンド内の文字列パラメータへのクォート付加について、実装がクリーンアップされました。 (Tom Lane) (18)(17)(16)(15)(14)

レプリケーションコマンドを生成する様々な個所で、コマンドに挿入されるレプリケーションスロット名や他のパラメータのクォート付加について、十分な注意が払われていませんでした。そのため、レプリケーションコマンドで予期せぬエラーが発生するおそれがありました。

原理的には作りこまれたレプリケーションスロット名でSQLインジェクションも可能でした。ただし、ほとんどの場合、元からSQL実行が可能な管理者が行う操作であるため、実用的な害はないと考えられます。

§ § § § §

空のプリペアドトランザクションのロジカルデコーディングについて修正されました。 (Masahiko Sawada) (18)(17)(16)(15)(14)

デコード可能な変更を起こさないプリペアドトランザクションは、先立つ「PREPARE」無しに、「COMMIT PREPARED」や「ROLLBACK PREPARED」を出力プラグインに送出していました。組み込みのサブスクライバでは、これはレプリケーションを壊します。他のプラグインでも同様に問題となると考えられます。

§ § § § § §

スタンバイ昇格後のUNLOGGEDシーケンスのデータ破損が修正されました。 (Fujii Masao) (18)(17)(16)(15)

これまでは、プライマリで作られてスタンバイにレプリケートされたUNLOGGEDシーケンスに、スタンバイ昇格後にアクセスすると、「ERROR: bad magic number in sequence」などのエラーや、アサート失敗が発生する可能性がありました。

§ § § § §

カスケードスタンバイでのWALアーカイブによるリカバリからストリーミングに復帰するときの再接続失敗が、修正されました。 (Marco Nenciarini) (18)(17)(16)(15)(14)

このとき「ERROR: requested starting point ... is ahead of the WAL flush position」が発生する可能性がありました。

§ § § § § §

WALリプレイが一貫性のあるデータベース状態に達する前にホットスタンバイ接続を受け付ける動作が防止されました。 (Nikhil Sontakke) (18)

§ §

スタンバイサーバで、ローカルにpg_database.dathasloginevtのクリアを試みないようになりました。 (Ayush Tiwari) (18)(17)

スタンバイで実行が試みられていましたが、これは機能しておらず、また、プライマリでの変化がすぐに反映されて上書きされるので不要な動作でした。

loginのイベントトリガを削除した後にスタンバイに接続したときに、「FATAL: cannot acquire lock mode AccessExclusiveLock on database objects while recovery is in progress」が出て接続できない動作が報告されました。

§ §

使われなくなったレプリケーションスロットを削除するときの競合状態が回避されました。 (Xuneng Zhou) (18)(17)

削除直後のスロットの共有メモリエントリを他セッションが再利用した場合、誤ったロック解放と誤ったログメッセージ（異なるスロット名やデータベースOIDが使われる）が生じる可能性がありました。

§ §

一時的なレプリケーションスロット（初期化途中の論理レプリケーションスロット）を削除するときの競合状態が回避されました。 (Zhijie Hou) (18)(17)(16)(15)(14)

これまでの実装では、スロットを解放した後にスロットの共有メモリエントリにいくらか追加的な更新を実行していました。これは他セッションが直ちに再利用するかもしれないため、安全ではありません。本修正で、一時スロットには、この更新を行なわないようになりました。

§ § § § §

ロジカルレプリケーションのテーブル初期同期で、進捗報告が古い内容となっていた問題が修正されました。 (Shinya Kato) (18)(17)(16)(15)(14)

これまでは、サブスクライバのpg_stat_progress_copyビューは、データコピーが終わった後でも、初期COPY操作をアクティブとして表示していました。同期がパブリッシャに追いつくまで、古いエントリが表示されたままでした。

§ § § § §

バックアップに失敗したなら、ベースバックアップの進捗がクリアされるようになりました。 (Chao Li) (18)(17)(16)(15)

これまで、pg_stat_progress_basebackupビューは、レプリケーションクライアントが切断するまで、古い進捗情報を表示し続けていました。標準付属のpg_basebackupであれば、失敗した後に即座に切断しますが、他のバックアップを取得するクライアントはそうであるとは限りません。

§ § § § § § § § §

設定track_functionsが有効であるとき、実行時統計情報(pgstats)のエントリの同時削除のためにPANICが生じる可能性があり、修正されました。 (Sami Imseih, Michael Paquier) (18)(17)(16)(15)

「PANIC: cannot abort transaction .., it was already committed」が出るケースが報告されました。

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

対応する共有ハッシュテーブルのエントリに対するメモリ領域取得に失敗した後、壊れた実行時統計情報(pgstats)のローカルエントリをクリーンアップするようになりました。 (Niall Newman) (18)(17)(16)(15)

これを行なっていなかったため、次にローカルエントリが使われたときに、NULLポインタ参照によるクラッシュが発生しました。

§ § § § §

読み込みや書き込みの失敗後に誤ったI/O操作統計が記録されないように、修正されました。 (Bertrand Drouvot) (18)

各種のWAL読み書きに処理に失敗したときにエラーを意味する負の値がそのまま統計値のカウントに使われていて、pg_stat_ioビューなどで参照されるWALのI/O統計に誤った値が混入する可能性がありました。

PL/Perlで、不正なPostgreSQL::InServer::ARRAYオブジェクトを扱うときのNULLポインタ参照によるクラッシュが回避されるようになりました。 (Xing Guo) (18)(17)(16)(15)(14)

PostgreSQL::InServer::ARRAYはPL/Perl関数に引数でPostgreSQLの配列を渡すときに使われるperlのオブジェクト型です。PL/Perl関数からPostgreSQLの配列を返すときにも使用できます。検査が不足していて、引数に由来せず適切な内部構造を持たないPostgreSQL::InServer::ARRAYオブジェクトを返すとクラッシュを引き起こせました。

（クラッシュ発生例）
=# CREATE FUNCTION f102() RETURNS integer[] AS $$
     return bless {}, "PostgreSQL::InServer::ARRAY"; $$ LANGUAGE plperl;
=# SELECT f102();
server closed the connection unexpectedly

§ § § § §

PL/Pythonで、Pythonのシーケンスオブジェクトとマッピングオブジェクトを扱うときにエラーを正しく検査するようになりました。 (Richard Guo) (18)(17)(16)(15)(14)

hstore_plpython拡張やjsonb_plpython拡張を使って、PL/Python関数の戻り値をhsotre型やjsonb型に変換している場合に該当する問題です。これまでは、壊れたオブジェクトやハンドルされない例外によって、NULLポインタ参照によるクラッシュが発生する可能性がありました。

§ § § § § §

libpqで、pqReadData()の実行中にSSLまたはGSSの復号バッファに残っている未処理バイトを常にすべて取り出すようになりました。 (Jacob Champion) (18)(17)(16)(15)(14)

例外的なケースですが、大きなメッセージのサーバからの届き方によっては、バッファがいっぱいになることでlibpqがソケット到着を誤って待ち続けて、APIを呼び出すクライアントアプリケーションがハングアップしてしまう可能性がありました。

pqReadData()はサーバ側からデータを読むlibpqの内部実装関数です。

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

libpqのメモリ不足状態の処理が改善されました。 (Anthonin Bonnefoy) (18)

COPYデータ読み込みや関数呼び出しの途中に、非同期メッセージ処理でメモリ不足になった場合にも、直ちにエラーを出すようになりました。これまでは、セッション切断された状態で処理が継続されていて、エラー発生が遅れたり、不適切なエラーが出る可能性がありました。

§ §

libpqのトレース機能が、新しい形式のBackendKeyDataメッセージとCancelRequestメッセージを正しく出力するようになりました。 (Anthonin Bonnefoy) (18)

これらのプロトコルメッセージは固定長から可変長に仕様変更されましたが、トレース機能では固定長を想定したままとなっていたため、「mismatched message length」という警告が出力されていました。

§ §

libpqが30000バイトを超えるParameterDescriptionメッセージを受け付けられるようになりました。 (Ning Sun) (18)(17)(16)(15)(14)

libpqは受信メッセージの妥当性検査として、「長くなりうるメッセージ型」以外について長すぎるメッセージを弾きます。ParameterDescriptionは「長くなりうるメッセージ型」として扱われていなかったため、メッセージ長が30000バイトを超えるとエラーになっていました。この制限により、7498個を超えるパラメータを持つプリペアドステートメントに対するPQdescribePrepared()が失敗していました。この数のパラメータはまれな用法ですが仕様の範囲内です。

§ § § § §

ecpgコンパイラのNULLポインタ参照によるクラッシュが修正されました。 (Jehan-Guillaume de Rorthais) (18)

構造体の内側に入れ子になった共用体を含むDECLAREセクションをもつ.pgcコードを変換しようとすると、ecpgコマンド実行がクラッシュしました。

（ecpgコマンドがクラッシュするコード例）
EXEC SQL BEGIN DECLARE SECTION;
    struct s1
    {
        char STR1[10];
        union u1
        {
             int NUM1;
             int NUM2;
        } U1;
    } S1;
EXEC SQL END DECLARE SECTION;

ecpgのGET DESCRIPTOR文とSET DESCRIPTOR文で、記述子ヘッダ項目を複数指定する構文が拒否されるようになりました。 (Masashi Kamura) (18)(17)(16)(15)(14)

これまでも文法上はこの構文が許されていましたが、実装は実際には複数のヘッダ項目に対応できておらず、指定すると壊れたCコードが生成されていました。

本修正で構文解析処理でもドキュメント上でもヘッダ項目は1つだけに変更されました。これは非互換性を含む変更です。

§ § § § §

psqlのパイプラインモードにおける遅延エラーの問題が修正されました。 (Michael Paquier) (18)

Syncメッセージへの応答としてサーバがエラーを報告する場面（遅延制約の違反など）で、psqlがハングアップしたり、アサート失敗したりする可能性がありました。

psqlの拡張表示（expanded）の整形出力で、行の幅が揃うようになりました。 (Pavel Stehule) (18)(17)(16)(15)(14)

テーブルのデータ行がレコードヘッダ行より狭い場合、データ行の幅がレコードヘッダ行に合わせられず、次のように桁のずれた出力になっていました。

（ずれた出力の例）

+-[ RECORD 1 ]-+
| a | 10 |
| b | 20 |
+---+----+

（修正後の出力例）

+-[ RECORD 1 ]-+
| a | 10       |
| b | 20       |
+---+----------+

§ § § § §

psqlの特別変数WATCH_INTERVALについて、既定の上限が強制されるようになりました。 (Sven Klemm, Daniel Gustafsson) (18)

大きすぎる値(1000000超)を設定しようとすると、psqlはエラーを報告するものの、その値を適用してしまっていました。修正後は、上限を超える値は拒否され、変数の値は変更されません。

psqlの「\l+」でデータベースサイズを表示する権限検査が修正されました。 (Christoph Berg) (18)(17)(16)(15)(14)

サーバ側のpg_database_size()は、pg_read_all_statsロールの権限を持つ利用者に対して、対象データベースへのCONNECT権限がなくてもすべてのデータベースのサイズの参照を許します。しかしpsqlはこの仕組みを考慮せず、CONNECT権限を持つ利用者以外に対してはこの関数を呼び出していませんでした。

修正後は、「\l+」の権限検査にpg_read_all_statsロールの権限（USAGE）の確認が加わり、pg_database_size()の権限規則と一致するようになりました。

§ § § § § §

psqlの「\df」のタブ補完で、プロシージャも候補に含めるようになりました。 (Erik Wienhold) (18)(17)(16)(15)(14)

「\df」コマンド自体はプロシージャも表示対象に含めるよう拡張されていましたが、タブ補完の候補は関数だけを表示し続けていました。

§ § § § § §

pgbenchのスレッド安全性のバグが修正されました。 (Fujii Masao) (18)(17)(16)(15)

pgbenchを複数スレッドで実行し、かつ「--verbose-errors」オプションを指定した場合、異なるスレッドが同じバッファを使ってエラーメッセージを組み立てようとし、ログ出力が壊れる可能性がありました。

§ § § §

pg_combinebackupで、コピー元ファイルが想定より小さい場合に無限ループが発生することがあり、防止されました。 (Peter Eisentraut) (18)(17)

「--copy-file-range」を指定して合成フルバックアップを再構築する過程で、ファイルが0バイトしかコピーできなかった場合をエラーとしていなかったため、試行が繰り返されてしまっていました。

§ §

pg_createsubscriberで、エラー発生後にパブリッシャ側オブジェクトのクリーンアップが行なわれない場合があり、修正されました。 (Nisha Moond) (18)(17)

pg_createsubscriberは、論理レプリケーションオブジェクトを作成した後にエラーを起こした場合、パブリッシャ上に作成したパブリケーションとレプリケーションスロットを削除する必要があります。一部のエラーケースでは削除が行われず、pg_createsubscriberの再実行のために手動での削除が必要でした。

§ §

pg_recvlogicalの出力ファイルが、ソースクラスタのグループ読み取り権限に従って作成されるようになりました。 (Fujii Masao) (18)(17)(16)(15)(14)

pg_recvlogicalはこの挙動についてドキュメントに記載されていたにもかかわらず、実際にはソースクラスタのグループ読み取り権限を反映した書き出しが行なわれず、常にファイル所有者の読み書きのみを許すモードが使われていました。

§ § § § §

pg_restoreの「--statistics」および「--statistics-only」オプションの一貫しない挙動が修正されました。 (Chao Li, Michael Paquier) (18)

「--schema」「--table」などの選択的リストアオプションと組み合わせた場合に意図通りの要素がリストアされませんでした。pg_dumpで対象選択オプションを組み合わせた場合と同様に動作するように修正されました。

（誤動作例）
$ psql -d db1 <
 § §
vacuumdbの「--missing-stats-only」が、パーティションテーブルに対する式インデックスを処理対象から除外するようになりました。  (Baji Shaik) (18)

これまで、本オプションのvacuumdb実行では、パーティションテーブルに式インデックスがあると、常にそのパーティションテーブルにANALYZEを実行しようとしていました。しかし、統計情報は子パーティションのインデックスに作成されても、パーティションテーブルのインデックスには作成されないため、意味がありませんでした。

 §
contrib/amcheckで、btreeインデックスのメタページの「allequalimage」フラグの破損が報告されない問題が修正されました。  (Chao Li) (18)

btreeインデックスを検査する関数は、これまでインデックスキー列のいずれかにinterval_ops演算子クラスを含む場合のみ正しく動作していて、そうでないインデックスでこの破損が見逃される可能性がありました。

 §
contrib/amcheckの GINインデックス検証関数でメモリリークが修正されました。問い合わせが終わるまで未開放メモリが蓄積します。  (Kirill Reshke) (18)

大きなGINインデックスの検証でメモリ使用量が増大するおそれがありました。

 § §
contrib/amcheckで、ショートヘッダのvarlenaデータムが正しく扱われるように修正されました。  (Andrey Borodin) (18)(17)(16)(15)(14)

この誤りで、btreeインデックス検証で無駄な処理が生じる可能性がありますが、それ以上の悪影響は無いと考えられます。


varlenaデータムとはPostgreSQL実装内で使われる長さとデータ本体からなるデータ構造です。ショートヘッダは長さをあらわすのに1バイトだけ使う形式です。

 § § § § §
contrib/btree_gistで、float4とfloat8の演算子クラスにおける「NaN」の扱いが修正されました。  (Bill Kim, Tom Lane) (18)(17)(16)(15)(14)

各種の比較関数と、GiSTのpenalty関数、distance関数が「NaN」を考慮しておらず、「NaN」を渡されたときに誤った結果を返していました。


本修正の適用後、float列のbtree_gistインデックスに「NaN」のエントリが含まれる可能性がある場合は、それらのインデックスの再構築を推奨します。

 § § § § § §
contrib/btree_gistで、GiSTインデックス構築時のbit型とvarbit型の値のソートが修正されました。  (Tom Lane) (18)

これまでbit型の値がbytea型であるかのようにソートされていました。これは明白な誤動作を引き起こすことはありませんでしたが、型本来のソート順に一致しない並びで構築されるため、非効率なインデックスになりました。


本修正の適用後、bit列上のbtree_gistインデックスの再構築を推奨します。

 § §
contrib/btree_gistで、非等価（<>）演算子を使った検索が修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

可変長データ型の場合、非リーフインデックスページを走査するコードが誤った比較関数を適用していました。これは誤った問い合わせ結果、および場合によってはクラッシュにつながる可能性がありました。

 § § § § § §
contrib/dblinkとcontrib/postgres_fdwで、use_scram_passthroughオプションについて、ユーザマッピングの設定が外部サーバの設定より優先されるよう修正されました。  (Matheus Alcantara) (18)

これまでは外部サーバ側の設定が優先されていましたが、これは他の外部テーブルオプションの挙動と一貫していませんでした。他の接続オプション（sslcertやsslkeyなど）と同様に、外部サーバのオプションは共通のデフォルト値を提供し、ユーザマッピングのオプションがそれを上書きする扱いに統一されました。


これは非互換性を含む変更と言えます。

 § §
contrib/dblinkの外部データラッパのuse_scram_passthroughオプションが拒否されるようになりました。  (Matheus Alcantara) (18)

このオプションは外部サーバとユーザマッピングに対してのみ意味を持ちますが、dblinkは外部データラッパ（dblink_fdw）レベルでもこのオプションを受け付けていました（そして受け付けた設定を無視していました）。

 §
contrib/hstore_plperl、contrib/jsonb_plperl、contrib/jsonb_plpythonで保護されていない再帰とループがあり、修正されました。  (Aleksander Alekseev) (18)(17)(16)(15)(14)

深くネストしたjsonb値を扱うときのスタックオーバーフロー（によるクラッシュ）が防止されました。また、Perlのオブジェクト参照の循環チェーンをたどるときに生じる無限ループが割り込み可能になりました。

 § § § § § § § § § §
contrib/intarrayでプランナ統計情報のカタログキャッシュエントリの解放漏れが修正されました。  (Man Zeng) (18)(17)(16)(15)(14)

この解放漏れにより、「WARNING:  resource was not closed: cache pg_statistic ..」のような警告が発生していました。

 § § § § §
contrib/ltreeで比較関数における整数オーバーフローが修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

約14,653個を超えるラベルを含むltree値は、オーバーフローによって誤った比較結果を返していました。btreeインデックスにそのような値が含まれている場合、破損している可能性があるため、本修正の適用後に再構築することを推奨します。

 § § § § §
contrib/pgcryptoで、OSSLCipherオブジェクトの使用中にエラーが発生した後の二重解放によるクラッシュが回避されました。  (Yuelin Wang) (18)(17)
 § §
contrib/pg_prewarmのautoprewarmワーカの範囲外アクセスが修正されました。  (Matheus Alcantara) (18)

このコードは、配列の末尾の1つ先から値を取り出そうとしており、セグメンテーション違反によるクラッシュを引き起こす可能性がありました。

 §
contrib/pg_surgeryのheap_force_kill関数とheap_force_freeze関数で、配列の範囲外書き込みが修正されました。  (Michael Paquier) (18)(17)(16)(15)(14)

オフセット番号がMaxHeapTuplesPerPage（ページあたりの最大タプル数、291など）に等しいTIDを変更しようとすると、確保された配列の末尾の1バイト先に書き込み、サーバをクラッシュさせる可能性がありました。

 § § § § §
contrib/pg_surgeryで、64K要素を超えるTID配列による無限ループが回避されるようになりました。  (Andrey Rachitskiy) (18)(17)(16)(15)(14)
 § § § § § §
contrib/spiのrefint拡張で、check_foreign_key()関数のNULLポインタ参照が回避されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

ON UPDATE CASCADEの場合、参照列の新しいキー値がNULLであると、クラッシュが発生していました。これはCVE-2026-6637の修正の見落しですが、その前からあったコードも正しいものではありませんでした。

 § § § § §
contrib/segで、確実性指示子「~」を持つセグメントの値が正しく出力されるように修正されました。  (Ewan Young) (18)(17)(16)(15)(14)

seg型の出力関数seg_out()はセグメントの上限に付いた「~」を出力していませんでした。さらに悪いことに、下限に「~」があり上限に指示子がない場合、上限がまったく出力されませんでした。なお、文字列としての出力が不正であるだけで、演算結果に影響はありません。

（誤動作例：2番目と3番目が誤動作）
db1=# SELECT '~1 .. ~5'::seg, '1 .. ~5'::seg, '~1 .. 5'::seg;
   seg    |  seg   |  seg
----------+--------+--------
 ~1 .. ~5 | 1 .. 5 | ~1 ..
(1 row)

 § § § § §
contrib/xml2のxpath_nodeset()関数で名前空間ノードを問合せたときのクラッシュが修正されました。  (Andrey Chernyy, Michael Paquier) (18)(17)(16)(15)(14)

以下のように、query引数に「//namespace::」を指定した場合にクラッシュするケースが報告されました。

db1=# SELECT xpath_nodeset(
        '',
        '//namespace::*');

 § § § § §
OpenSSL 4を使ったPostgreSQLのビルドに対応しました。  (Daniel Gustafsson) (18)(17)(16)(15)(14)
 § § § § §
タイムゾーンデータファイルをtzdataリリース2026cに更新しました。  (Tom Lane) (18)(17)(16)(15)(14)

アルバータ州（America/Edmonton）は、2026年11月から年間を通したUTC-06（実質的に、恒久的なサマータイム）になります。このリリースでは、それ以降のタイムゾーン省略形は「CST」と仮定しています。この仮定は将来変更される可能性が高いのですが、新しい省略形に何が使われるかは明らかになっていません。


モロッコ（Africa/Casablanca）は、2026-09-20に、サマータイムの切り替えなしの恒久的なUTC+00に移行します。

 § § § § § §
古いマイナーバージョンが生成したWALのリプレイ時の自己デッドロックが修正されました。  (Andrey Borodin) (16)(15)(14)

この不具合は前回のマイナーリリース(16.14、15.18、14.23)で導入されました。より古いマイナーバージョンのプライマリに追従するスタンバイサーバで、startupプロセスがハングアップしてレプリケーションが先に進まなくなりました。


共有行ロックで使われるマルチトランザクションに関するWALレコードのリプレイで問題が発生しました。

 § § §
変数が1つも渡されていない場合でも、未定義のjsonpath変数をエラーとして扱うようになりました。  (Andrey Rachitskiy) (16)(15)(14)

jsonbの「@?」演算子と「@@」演算子がjsonpath式の中で使う変数を渡せない、という場合のコードパスでは、未知のjsonpath変数が、本来の期待であるエラーの発生ではなく、JSONのnullとして誤って扱われていました。期待される動作でないことに加えて、この誤りは無制限のメモリ消費を引き起こす可能性がありました。

（誤動作例）
db1=# select '{"A":1}'::jsonb @@ '$"no_such_var" == 1';
 ?column?
----------
 f
(1 row)

db1=# SELECT '{"A":1}'::jsonb @? '$"no_such_var"';
 ?column?
----------
 t
(1 row)

（修正後は以下のエラーが出る）
ERROR:  could not find jsonpath variable "no_such_var"

 § § §
Visual Studio 2026を使ったPostgreSQLのビルドに対応しました。  (Andrew Dunstan) (16)(15)(14)
 § § §

SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

2026/10/27（火）「PostgreSQL 19 リリース記念セミナー」開催！
コントリビューターが新機能をわかりやすく解説します。
詳しくはこちらをご覧ください。

PostgreSQL 17.10 に関する技術情報

データベース技術グループ — Thu, 28 May 2026 03:11:19 +0000

このリリースは 17.9 からの修正リリース（2026年 5月 14日リリース）です。
17.X からのアップデートではダンプ、リストアは不要です。
しかしながら、17.6 よりも前のバージョンからアップデートする場合には、17.6のリリース情報も参照してください。

PostgreSQL 17.9 から 17.10 への変更点

18.4, 17.10, 16.14, 15.18, 14.23 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。

スタートアップパケットの処理での際限ない再帰を防止するようになりました。(CVE-2026-6479) (Michael Paquier) (18)(17)(16)(15)(14)

悪意のクライアントが、拒絶されたSSLとGSSの暗号化の要求を交互に何度も繰り返すことで、接続先バックエンドをクラッシュさせることができました。

§ § § § § § § § §

メモリ割り当て計算における整数オーバーフローがいくつか修正されました。(CVE-2026-6473) (Tom Lane, Nathan Bossart, Heikki Linnakangas) (18)(17)(16)(15)(14)

様々な場所のメモリ割り当てサイズの計算で整数オーバーフローの可能性について不注意がありました。整数オーバーフローにより小さすぎるメモリ確保が行なわれて、その結果、範囲外に書き込みが行なわれて、サーバプロセスのクラッシュを引き起こす可能性がありました。また、おそらく任意コード実行も可能と考えられます。

全てとは言えませんが、この危険があるのは概ね 32ビットビルドだけです。

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

pg_createsubscriberコマンドで、オプションで指定されたサブスクリプション名を適切にクォートするようになりました。(CVE-2026-6476) (Nathan Bossart) (18)(17)

（ありそうにないことですが）信頼できない者がサブスクリプション名を任意に指定しているとして、サブスクリプション名にクォート無しのSQLコマンドを含めることで、SQLインジェクションが可能でした。

§ §

論理レプリケーションのオリジンの検査で、オブジェクト名を適切にクォートするようになりました。(CVE-2026-6638) (Pavel Kohout) (18)(17)(16)

「ALTER SUBSCRIPTION ... REFRESH PUBLICATION」はクォートを付加することなくSQLコマンドにスキーマ名とリレーション名を埋め込んでいて、これによりSQLインジェクションでパブリッシャ側で任意のSQL実行ができました。

§ § §

ts_headline()関数で長すぎるオプションをエラーを出して拒絶するようになりました。(CVE-2026-6473) (Michael Paquier) (18)(17)(16)(15)(14)

オプション「StartSel」「StopSel」「FragmentDelimiter」の文字列長は32Kbが上限でしたが、入力の検査が行われていませんでした。これを超える長い文字列の指定は、典型的にはサーバプロセスのクラッシュを引き起こしました。

§ § § § §

列のMCV（最頻値）統計情報をリストアするときに、誤った入力を検出するようになりました。(CVE-2026-6575) (Michael Paquier) (18)

プランナ統計情報をリストアする関数はMCV統計値の検証が不十分でした。そのため、誤った値を受け入れて、後のプランナのクラッシュを引き起こすことがありました。

timeofday()およびpg_strfname()関数で、悪意のタイムゾーン名による攻撃を防ぐようになりました。(CVE-2026-6474) (Tom Lane) (18)(17)(16)(15)(14)

作りこまれたタイムゾーン設定により、pg_strfname()関数に続いて実行されるsnprintf()関数のテンプレート文字列引数に「%」シーケンスを渡すことができました。これにより潜在的にクラッシュやサーバメモリ暴露を引き起こすことができました。また、pg_strftime()で使われるサイズに限りのある出力バッファのオーバーフローを起こすこともありました。

§ § § § § § § § § §

マルチ範囲型を作るときに、ユーザに指定されたスキーマに対するCREATE権限があることの確認が漏れており、修正されました。(CVE-2026-6472) (Jelte Fennema-Nio) (18)(17)(16)(15)(14)

マルチ範囲型は元となる範囲型と異なるスキーマに作成することが可能ですが、このときマルチ範囲型のスキーマについて権限確認が行なわれませんでした。

（誤動作例：scm_without_privilegeに権限がなくともエラーなく実行できてしまう）
db1=> CREATE TYPE scm_with_privilege.typ1_range AS RANGE
        (SUBTYPE=int4, MULTIRANGE_TYPE_NAME=scm_without_privilege.typ1_multi)
CREATE TYPE

§ § § § §

認証のコードでタイミング攻撃に安全な文字列比較を使うようになりました。(CVE-2026-6478) (Michael Paquier) (18)(17)(16)(15)(14)

これからはパスワードやハッシュ文字列などの検査で、memcpy()やstrcmp()に替えてtimingsafe_bcmp()を使用します。所要時間のデータ依存性がどれほど攻撃に有用であるかは不明ですが、安全のため置き換える判断がされました。

§ § § § § § § § §

libpqのPQfn()を安全でない関数であるとドキュメント記載し、libpq実装内部でも使用しないようになりました。(CVE-2026-6477) (Nathan Bossart) (18)(17)(16)(15)(14)

非整数の結果型に対してPQfn()には出力バッファのサイズが渡されないため、サーバから返ったデータのサイズが一致するか検査できません。悪意のサーバはこれを使ってクライアントのメモリを上書きできました。PQfn()は既に「廃れたもの」とドキュメント記載されていました。

PQfn()をresult_is_int引数に0を指定して使用しているクライアントで危険性を回避するには、使用するAPIを変更するほかありません。

§ § § § §

pg_basebackupとpg_rewindでパス横断が防止されました。(CVE-2026-6475) (Michael Paquier) (18)(17)(16)(15)(14)

これらのアプリケーションでは入力から読み込まれた出力ファイルのパスを検証できていませんでした。そのため、（PostgreSQLサーバ側の）入力を与える悪意の者がこれらのアプリケーションにクライアント側の任意のファイル上書きをさせることができました。これからは絶対パスと親ディレクトリ参照を含むパスを拒絶するようになります。

§ § § § §

contrib/intarrayのquery_int型とcontrib/ltreeのltxtquery型の中で、フィールドのオーバーフローが防止されました。(CVE-2026-6473) (Tom Lane) (18)(17)(16)(15)(14)

16ビットのフィールドがオーバーフローを起こすか検査されていなかったため、これらのデータ型として多すぎる要素数を持つ値を与えると、問合せを実行したバックエンドプロセスのクラッシュが発生する可能性がありました。これから、そのような値は ERROR になります。

§ § § § § § § § § §

contrib/ltreeのlquery型の長すぎる値を防止するようになりました。(CVE-2026-6473) (Michael Paquier) (18)(17)(16)(15)(14)

64Kアイテムを超える値は内部オーバーフローを起こしていて、潜在的にスタック破壊や誤った問い合わせ結果をもたらすおそれがありました。

§ § § § §

contrib/spiでSQLインジェクションとバッファオーバーランが防止されました。(CVE-2026-6637) (Nathan Bossart) (18)(17)(16)(15)(14)

check_foreign_key()関数はキー値のクォート付加が不十分で、また、クエリの組み立てに固定長のバッファを使用していました。このモジュールはサンプルコードにすぎないとはいえ、このような危険な誤りは含まれるべきでないため、修正されました。

§ § § § §

照合順序を適用できる型では、等価条件が一意性を示すものと仮定するのでなく、非決定論的照合順序を検査するようになりました。 (Richard Guo) (18)(17)(16)(15)(14)

多数のプランナ最適化がこれを仮定していました。例えば、一意性インデックスがx列にあれば、ある1行だけが「WHERE x = 'abc'」を満たします。しかしながら、WHERE句にインデックスと異なる照合順序が付加されている場合、この結論は一般には安全ではありません。両方の照合順序が決定論的であるときは文字列の等価がビット単位での等価を意味するため安全ですが、非決定論的な場合にはそのように動作しないため、WHERE句またはインデックスに非決定論的な照合順序が適用される場合に、一意性を前提とした最適化で、誤った問い合わせ結果が返される可能性がありました。

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

結合の削除時に、RestrictInfo構造体内のリレーション参照が完全に削除されない問題が修正されました。 (Tom Lane) (18)(17)(16)

この見落としにより、「ERROR: FULL JOIN is only supported with merge-joinable or hash-joinable join conditions」といった予期しないプランナでのエラーを引き起こすことが判明しています。また、他のケースでも有効なプランが考慮されない原因となっていた可能性がありました。

§ § § § §

プランナによるパーティションキー列とサブクエリ出力の照合が改善されました。 (Richard Guo) (18)

オペランドをパーティションキーと比較する前に、オペランドから何もしない（no-opの）PlaceHolderVarsを削除します。この変更により、以前はパーティションのスキャンが不要であると認識できなかった場合でも、パーティションプルーニングが正常に実行されるようになります。

「ON t1.boolcol」のようなboolean型の列のみで構成される結合句を処理できるように、自己結合の削除処理が修正されました。 (Andrei Lepikhov, Tender Wang, Alexander Korotkov) (18)

以前は、このような場合に「ERROR: no relation entry for relid ...」が発生していました。

仮想生成列を持つテーブルで、カーソルを使った更新「UPDATE/DELETE ... WHERE CURRENT OF」が正常に動作するように修正されました。 (Satyanarayana Narlapuram, Dean Rasheed) (18)

これまでは、実行時に「ERROR: WHERE CURRENT OF on a view is not implemented」が発生する動作が報告されていました。

「INSERT ... ON CONFLICT」内のEXCLUDED列参照における仮想生成列の展開が修正されました。 (Satyanarayana Narlapuram, Dean Rasheed) (18)

不具合によって、予期せぬエラー「ERROR: unexpected virtual generated column reference」が発生したり、誤った問い合わせ結果が発生したりしていました。

ルールアクションおよびルール条件における「NEW」生成列の誤った処理が修正されました。 (Richard Guo, Dean Rasheed) (18)(17)(16)(15)(14)

以前は、このような列参照がINSERTの場合にNULLとなり、UPDATEの場合にはOLDと同じ値になっていました。

（誤動作例）
db1=# CREATE TABLE t21 (id int PRIMARY KEY, a int,
        gen int GENERATED ALWAYS AS (a * 2) VIRTUAL);
db1=# CREATE TABLE t21log (op text, old_gen int, new_gen int);
db1=# CREATE RULE r21i AS ON INSERT TO t21 DO ALSO
        INSERT INTO t21log VALUES ('I', NULL, NEW.gen);
db1=# CREATE RULE r21u AS ON UPDATE TO t21 DO ALSO
        INSERT INTO t21log VALUES ('U', OLD.gen, NEW.gen);
db1=# INSERT INTO t21 (id, a) VALUES (1, 10);
db1=# UPDATE t21 SET a = 100 WHERE id = 1;
db1=# SELECT * FROM t21log;
 op | old_gen | new_gen
----+---------+---------
 I  |  *null* |  *null*
 U  |      20 |      20
(2 rows)

§ § § § §

偽性のエラー「ERROR: indexes on virtual generated columns are not supported」が修正されました。 (Robert Haas) (18)

式インデックスの作成時に、このエラーが誤って報告されることがありました。

偽性のエラー「ERROR: generated columns are not supported in COPY FROM WHERE conditions」が修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

「COPY t23 FROM stdin WHERE tableoid > 0」のように「COPY FROM」のWHERE句でシステム列を使用すると、このエラーが誤って報告されることがありました。アサート有効のビルドでのアサート失敗も報告されました。

§ § § § §

MERGEがrepeatable readモードまたはserializableモードで同時更新されるタプルを検出した場合に、「ERROR: could not serialize access due to concurrent update」を出して直列化失敗を正しく報告するようになりました。 (Tender Wang) (18)(17)(16)(15)

以前は、このような場合により低い分離レベルの場合と同じ動作をしていて、トランザクションがアボートせず、不整合が見過ごされる可能性がありました。

（誤動作例 - 字下げは並行する別セッションをあらわします）
db1=# CREATE TABLE t24 (id int, v int);
db1=# INSERT INTO t24 VALUES (1,0);

　　　db1=# BEGIN;
　　　db1=*# UPDATE t24 SET v = v + 100;

db1=# START TRANSACTION ISOLATION LEVEL serializable;
db1=*# MERGE INTO t24 t USING (VALUES (1, 100)) AS s (id, inc) ON t.id = s.id
         WHEN MATCHED THEN UPDATE SET v = t.v + s.inc
         WHEN NOT MATCHED THEN INSERT (id, v) VALUES (s.id, s.inc);

　　　db1=*# COMMIT;

db1=*# SELECT * FROM t24;
 id |  v
----+-----
  1 |   0
  1 | 200
(2 rows)

db1=*# COMMIT;
db1=# SELECT * FROM t24;
 id |  v
----+-----
  1 | 200
(1 row)

§ § § §

ソーステーブルから列が削除されている場合における「CREATE TABLE ... LIKE ... INCLUDING STATISTICS」の動作が修正されました。 (Julien Tachoires) (18)(17)(16)(15)(14)

LIKEで指定するテーブルが作成後にALTER TABLEで列の削除を行なっているときに該当します。このような場合、拡張統計オブジェクトが正しくコピーされなかったり、コマンドが下記のような予期せぬエラーを返す可能性がありました。

ERROR:  cache lookup failed for attribute 3 of relation 17106

§ § § § §

「ALTER INDEX ... ATTACH PARTITION」で、そうすべき場合には親インデックスを有効とマークできるようになりました。 (Sami Imseih) (18)(17)(16)(15)(14)

すべてのリーフインデックスが有効であるにもかかわらず、パーティションインデックスが無効とマークされたままになる特殊なケースが存在していました。本修正は、ユーザが手動でカタログを更新することなく、このような状況を補正する仕組みを提供します。

§ § § § §

「ALTER TABLE ... SET NOT NULL」がシステムテーブル（カタログ）の変更が完了した後にのみオブジェクトアクセスフック関数を呼び出すように修正されました。 (Artur Zakirov) (18)

これはpg_constraintにNOT NULL制約用の行が追加された際につくられた不具合の修正です。

ALTER FOREIGN DATA WRAPPERが、ラッパーオブジェクトのハンドラ関数への依存関係を削除しないように修正されました。 (Jeff Davis) (18)(17)(16)(15)(14)

以前は、VALIDATORパラメータの指定により、誤ってハンドラ関数への依存関係が削除されていました。

§ § § § §

外部キー制約のトリガーに対する遅延実行指定が効かなくなる問題が修正されました。 (Yasuo Honda) (18)

以前は「DEFERRABLE INITIALLY DEFERRED」として定義された外部キー制約が、「NOT ENFORCED」ステータスに設定された後、再び「ENFORCED」に戻されると「NOT DEFERRABLE」として動作していました。

この問題が発生している外部キー制約がある場合は、本マイナーバージョンアップ適用後に「ALTER TABLE ..」で再度「NOT ENFORCED」に設定してから「ENFORCED」に戻すことで修復できます。

ドメインを許可するように「WITHOUT OVERLAPS」が修正されました。 (Jian He) (18)

「UNIQUE/PRIMARY KEY ... WITHOUT OVERLAPS」で指定する重複しない列は範囲型またはマルチ範囲型である必要がありますが、そのような型を元にしたドメインも許可する必要がありました。これまでは以下のようなエラーになっていました。

（修正前の動作例）
db1=# CREATE DOMAIN dtsrange AS tsrange CHECK (lower(VALUE) IS NOT NULL);
db1=# CREATE TABLE t30 (id int, tsr dtsrange, PRIMARY KEY (id, tsr WITHOUT OVERLAPS));
ERROR:  column "tsr" in WITHOUT OVERLAPS is not a range or multirange type

マルチ範囲型を介して、複合型が再帰的に自身をメンバーとして含むことが禁止されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

これまでも ALTER TABLE ADD COLUMN や ALTER TYPE ADD ATTRIBUTE の際に、ドメイン、配列、複合型、範囲型を通して自身をメンバーとして含まないことを検査していましたが、マルチ範囲型を経由する場合について見落とされていました。

（誤動作例）
db1=# CREATE TYPE typ31 AS (a int, b int);
db1=# CREATE TYPE typ31range AS RANGE (subtype = typ31);
db1=# ALTER TYPE typ31 ADD ATTRIBUTE c typ31range;
→ 修正前は実行できてしまう
　 修正後は「ERROR:  composite type two_ints cannot be made a member of itself」

§ § § § §

Datumのイメージ比較が符号拡張の違いに依存しないよう修正されました。 (David Rowley) (18)(17)(16)(15)(14)

従来は「ERROR: could not find memoization table entry」といったエラーメッセージが出力されたり、誤った問合せ結果を招いていました。

DatumとはSQLの各種データ型の値を格納する汎用的な内部実装上のデータ型です。そのイメージ比較とはビット単位での一致を調べる処理です。

§ § § § §

ハッシュ化された「IN」/「NOT IN」において、非STRICTな等価演算子を使用した場合の処理が修正されました。 (Chengpeng Yan) (18)(17)(16)(15)(14)

これまでは、NULLを空文字と等価とする独自の等価演算子を拡張機能で定義している場合などで、NULLを含む検索時にクラッシュや誤った問い合わせ結果を引き起こす可能性がありました。

なお、組み込みデータ型の等価演算子はすべてSTRICTであるため、この問題は拡張機能で定義されたデータ型でのみ発生します。

§ § § § §

to_char()における、ロケール依存の長すぎる数値記号を切り詰められるようになりました。 (Tom Lane) (18)(17)(16)(15)(14)

to_char()は、パターン内の各フォーマットコードごとに8バイトを見込んで出力バッファを確保しています。ロケールで指定された通貨記号、桁区切り記号、小数点記号、または符号記号が8バイトを超える場合、理論上はバッファオーバーランが発生する可能性がありました。

現実にはそのようなロケールは存在せず、さらに権限のない攻撃者がPostgresSQLサーバ配下に悪意あるロケール定義をインストールするのは現実的ではありませんが、安全性を考慮し、記号が長すぎる場合にはそれを検出し、必要に応じて切り詰めるようになりました。

§ § § § §

「Ispell」辞書用のaffixファイル解析時に発生し得るバッファオーバーランが防止されました。 (Tom Lane) (18)(17)(16)(15)(14)

破損した、あるいは悪意あるaffixファイルによってサーバプロセスがクラッシュする可能性があったため、入力値検証を強化し、異常に長いデータを安全に扱えるよう修正されました。

なお、テキスト検索設定ファイルは信頼できるものと想定されているため、これはセキュリティ問題の扱いにはなりませんでした。

§ § § § § § § § § §

ウィンドウ集約におけるフレーム開始位置および終了位置の計算で、整数オーバーフローが発生しないよう保護されました。 (Richard Guo) (18)(17)(16)(15)(14)

ユーザ指定のオフセット値が非常に大きい場合（INT64_MAXに近い値）、予期せぬエラーや誤った問い合わせ結果を引き起こす可能性がありました。開発用ビルドではアサート失敗も報告されました。

（誤動作例）
db1=# CREATE TABLE t36 (i int);
db1=# INSERT INTO t36 SELECT generate_series(1, 1000) g;
db1=# SELECT sum(i) 
        OVER (ROWS BETWEEN 0x7fffffffffffffff FOLLOWING AND 1 FOLLOWING), i FROM t36;
ERROR:  window frame head moved backward

§ § § § §

array_agg_array_combine()が、配列のNULLビットマップを正しく結合するよう修正されました。 (Dmytro Astapov) (18)(17)(16)

array_agg_array_combine() はarray_agg()集約関数の内部実装で使われている関数です。

この不具合により、NULLと非NULL要素が混在する入力において、並列化されたarray_agg(anyarray)の計算が失敗し、誤った問い合わせ結果が生じるおそれがありました。このエラーは並列ワーカーの実行タイミングに依存するため、再現性の低い不具合として現れていました。

（並列実行プランのときに誤動作が発生する可能性のある問い合わせ例）
db1=# CREATE TABLE t37 (id int, grpid int, c1 int, c2 int, c3 int);
db1=# INSERT INTO t37 SELECT g, g % 10000, 
        nullif(g % 3, 0), nullif(g % 5, 0), nullif(g % 7, 0)
        FROM generate_series(1, 100000) g;
db1=# SELECT grpid, array_agg(ARRAY[c1, c2, c3]) FROM t37 GROUP BY grpid;
　→ この結果が並列実行プランを無効化したときと一致しない場合がある

§ § §

sync_file_range()がエラーコード「EINTR」を返した場合に再試行するようになりました。 (DaeMyung Kang) (18)(17)(16)

これまでは、割り込み発生時のリトライ処理が正しく機能していませんでした。sync_file_range()はファイル書き込みをストレージに反映させるときに使われるLinuxのシステムコールです。

§ § §

共有システムテーブル（カタログ）に対するpg_stat_reset_single_table_counters()の誤動作が修正されました。 (Chao Li) (18)(17)(16)(15)

これまでは、共有システムテーブルに対して同関数を実行すると、現在のデータベースの「stat_reset_timestamp」（pg_stat_databaseシステムビューのstats_reset列で報告される値）が誤って更新されていました。

（誤動作例）
db1=# SELECT now(), pg_stat_reset_single_table_counters('pg_authid'::regclass);
              now              | pg_stat_reset_single_table_counters
-------------------------------+-------------------------------------
 2026-05-22 13:07:49.624814+09 |
(1 row)

db1=# SELECT datname, stats_reset FROM pg_stat_database
        WHERE datname = current_database();
 datname |          stats_reset
---------+-------------------------------
 db1     | 2026-05-22 13:07:49.627562+09
(1 row)

§ § § §

並列applyワーカーがidle状態のときにアクティビティ統計を更新するようになりました。 (Zhijie Hou) (18)(17)(16)

これまでは、直近に完了したトランザクションの統計情報が長時間報告されない場合があり、特にワークロードが軽い環境で顕著でした。

§ § §

集合演算で配列長を推定中するときに、予期せぬエラー「ERROR: no relation entry for relid 0」が発生することがあり、修正されました。 (Tender Wang) (18)(17)

UNIONなどの集合演算で、元となる型の異なる配列型を型変換する場合に発生することがありました。

（発生例）
db1=# SELECT null::int[] UNION ALL SELECT null::int[] UNION ALL SELECT null::bigint[];
ERROR:  no relation entry for relid 0

§ §

pglz_decompress()が破損した入力を受け取った場合にバッファの超過読み取りが発生することがあり、修正されました。 (Andrew Dunstan) (18)(17)(16)(15)(14)

pglz_decompress()はpglz形式の圧縮データを展開する内部実装関数です。破損した圧縮データによって入力末尾を越えた読み取りが発生する可能性があり、ごくまれにクラッシュを引き起こすおそれがありました。

§ § § § §

インクリメンタルJSONパーサにおいて、入力バッファの境界をまたぐ数値トークンの処理が修正されました。 (Andrew Dunstan) (18)(17)

JSON数値の文法に反する不正な形式の数値を受け入れてしまう可能性があり、その結果として後の処理でエラー（「ERROR: invalid input syntax for type json」など）が発生することがありえました。デバッグ用ビルドではアサート失敗を引き起こしました。

§ §

インクリメンタルバックアップのリストア時に、リレーションの可視性マップが肥大化することがあり、防止されました。 (Robert Haas) (18)(17)

このリストア処理では、期待されるファイル長の計算が誤っていたため、可視性マップに多数のゼロブロックが追加される可能性がありました。これはデータ破損にはつながりませんが、大量のディスク領域を無用に消費する可能性がありました。

§ §

カタログキャッシュのテキスト列検索において、データベースのデフォルト照合順序ではなく、C照合順序が使用されるようになりました。 (Jeff Davis) (18)(17)

これにより、データベースが特定できずデフォルト照合順序も決定できない特殊ケースでも、物理レプリケーションが開始できるようになります。pg_receivewalによるレプリケーション接続の開始時に「FATAL: cannot read pg_class without having selected a database」が発生するケースが報告されました。

§ §

スタンバイサーバ昇格時に、応答待ちのまま停止したslotsyncワーカープロセスが昇格処理をブロックする問題が修正されました。 (Nisha Moond, Ajin Cherian) (18)(17)

プライマリサーバからの応答を待ち続けていたワーカープロセスにより、昇格処理が不必要に長時間遅延することがありました。

§ § § § § §

アイドル状態のslotsyncワーカープロセスによる過剰なログ出力が修正されました。 (Zhijie Hou) (18)(17)

§ §

tuplestoreデータ構造で、エラー発生後に内部状態の不整合が生じないようになりました。 (Tom Lane) (18)(17)(16)(15)(14)

通常は問題になりませんが、WITH HOLDカーソルのtuplestoreでは問題となる可能性がありました。PostgreSQL 15以前では、この問題により容易に再現可能なクラッシュが発生することがありました。PostgreSQL 16以降での影響は確認されていませんが、すべてのサポートバージョンで内部状態の整合性が保たれるよう修正されました。

§ § § § §

pg_aiosシステムビューのpid列が、所有プロセスが存在しない場合に0ではなくNULLを示すようになりました。 (ChangAo Chen) (18)

pg_stat_replicationのlag列が実際より早い段階でNULLと報告されてしまう問題が修正されました。 (Shinya Kato) (18)(17)(16)(15)(14)

特に論理レプリケーション環境で、レプリケーション処理中であるにもかかわらず、過度に早くNULLとなることがありました。

§ § § § §

並列Btreeインデックススキャンで使用される共有メモリの割り当て不足が修正されました。 (Siddharth Kothari) (18)

稀なケースで、この共有メモリの割り当て不足によりサーバがクラッシュする可能性がありました。

WAL出力無しのGiSTインデックスを使用する際に、稀に発生するフラッシュ失敗を回避するようになりました。 (Tomas Vondra) (18)(17)(16)(15)(14)

WAL出力無しのGiSTインデックスにおいて、挿入ポイントを表す擬似LSNの選択が不適切であったため、誤って「ERROR: xlog flush request n/nnnn is not satisfied」が発生することがありました。（なお、ここでのWAL出力無しはUNLOGGEDテーブルを意味していません。）

§ § § § §

変則的なサイズのセグメント使用時に、DSAページマップの必要サイズの過小評価が修正されました (Paul Bunn) (18)(17)(16)(15)(14)

この計算ミスにより、範囲外アクセスが発生し、サーバがクラッシュする可能性がありました。

§ § § § §

共有メモリ内における最も古いマルチトランザクション配列のインデックス計算が修正されました。 (Yura Sokolov) (18)(17)

PREPARED状態であるが、未コミットのトランザクションが保持する行ロックが他セッションから見えなくなるなど、可視性の不整合が発生する可能性がありました。また、max_connectionsが非常に小さい場合には、メモリ破壊が発生する可能性もありました。

§ § § §

多数のEXPLAIN拡張オプションを登録した場合に発生する配列オーバーランが修正されました。 (Joel Jacobson) (18)

この問題により、メモリ破損やサーバプロセスのクラッシュが発生する可能性がありました。

拡張データ型の式に対する拡張統計情報処理時にクラッシュが発生する可能性があり、修正されました。 (Michael Paquier) (18)(17)(16)(15)(14)

データ型のtypanalyze関数が有効な統計情報を生成しない場合、NULLポインタ参照が発生する可能性がありました。PostgreSQL本体のtypanalyzeでは発生しませんが、拡張機能では発生する可能性がありました。

§ § § § §

GROUP BY句で使用される結合エイリアス変数を正しく表示するよう修正されました。 (Tom Lane) (18)

「SELECT ... t1 LEFT JOIN t2 USING (x) GROUP BY x」のようなクエリを含むビューにおいて、GROUP BY句のSQL文が内部からの逆解析時に誤って表示され、データベースのダンプ/リストアが失敗する可能性がありました。この問題は、「t1.x」と「t2.x」のデータ型が同一ではなく、「t1.x」側で暗黙的な型変換が必要だった場合にのみ発生しました。

（誤動作例）
db1=# CREATE TABLE t1 (x integer, a numeric);
db1=# CREATE TABLE t2 (x bigint, b text);
db1=# CREATE VIEW test_view AS SELECT x::integer AS x FROM t1 LEFT JOIN t2 USING (x) GROUP BY x;
（18.3以前では、以下のように誤ったSQLへ逆解析される）
db1=# SELECT pg_get_viewdef('test_view'::regclass, true);
       pg_get_viewdef
-----------------------------
  SELECT t1.x::integer AS x +
    FROM t1                 +
      LEFT JOIN t2 USING (x)+
   GROUP BY (t1.x::bigint);
(1 row)

（この状態でダンプしリストアすると、以下のようなエラーが発生する）
$ pg_dump db1 > dump.sql
$ psql restore_test < dump.sql
ERROR:  column "t1.x" must appear in the GROUP BY clause or be used in an aggregate function
LINE 2:  SELECT (t1.x)::integer AS x

ICUを使用した文字列処理における、軽微なメモリリークが修正されました。 (Jeff Davis) (18)(17)(16)

§ § §

startupプロセス失敗時に、他の子プロセスを適切にシャットダウンするよう修正されました。 (Ayush Tiwari) (18)(17)(16)(15)

従来は「startupプロセス実行中は他のpostmaster子プロセスは存在しない」という古い前提に依存しており、postmasterの即時終了でも問題ないとされていました。残存した子プロセスも最終的にはpostmasterの終了を検知して自主的に終了しますが、より適切なシャットダウン手順が望まれていました。

§ § § §

チェックポイントのWALリプレイ処理とマルチトランザクションID生成の間に存在する競合状態が修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

古いマイナーバージョンのプライマリからWALを追従するスタンバイサーバにおいて、「ERROR: could not access status of transaction」というエラーを伴うクラッシュおよび再起動ループが発生する可能性がありました。

§ § § § §

walsenderプロセス終了時に無限待機状態となりうる不具合が修正されました。 (Anthonin Bonnefoy) (18)(17)(16)(15)(14)

論理レプリケーションのパブリッシャ側のPostgreSQLを停止する際に、walsenderプロセスは未書き込みのWALがすべて書き出されるまで待機します。しかし、その書き出し要求が正しく行われていなかったため、状況によっては待機が終了せず、無限に停止処理が続く場合がありました。

§ § § § § § § § § §

リカバリ中にテーブルの空き領域マップ（FSM）の変更内容が確実に保持されるように修正されました。 (Alexey Makhmutov) (18)(17)(16)(15)(14)

これまでは、WALリプレイ時にFSMの更新自体は行われていたものの、チェックサムが有効な場合に、FSMページのバッファがダーティページとして印付けされていませんでした。そのため、変更内容がディスクへ書き出されず、反映されない場合がありました。

スタンバイサーバでは、この問題により時間の経過とともにFSMの内容が実際のテーブル状態と大きく乖離することがありました。FSMはあくまでヒント情報として使用されるだけですが、スタンバイサーバがアクティブに昇格した際、FSMの大部分が更新によって修復されるまでの間、大きく性能低下するおそれがありました。

§ § § § §

ecpgプリプロセッサで、接続が確立されていない状態で一部の関数を呼び出した場合に、クラッシュする不具合が修正されました。 (Shruthi Gowda) (18)(17)(16)(15)(14)

ECPGdeallocate_all()、ECPGprepared_statement()、ECPGget_desc()、および、ecpg_freeStmtCacheEntry()でセグメンテーション違反が生じました。

§ § § § §

pg_basebackupおよびpg_verifybackupでtarファイルの読み込み処理が強化されました。 (Tom Lane) (18)

これまでは、入力ファイルがtarファイルであるかどうか、さらにPostgreSQLが処理可能なtar形式かどうかの検証が十分に行われていませんでした。そのため、PostgreSQLではない他のtar作成ツールによって生成されたtarファイルを入力とした場合、想定外の形式であることで問題が生じる可能性がありました。

pg_basebackupおよびpg_verifybackupでバックアップの展開およびtar読み込み処理における各種バグが修正されました。 (Andrew Dunstan, Tom Lane, Chao Li) (18)(17)(16)(15)

具体的には、tarファイルのパディング領域の扱いの不備、特殊ケースにおいてLZ4圧縮データが破損する可能性、一部の異常系エラー条件の検査漏れ、圧縮／展開のエラー発生後に終了しないことによる連鎖的なエラー報告、メモリリークの発生、ということが含まれます。

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

pg_dumpにおいて、NOT NULL制約のNO INHERIT属性が正しく保持されるように修正されました。 (Jian He) (18)

これまでは、一部のケースでNO INHERIT句がダンプ出力されませんでした。

pg_dumpallにおいて、OIDが存在しないロールが権限を与えた場合にもGRANT文を出力するように、修正されました。 (Tom Lane) (18)(17)(16)

これまでは、このような状態のGRANTがダンプ対象から除外される場合がありました。今回の修正で、PostgreSQL v16より前と同様に、GRANTED BY句を付けずにGRANT文を出力するよう変更されました。

なお、権限を与えたロールのOIDが存在しないことに対する警告メッセージは引き続き出力されますが、警告を出すのはソースサーバがPostgreSQL v16以降の場合のみに限定されます。

§ § §

pg_upgradeにおいて、古いソースサーバへ接続する際に正しいプロトコルバージョンを使用するように修正されました。 (Jacob Champion) (18)(17)(16)(15)(14)

これまでは、2018年2月のマイナーリリース（10.2、9.6.7、9.5.11、9.4.16、9.3.21）よりも古いPostgreSQLサーバからアップグレードを行う場合に、不具合が発生する可能性がありました。

「FATAL: unsupported frontend protocol ...」が発生するケースが報告されました。

§ § § § §

contrib/basic_archiveが、起動時にアーカイブディレクトリが存在しなくてもよくなりました。 (Nathan Bossart) (18)(17)(16)(15)

これまでは、起動時点でbasic_archive.archive_directoryに指定したディレクトリが存在しない場合、その設定自体が無効なものとして扱われました。今回の修正により、起動時点でディレクトリが存在しなくても、後からディレクトリが作成された場合にアーカイブ処理を継続できるようになりました。

§ § § §

contrib/ltreeが、大文字小文字のフォールドで文字列のバイト長が変化する場合に対応できるように修正されました。 (Jeff Davis) (18)(17)(16)(15)(14)

これまでは、大文字小文字を区別しないマッチングを指定するlqueryパターンにおいて、本来一致するはずのラベルにマッチしない場合がありました。

§ § § § § §

contrib/pg_overexplainにおいて、RANGE_TABLEオプションの出力構造の不具合が修正されました。 (Satyanarayana Narlapuram) (18)

これまでは、JSON、YAML、XML形式の出力で一部のフィールドが誤った位置に出力される場合がありました。

contrib/pg_stat_statementsで、pgss_query_texts.statファイルの解析中にエラーが発生した時に、メモリリークが発生しないように修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

§ § § § §

contrib/postgres_fdwにおいて、利用不能になった接続を早期に解放してしまうことでクラッシュすることがあり、修正されました。 (Etsuro Fujita) (18)(17)(16)(15)(14)

オープン中のカーソルなどのデータ構造に接続オブジェクトへの参照が残っている可能性があるため、トランザクション終了まで接続オブジェクトのクローズを遅延させるようになりました。

§ § § § §

タイムゾーンデータファイルがtzdata release 2026bに更新されました。 (Tom Lane) (18)(17)(16)(15)(14)

ブリティッシュコロンビア州（America/Vancouver）は、2026年11月から通年でUTC-07を使用するようになります（事実上の恒久的な夏時間）。同地域のタイムゾーン略称がそれ以降「MST」になると想定しています。実際には別の略称へ変更される可能性もありますが、現時点では未確定です。

モルドバの歴史的変更も行なわれました。モルドバは2022年以降、EUの夏時間切替時刻に従っていたことが反映されました。

§ § § § §

SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

PostgreSQL 17.9 に関する技術情報

データベース技術グループ — Fri, 06 Mar 2026 02:14:41 +0000

このリリースは 17.8 からの修正リリース（2026年 2月 26日リリース）です。
17.X からのアップデートではダンプ、リストアは不要です。
しかしながら、17.6 よりも前のバージョンからアップデートする場合には、17.6のリリース情報も参照してください。

PostgreSQL 17.8 から 17.9 への変更点

18.3, 17.9, 16.13, 15.17, 14.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。

古いマイナーバージョンで生成された、マルチトランザクションIDの切り詰めを行うWALレコードをリプレイした後にエラーが発生する問題が修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

以前のバージョンにおけるマルチトランザクションID周回への対処ロジックに誤りがあったため、「ERROR: could not access status of transaction」といったエラーを伴うWALリプレイ失敗が発生していました。

この問題が発生する典型的なシナリオとしては、最新のマイナーバージョンのスタンバイサーバが、旧バージョンのプライマリサーバから送られてくるWALをリプレイする場合があります。

§ § § § §

TOASTとして保存されたデータに対してsubstring()関数を適用したときに、無効なエンコーディングであると誤判定される問題が回避されました。 (Noah Misch) (18)(17)(16)(15)(14)

CVE-2026-2006に対する修正が過度に厳格であったため、実際には正しい文字列であっても不完全な文字と判定される可能性がありました。

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

CVE-2026-2007に対する修正の見落としがあり、再修正されました。 (Zsolt Parragi) (18)

pg_trgm拡張のstrict_word_similarity()関数や関連する関数が誤った問合せ結果を返す可能性があり、まれにクラッシュを引き起こすこともありました。ICUロケールにて、いくつかのシングルバイトエンコーディングを使用している場合に、現象発生が確認されています。

類似度関数への入力に、初期見積もりより多くのトライグラムが含まれていて、内部処理で使われる単語境界情報を保存するための配列を拡張する必要があった場合に、実装の不備がありました。

UPDATE pg_catalog.pg_proc SET provolatile = 'i' WHERE oid IN ('3261','3262');

組み込み関数json_strip_nulls()とjsonb_strip_nulls()の変動性区分が修正されました。 (Andrew Dunstan) (18)

これらの関数はIMMUTABLEと分類されていましたが、バージョン18でのリファクタリングにより誤ってSTABLEと分類されました。この不具合により、インデックス式での使用が妨げられ、クエリ内で不要な評価が繰り返されるおそれがありました。

本修正により、新しく初期化されたデータベースクラスタ（18.3以降にpg_upgradeされたクラスターを含む）で関数定義が修正されます。ただし、18.0～18.2を使用して作成された既存のクラスタには役立ちません。既存のクラスタでこの間違いを修正する場合に推奨される方法は手動カタログ更新です。その方法はスーパーユーザとして影響を受ける各データベースで以下を実行することです。

UPDATE pg_catalog.pg_proc SET provolatile = 'i' WHERE oid IN ('3261','3262');

今後作成されるデータベースにも修正が適用されるようにするには、テンプレートデータベース（template0、template1）でこれを行なってください。

「LATERAL UNION ALL」を含むサブクエリを外部結合する場合に、サブクエリ内でNULLになる可能性があるかの判定が修正されました。 (Richard Guo) (18)(17)(16)

この不具合により、「NOT NULL」テストが不要とされ「NOT NULL」テストがスキップされることで、誤ったクエリ結果を返す可能性がありました。

§ § §

NOT NULL制約に自動で付けられる名前が、既にユーザが定義した名前と競合する可能性がなくなりました。 (Laurenz Albe) (18)

バージョン18では、NOT NULL制約はpg_constraintに追加されたため、制約名が存在します。これまでは、NOT NULL制約に自動で付けられていた名前が、同じCREATE TABLE文内のユーザ作成の名前と競合して、ユニーク制約違反のエラーが発生していました。

（エラー発生例）
db1=# CREATE TABLE t6 (col int NOT NULL,
        CONSTRAINT t6_col_not_null CHECK (col IS NOT NULL));
ERROR:  duplicate key value violates unique constraint "pg_constraint_conrelid_contypid_conname_index"
DETAIL:  Key (conrelid, contypid, conname)=(16556, 0, t6_col_not_null) already exists.

関数pg_stat_get_backend_wait_event()とpg_stat_get_backend_wait_event_type()が補助プロセスの情報を返すように修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

これまでは、これらの関数は補助プロセスに対してNULLを返していましたが、これはpg_stat_activityビューとの一貫性に欠けていました。

§ § § § §

PL/pgSQL関数から返す変数を複合型からドメイン型へのキャストする場合について修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

変数値がNULLであった場合に「ERROR: cache lookup failed for type 0」エラーが発生することがありました。

§ § § § §

contrib/hstoreのバイナリ入力関数で潜在的にNULLポインタアクセスの可能性があり、修正されました。 (Michael Paquier) (18)(17)(16)(15)(14)

hsore型のレシーブ関数は重複キーを含む入力でクラッシュを起こしていました。PostgreSQLによって生成されたhstoreの値が重複キーを含むことがないため、誤りが見過ごされていました。クラッシュは悪意のデータや壊れたデータで引き起こされます。

§ § § § §

SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

PostgreSQL 17.8 に関する技術情報

データベース技術グループ — Fri, 27 Feb 2026 05:03:19 +0000

このリリースは 17.7 からの修正リリース（2026年 2月 12日リリース）です。
17.X からのアップデートではダンプ、リストアは不要です。
しかしながら、17.6 よりも前のバージョンからアップデートする場合には、17.6のリリース情報も参照してください。

PostgreSQL 17.7 から 17.8 への変更点

18.2, 17.8, 16.12, 15.16, 14.21 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。

予期せぬ次元のoidvectorやint2vectorを防止するようになりました。(CVE-2026-2003) (Tom Lane) (18)(17)(16)(15)(14)

これらのデータ型はNULLを含まない1次元配列を想定していますが、それを破るキャスト経路がありました。これによりクラッシュやサーバメモリ暴露を含む誤動作を引き起こす可能性がありました。

（誤動作例：本来はエラーになるべき）
db1=# SELECT ARRAY[ARRAY[1,2,3],ARRAY[4,5,6]]::int2vector;
 array
-------
 1 0
(1 row)

§ § § § §

予期せぬデータ型を受け入れる演算子に付加される選択率推定が厳格化されました。(CVE-2026-2004) (Tom Lane) (18)(17)(16)(15)(14)

contrib/intarray拡張に含まれる選択率推定関数は、入力が想定したデータ型であるか検査していなかったため、任意コード実行のために悪用される恐れがありました。サードパーティ拡張は類似の危険に備えて、intarrayと同様の技法で検査し防御を加えるべきです。

そのような拡張で対応が行なわれるまで時間がかかるため、今後は、演算子に非組み込みの選択率推定関数を付加するためにスーパーユーザ―権限が必要になりました。

そのため、新たなデータ型や演算子を導入する拡張を一般ユーザで導入（CREATE EXTENSION）する運用をしている場合に、これからはスーパーユーザで行う必要が生じるかもしれません。

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

contrib/pgcryptoのPGP復号化関数でバッファオーバーランが修正されました。(CVE-2026-2005) (Michael Paquier) (18)(17)(16)(15)(14)

作りこまれたメッセージを長すぎるセッションキーで復号化すると、バッファオーバーランが起きて、これによる任意コード実行も可能でした。

§ § § § §

マルチバイト文字長の不十分な検証が修正されました。(CVE-2026-2006) (Thomas Munro, Noah Misch) (18)(17)(16)(15)(14)

いくつかのバグのため、攻撃者が作りこまれたSQLを発行して文字列のバッファオーバーランを起こすことができて、これによる任意コード実行も可能でした。

本修正後は、文字列関数がデータベース内に既に格納されている不正なテキストを処理するときに「ERROR: invalid byte sequence for encoding」のエラーが発生するようになります。

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

contrib/pg_trgmで文字列の小文字化の振る舞いについて厳格化されました。(CVE-2026-2007) (Heikki Linnakangas) (18)

PostgreSQL 18以降では、一部のロケールにおいて文字列の小文字化で（バイト数でなく）文字数が増えることがあります。それによる潜在的なバッファオーバーランの危険性があり、修正されました。

§ §

contrib/ltreeで大文字小文字を区別しないマッチの一貫性の欠如が修正されました。 (Jeff Davis) (18)

ltreeのインデックス関係ルーチンはケースフォールドに元となる演算子とは異なる実装を使っていました。これらが一致した動作をするのは、デフォルト照合順序プロバイダがlibcのシングルバイト文字エンコーディングのときだけでした。

データベースのデフォルト照合順序のケースフォールドを使うように修正されました。データベースが照合順序プロバイダにlibcのシングルバイト文字エンコーディングを使っていないなら、本修正を含むバージョンアップ後に、インデックスアクセスメソッドが何であれ、ltree型の列を含むインデックスを再構築する必要があります。さもないと、誤った検索結果が生じるおそれがあります。

§ §

「ALTER TABLE ... ADD CONSTRAINT」で名前を付けてNOT NULL制約を加えるときに、その列に別の名前のNOT NULL制約が既にあった場合にはエラーを出すようになりました。 (Alvaro Herrera, Srinath Reddy Sadipiralla) (18)

これまでは、NOT NULL制約名は元のままで何も行われませんが、エラーも出ませんでした。同名のNOT NULL制約を加えようとした場合には、これまで通り、何も行われず、エラーも出ない動作をします。

副問合せでのCTE参照が集約関数のセマンティックレベルを決定することが禁止されました。 (Tom Lane) (18)(17)(16)(15)(14)

本修正で、外側の集約では入れ子のCTEを使用できないものとして「ERROR: outer-level aggregate cannot use a nested CTE」エラーを出すようになりました。これまでは予期せぬ「ERROR: unexpected outer reference in CTE query」エラーが場合によっては出るという動作でした。

本修正は以前のマイナーリリースでの変更（17.7等の 56番）を取り消すものです。標準SQLでは集約内の副問合せは完全に禁止されているため、このようなケースはエラーとして扱えば十分と判断されました。

（問題が生じる問合せ形状の例：これからは以下のSELECT文はエラーになる）
CREATE TABLE t8 (c1 int);
INSERT INTO t8 VALUES (1), (2), (3);
SELECT c1, (WITH cte1(x,y) AS (SELECT 1,2) 
  SELECT count((SELECT t8.c1 FROM cte1))) AS ss FROM t8;

§ § § § §

CTE問合せでのMERGEの変更内容取得について、トリガの遷移表が修正されました。 (Dean Rasheed) (18)(17)(16)(15)

文単位のAFTERトリガを伴うテーブルに対し、MERGEと別のDML操作の両方を含みデータ変更を行うCTE問合せを実行すると、トリガに渡される遷移表には、MERGEで変更される行が含まれず、他のDML操作で変更される行だけが含まれました。

（以下のWITH句付きMERGE文は2行のINSERTが生じるが、これまでは、
  t9テーブルのINSERT文のトリガに渡される遷移表には1行しか含まれなかった。)
CREATE TABLE t9 (a int);
WITH cte1 AS (INSERT INTO t9 VALUES (1))
  MERGE INTO t9 USING (VALUES (2)) AS v(a) ON t9.a = v.a
    WHEN NOT MATCHED THEN INSERT VALUES (v.a);

§ § § §

エグゼキュータで、副問い合わせなどテーブル以外の処理対象エントリに属するrowmarkの誤った除外が修正されました。 (Dean Rasheed) (18)

rowmarkは行ロックや可視性制御のための内部的に使われるメタデータです。

この誤りにより、問合せ対象テーブルの更新が並行している場合に、VALUESやCTE（WITH句）、サブクエリを伴う、MERGEやUPDATE、DELETEで、誤った問い合わせ結果が生じる可能性がありました。想定される行の更新について、EvalPlanQual再チェックを要する場合に該当します。

EvalPlanQual再チェックは主としてREAD COMMITTEDトランザクション分離レベルで実行される内部処理です。

UPDATEまたはDELETEの対象となるパーティションテーブルのすべての子テーブルが除外されている場合に発生するエラーが修正されました。 (Amit Langote) (18)(17)(16)(15)(14)

このような場合、何もする必要がないにもかかわらず、エクゼキュータが「ERROR: could not find junk ctid column」を報告する可能性がありました。

外部テーブルを子テーブルとしている場合に現象が報告されました。

§ § § § §

配列添字内の副問い合わせに対する式評価の誤りが修正されました。 (Andres Freund) (18)

不具合により、誤った問い合わせ結果が返ったり、バックエンドプロセスのクラッシュが生じることがありました。

（障害を起こす問合せ例 - いずれも 18.1 ではクラッシュする）
db1=#  SELECT (array[1,2])[(SELECT g.i)] FROM generate_series(1, 1) g(i);
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

db1=# SELECT (array[1,2])[(SELECT g.i):(SELECT g.i + 1)] FROM generate_series(1, 1) g(i);
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

非決定論的照合順序におけるテキストの部分文字列検索が修正されました。 (Laurenz Albe) (18)

非決定論的照合順序を使用する場合、検索文字列の末尾で発生する一致を検出できませんでした。

（誤動作例： 'testx'の末尾の'x'がマッチせず、'y'への置換に失敗する）
db1=# CREATE COLLATION test_nondeterministic (
        provider = icu, locale = 'und-u-ks-level2', deterministic = false);
db1=# SELECT replace(
        'testx' COLLATE "test_nondeterministic",
        'x'     COLLATE "test_nondeterministic", 'y') AS res1;
 res1
-------
 testx
(1 row)

クエリに重複したウィンドウ関数呼び出しが含まれる場合に発生する可能性のある、プランナエラーが回避されました。 (Meng Zhang, David Rowley) (18)(17)(16)

このような呼び出しの重複排除に関する混乱により、「ERROR: WindowFunc with winref 2 assigned to WindowAgg with winref 1」といったエラーを引き起こす可能性がありました。

§ § §

集合を返す関数とグルーピングセットに関するプランナのエラーが修正されました。 (Richard Guo) (18)

ProjectSetプランノードを構築するとき、グループ化式を含む部分式が入力プランによって既に計算済みであることを検出できませんでした。これにより、非効率的なプランや、「ERROR: variable not found in subplan target list」などのエラーが発生していました。

（障害動作例）
db1=# CREATE TABLE t18 (id int, brands text[], markets text[]);
db1=# INSERT INTO t18 VALUES (1, '{Brand A,Brand B}', '{Market A}'),
                             (2, '{Brand B,Brand C}', '{Market B}'),
                             (3, '{Brand A}', '{Market A,Market B}');
db1=# SELECT brands, unnest(markets) AS market, count(DISTINCT id) FROM t18
        GROUP BY GROUPING SETS (brands, market, ())
        ORDER BY brands ASC, market ASC;
ERROR:  variable not found in subplan target list

（正しい結果）
        brands         |  market  | count
-----------------------+----------+-------
 {"Brand A"}           |          |     1
 {"Brand A","Brand B"} |          |     1
 {"Brand B","Brand C"} |          |     1
                       | Market A |     2
                       | Market B |     2
                       |          |     3
(6 rows)

副問い合わせのGROUPING句にVOLATILE関数または集合を返す関数が含まれる場合の、誤った最適化が回避されました。 (Richard Guo) (18)

プランナが、このようなグループ化された列を参照する外部クエリの制約をプッシュダウンしようとしたため、VOLATILE関数の多重評価による不正な動作や、副問い合わせのWHERE/HAVING句に集合を返す関数の導入することによるエラーが発生していました。

（誤動作例）
db1=# CREATE TABLE t16 (id serial8, j json);
db1=# INSERT INTO t16 (j) VALUES ('[{"animal": "cats"}, {"animal": "dogs"}]');
db1=# SELECT animal FROM (
        SELECT json_array_elements(j) ->> 'animal' animal,
		  count(*) FROM t16 GROUP BY 1) x WHERE animal LIKE 'c%';
ERROR:  set-valued function called in context that cannot accept a set

（正しい結果）
 animal
--------
 cats
(1 row)

式に関する統計情報を検索するときに、PlaceHolderVarノードを詳しく調べるようになりました。 (Richard Guo) (18)

この変更により、プランナは副問い合わせからプルアップされた式やGROUP BYで使われる式について関連する統計情報を見つけられるようになり、デフォルト推定値で代用することを回避できます。

これまで、式の統計情報を見つけられず実行プランが劣化することがありえました。この制限は古くからあるものの、以前のバージョンで問題の報告が無いため、18.x系列以降のみが修正対象となりました。

式をインデックスと照合する際に、no-op（何もしない）のPlaceHolderVarノードを調べるようになりました。 (Richard Guo) (18)

PostgreSQL 18では、PlaceHolderVarが以前より多用されるため、従来インデックスを使用できた一部のクエリでインデックスを使用できなくなっていました。この退行を防ぐためにロジックが追加されました。

PlaceHolderVarはPostgreSQLのプランナの実装で使われている構造体変数です。

プランナのOR句からScalarArrayOpインデックス条件への変換が修正されました。 (Tender Wang, Tom Lane) (18)

コードがRelabelTypeノードを正しく処理せず、無効な式を生成したり、有効な変換を実行できなかったりすることがありました。潜在的に予期せぬエラーや誤った問い合わせ結果が生じる可能性があります。

（問題が生じる問い合わせ例）
db1=# CREATE TYPE typ19 AS (r float8, i float8);
db1=# CREATE TABLE t19 (f1 typ19 PRIMARY KEY);
db1=# INSERT INTO t19 SELECT (x, x+1)::typ19 FROM generate_series(1,10000) x;
db1=# ANALYZE t19;
db1=# EXPLAIN SELECT * FROM t19 WHERE f1 = (1,2)::typ19 OR f1 = (3,4)::typ19;
                                QUERY PLAN
---------------------------------------------------------------------------
 Index Only Scan using t19_pkey on t19  (cost=0.29..12.61 rows=2 width=37)
   Index Cond: (f1 = ANY ('{"(1,2)","(3,4)"}'::typ19[]))
(2 rows)

　→ 修正前バージョンでは Bitmap Heap/Index Scan と BitmapOr のプランになり、
　　 上記のように効率的な配列へのインデックス検索に変換されない。

インデックスの述語がWHERE句が真であることを暗示する場合でも、部分ハッシュインデックスでのIndex Scanができるようになりました。 (Tom Lane) (18)(17)(16)(15)(14)

通常、プランナは述語によって暗黙的に示されるWHERE句を削除します。なぜなら、すべてのインデックスエントリに対して必ず成立するため、テストする意味がないからです。しかし、ハッシュインデックスのように先頭インデックスキーにWHERE句を必要とするインデックスの場合、この処理がIndex Scanプランの作成を妨げる可能性がありました。このようなインデックスを検討するときにはWHERE句を削除しないようになりました。

（問題が生じる問い合わせ例）
db1=# CREATE TABLE t20 AS SELECT generate_series(1, 1000)::int x;
db1=# CREATE INDEX idx20 ON t20 USING hash (x) WHERE x = 1;
db1=# ANALYZE t20;
db1=# EXPLAIN SELECT x FROM t20 WHERE x = 1;
                           QUERY PLAN
-----------------------------------------------------------------
 Index Scan using idx20 on t20  (cost=0.00..8.02 rows=1 width=4)
   Index Cond: (x = 1)
(2 rows)

　→ 修正前バージョンでは、これが Seq Scan の実行プランになってしまう

§ § § § §

UNLOGGEDのBRINインデックスに対してWALを出力しないようになりました。 (Kirill Reshke) (18)(17)(16)(15)(14)

めったに使用されないコードパスの1つで、インデックスがUNLOGGEDとマークされている場合でも、BRINインデックスに関連するWALレコードが誤って出力されていました。その結果、クラッシュリカバリで「FATAL: could not create file "base/5/32819": File exists」といったエラーが発生して、WALレコードのリプレイに失敗していました。

§ § § § §

並列GINインデックス構築で正しい順序付け関数を使用するようになりました。 (Tomas Vondra) (18)

並列コードでは、デフォルトの順序付け演算子（列のデータ型のbtree演算子クラスによって決定される）が使用されていましたが、gin演算子クラスで指定された順序付け関数を（それがあるなら）使用する必要がありました。これにより、データ型にbtree演算子クラスが存在しない場合はエラーになり、演算子クラスが適合しない順序付け関数を指定している場合には無効なインデックスが生成される問題が発生していました。

未読のNOTIFYメッセージによってまだ必要とされるCLOGの切り捨てが防止されました。 (Joel Jacobson, Heikki Linnakangas) (18)(17)(16)(15)(14)

これまで、バックエンドによるNOTIFYメッセージの吸い上げが遅いときに「ERROR: could not access status of transaction」エラーが発生することがありました。

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

NOTIFYメッセージ処理中のエラー発生を、FATALにエスカレートする、すなわち、コネクション切断するようになりました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

以前は、バックエンドがNOTIFYメッセージの受信中にエラーを検出すると、そのメッセージを読み飛ばし、クライアントにエラーを報告して処理を続行していました。

しかし、この動作には多くの問題がありました。大きな懸念点の一つは、クライアントが通知の喪失を知る適切な手段がなく、ましてやその内容を知る手段がないことです。アプリケーションロジックによっては、通知が失われるとアプリケーションが待機状態になってしまう可能性がありました。また、残りのメッセージは誰かが新しいNOTIFYを送信するまで処理されません。さらに、NOTIFY信号受信時に接続がアイドル状態の場合、無関係な理由によりERRORは常にFATALにエスカレートされていました。

一貫性を保ち、アプリケーションに通知が失われた可能性があることを明確に伝えるため、本修正が選択されました。

§ § § § §

クエリIDのハッシュを計算する際に、グループ化式を考慮するようになりました。 (Jian He) (18)

以前は、GROUP BYの式を除いて同一の2つのクエリが、contrib/pg_stat_statementsやその他のクエリIDを利用ツールにおいて、誤って統合されていました。

（pg_stat_statementsの問題となる動作例）
db1=# CREATE TABLE t25 (id int, g1 int, g2 int)
db1=# SELECT count(*), max(g1) g1, max(g2) g2 FROM t25 GROUP BY g1;
db1=# SELECT count(*), max(g1) g1, max(g2) g2 FROM t25 GROUP BY g2;
db1=# SELECT queryid, query, calls FROM pg_stat_statements WHERE query ~ 't25 GROUP BY';
       queryid       |                            query                             | calls
---------------------+--------------------------------------------------------------+-------
 2402898342116734224 | SELECT count(*), max(g1) g1, max(g2) g2 FROM t25 GROUP BY g1 |     2
(1 row)
　→ 修正後は異なるステートメントと解釈されて2行が出力される

同時の更新と共に「EXPLAIN ANALYZE MERGE ...」を行なった際に、更新回数が誤ってカウントされる問題が修正されました。 (Dean Rasheed) (18)(17)

EXPLAINの出力でスキップされた(skipped)タプルの数が誤っていたり、アサートが有効なビルドではアサート失敗が発生していました。

§ §

タプルをロックするときの後続のupdate chainにおける不具合が修正されました。 (Jasper Smit) (18)(17)(16)(15)(14)

このコードパスでは、update chain内の最初の新しいタプルのxmin値の確認が省略されていたため、元の更新処理が中止され、その領域がVACUUMによってすぐに回収されて再利用された場合、無関係なタプルがロックされることがありました。これにより、予期せぬトランザクションの遅延やデッドロックが生じる可能性がありました。

本障害による以下の予期せぬエラーも確認されています。

ERROR:  t_xmin ... is uncommitted in tuple ... to be updated in table ...

update chainは、インデックス更新をしないHOT UPDATE処理を実現するためのデータ構造です。

§ § § § §

大規模テーブルの増分バックアップにおける誤った処理が修正されました。 (Robert Haas, Oleg Tkachenko) (18)(17)

ベースバックアップと増分バックアップの間に、セグメントサイズ（通常1GB）を超えるテーブルがVACUUMで切り詰められた場合、pg_combinebackupが「file ... has truncation block length ... in excess of segment size」というエラーで失敗する可能性がありました。これにより増分バックアップのリストアが妨げられていました。

§ §

動的共有メモリにロックを取得していたバックエンドプロセスが、FATAL発生時にクラッシュする可能性があり、修正されました。 (Rahila Syed) (18)(17)(16)(15)(14)

トランザクションコンテキスト外でFATALエラーが発生した際に、動的共有メモリセグメントがデタッチされ既にマップされていない領域に対してロックの解除処理が実行されて、バックエンドプロセスのクラッシュが発生していました。

§ § § § §

非同期I/Oコードの競合状態が修正されました。 (Andres Freund) (18)

非同期I/O操作の結果コードが取得される前に上書きされる可能性がありました。

クラッシュ後にマルチトランザクションの有効なSLRUセグメントが誤って切り詰めされる可能性があり、防止されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

該当コードはVACUUM処理の中で実行されます。問題が生じうるケースでは切り詰め処理をスキップするように変更されました。

§ § § § §

pg_stat_get_backend_activity() の結果が誤ってエンコーディングされる問題が修正されました。 (Chao Li) (18)(17)(16)(15)(14)

セッションのアクティビティ文字列を保持する共有メモリバッファは、不完全なマルチバイト文字で終わることがあります。そのような不完全な文字は読み取り時に切り詰めることになっていますが、この関数ではその処理が行われていませんでした。

§ § § § §

メモリコンテクストのログ出力の再帰的な実行が防止されました。 (Fujii Masao) (18)(17)(16)(15)(14)

メモリコンテクストのログ出力を要求するシグナルが継続的に送られた場合に、ログ出力コードが再帰的に実行されてしまうことがあり、これにより理論上はスタックオーバーフローが発生する可能性がありました。

§ § § § §

並列実行コンテクストを再初期化する際のメモリコンテクストの使用方法が修正されました。 (Jakub Wartak, Jeevan Chalke) (18)(17)(16)(15)(14)

補助的なデータ構造の寿命が並列コンテキストよりも短いために、クラッシュが発生することがありました。この問題は、PostgreSQLコアのみを使用している場合には到達可能であることは確認されていませんが、拡張機能において問題が発生したことが報告がされています。

§ § § § §

新しいmultixid（マルチトランザクションID）を生成する際に、次のmultixidのオフセットを設定するように変更し、コーナーケースで必要だった待機ループが削除されました。 (Andrey Borodin) (18)(17)(16)(15)(14)

以前のロジックでは、発生しない更新を待ち続けて動作が止まってしまうことがありました。

§ § § § § § § § § §

データ変更を伴うCTEの複数回書き換えが回避されました。 (Bernice Southey, Dean Rasheed) (18)(17)(16)(15)(14)

以前は、自動更新可能ビューやルール付きのリレーションを更新するときに、元の問合せにデータ変更を伴うCTEが含まれていると、リライタが再帰的にそのCTEを複数回書き換えしていました。この動作は非効率であるうえ、CTE内にALWAYS指定の生成列の更新が含まれている場合には、偽性のエラーを引き起こす可能性がありました。

（障害動作例 - エラーにならない動作が正しい）
db1=# CREATE TABLE t36 (i int GENERATED ALWAYS AS IDENTITY);
db1=# CREATE TABLE t36b (j int);
db1=# CREATE VIEW v36 AS SELECT * FROM t36b;
db1=# WITH cte AS (INSERT INTO t36 DEFAULT VALUES RETURNING i) 
        DELETE FROM v36 USING cte WHERE j = i;
ERROR:  cannot insert a non-DEFAULT value into column "i"
DETAIL:  Column "i" is an identity column defined as GENERATED ALWAYS.
HINT:  Use OVERRIDING SYSTEM VALUE to override.

§ § § § §

DSM（動的共有メモリ）レジストリのエントリの初期化を再試行できるように修正されました。 (Nathan Bossart) (18)(17)

動的共有メモリ（DSM）のエントリの初期化途中で失敗したとしても、次にそのエントリの使用を試みる際に初期化を再度試行できるようになりました。これまで一度初期化が失敗したエントリは、失敗した状態のままで残り続けていました。

§ §

ページがスワップアウトされている場合でも、NUMAステータスビューの取得が失敗しないように修正されました。 (Tomas Vondra) (18)

pg_shmem_allocations_numaビューの参照時でそのような場合に、これまでは「ERROR: invalid NUMA node id ...」エラーを出していましたが、取得できない値にNULLを返すようになりました。

古いバージョンのlibnumaを使用してNUMAページ状態を問い合わせた際に、権限不足エラーが発生しないように修正されました。 (Tomas Vondra) (18)

2.0.19より前のlibnumaで以下のようなエラー発生が報告されました。

db1=# SELECT * FROM pg_shmem_allocations_numa;
ERROR:  failed NUMA pages inquiry status: Operation not permitted

チェックポイントレコードが示すREDOポイントまで遡るWALが存在しない場合、リカバリを失敗させるように修正されました。 (Nitin Jadhav) (18)(17)(16)(15)(14)

リカバリ開始前に、チェックポイントレコードが示すREDOポイントまで遡るWALが存在するかどうかを明示的に検査して、存在しなければ以下のようなPANICを出すようになりました。

PANIC:  could not find redo location ... referenced by checkpoint record at ...

以前は、この状況でリカバリを行うプロセスがクラッシュしたり、データ破損を引き起こしたりする能性がありました。

§ § § § §

ALTER PUBLICATION文を処理するときに元のクエリツリーが書き換えられてしまう問題が修正されました。 (Sunil S) (18)(17)(16)(15)(14)

この誤りによる実害としては、ALTER PUBLICATIONに対して駆動されたイベントトリガが複数指定されたpublishオプションの最初の1つしか認識できませんでした。また、ALTER PUBLICATIONがプリペアドステートメントとして用意されていた場合、その再実行時に同様にオプション指定が失われました。

§ § § § §

「CREATE SUBSCRIPTION ... CONNECTION」で指定された接続オプションを、パブリッシャ側の walsender に渡すように修正されました。 (Fujii Masao) (18)(17)(16)(15)

この修正以前は、接続オプションのうち「options」が無視されていました。そのため、たとえば walsender セッション内でカスタムのサーバーパラメータを設定することができませんでした。これは PostgreSQL 15 でのリファクタリングによって壊れる前までは実際に動作していた挙動であり、今回の修正で以前の挙動が復元されます。

§ § § §

新たに作成または同期されたレプリケーションスロットが無効化される不具合があり、修正されました。 (Zhijie Hou) (18)(17)(16)(15)(14)

同時実行中のチェックポイント処理との競合状態にあるときに、レプリケーションスロットが必要としているWALが削除されてしまう可能性があり、その結果、そのスロットが即座に無効化されてしまう問題がありました。

§ § § § § § § § §

レプリケーションスロットのデータベースに保持させる必要のある最も古いXID（xmin）を計算するときの競合状態が修正されました。 (Zhijie Hou) (18)(17)(16)(15)(14)

この不具合により、論理レプリケーションスロット作成時に「ERROR: cannot build an initial slot snapshot as oldest safe xid follows snapshot's xmin」エラーが発生する可能性がありました。

§ § § § §

論理レプリケーションのサブスクリプションの初期同期において、データコピーを開始する前にpg_replication_originエントリの追加をコミットするように修正されました。 (Zhijie Hou) (18)(17)(16)(15)(14)

これまでは、コピー処理が失敗した場合、新しく追加された pg_replication_originエントリがトランザクションのロールバックによって失われていました。その結果、共有メモリ内の状態が不整合になっていました。

§ § § § §

パラレルワーカによるアプライ処理が失敗した後に、論理レプリケーションの進捗を進めないように修正されました。 (Zhijie Hou) (18)(17)(16)

これまでは、パラレルワーカのアプライ処理が失敗すると、サブスクライバ側でトランザクションが失われることがありました。

§ § §

論理レプリケーションのスロット同期（slotsync）ワーカプロセスが、LOCK_TIMEOUTを知らせるシグナルを正しく処理するように修正されました。 (Zhijie Hou) (18)(17)

これまではタイムアウトのシグナルが事実上無視されていました。

§ §

ストリーミングレプリケーションのスタンバイサーバの再起動時に「ERROR: unexpected data beyond EOF in block ... of relation ...」エラーが発生することがあり、修正されました。 (Anthonin Bonnefoy) (18)(17)(16)(15)(14)

§ § § § §

SQL/JSON pathの型不一致に関するエラーメッセージが正しい内容を示すように修正されました。 (Jian He) (18)(17)

これまでは、型が正しくない場合に本来出すべきエラーの代わりに、「ERROR: cache lookup failed for type 0」という誤ったエラーが発生していました。

（修正前に誤ったエラーが出るケースの正常動作例）
db1=# CREATE TABLE t49 (path) AS SELECT '$'::text;
db1=# SELECT json_value('"aaa"', t49 RETURNING json) FROM t49;
ERROR:  JSON path expression must be of type jsonpath, not of type t49

§ §

パーティション範囲の境界を解析する際に、列の位置の追跡を誤る問題が修正されました。 (myzhen) (18)(17)(16)(15)(14)

これまでは、例えばパーティション境界の値を列のデータ型にキャストする際のエラーで、誤った列名が表示されることがありました。

（誤動作例: b列の型不一致なのにエラーでa列を出している)
db1=# CREATE TABLE t50 (a int, b int, c int) PARTITION BY RANGE (a, b);
db1=# CREATE TABLE t50_p1 PARTITION OF t50
        FOR VALUES FROM (minvalue, now()) TO (100, 100);
ERROR:  specified value cannot be cast to type integer for column "a"

§ § § § §

エラーメッセージ内の軽微な誤りがいくつか修正されました。 (Man Zeng, Tianchen Zhang) (18)(17)(16)(15)(14)

例えば、バックアップマニフェスト内のタイムライン番号が不一致でエラーが発生した場合、本来、終了タイムライン番号を表示すべきところで、開始タイムライン番号を表示する誤りがあり、修正されました。

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

LLVMバージョン17以降で、JITコンパイル時に関数をインライン化できない問題が修正されました。 (Anthonin Bonnefoy) (18)(17)(16)(15)(14)

§ § § § §

LLVMバージョン21で動作するようにJITコードが修正されました。 (Holger Hoffstatte) (18)(17)(16)(15)(14)

これまではaarch64マシンでコンパイルに失敗しました。

§ § § § §

古い（RHEL7時代の）システムヘッダーファイルでビルドできるよう、aarch64固有のコードが修正されました。 (Tom Lane) (18)

§ §

autotoolsによるconfigureスクリプトでio_uring_queue_init_mem()が使えるか否かの判定が修正されました。 (Masahiko Sawada) (18)

これまでは、この判定が間違っていたため、非同期I/Oバッファの最適化に失敗していました。その結果、バックエンドプロセスの終了が必要以上に遅くなっていました。

mesonビルドの場合には問題は発生しません。

新たな設定パラメータfile_extend_methodが追加されました。これはposix_fallocate()の使用を制御します。 (Thomas Munro) (18)(17)(16)

PostgreSQL16以降ではプラットフォームで提供されているなら、posix_fallocate()を使用してリレーションファイルを拡張します。しかし、posix_fallocate()が使えたとしても、一部のファイルシステムでは不具合がありました。

BTRFSの圧縮が無効化されたり、古いLinuxカーネルバージョンのXFSで偽性のENOSPC（空き領域なし）が生じることがありました。

その回避策として、file_extend_methodパラメータを「write_zeros」に設定することで、旧方式（ゼロのブロックを書き込む）でのファイル拡張ができるようになりました。

§ § §

Windowsでもopen()の「O_CLOEXEC」フラグを参照するように修正されました。 (Bryan Green, Thomas Munro) (18)(17)(16)

Windowsで「COPY TO/FROM PROGRAM」などで子プロセスを起動する際、子プロセスにファイルハンドルがリークしていました。大きな被害はありませんが望ましくありませんでした。修正によりPOSIXと同様の動作になりました。

§ § § § § § § § §

Solaris上でmesonを使ってビルドしたpostgresコマンドがロングオプション（--XXX形式）の解析に失敗しており、修正されました。 (Tom Lane) (18)(17)(16)

§ § §

GNU/Hurdでもプロセスタイトルの変更が可能になりました。 (Michael Banck) (18)(17)(16)(15)(14)

§ § § § §

psqlでVACUUMのオプションをタブ補完する際の不具合が修正されました。 (Yugo Nagata) (18)

psqlのプロンプトエスケープ「%P」の表示が修正されました。 (Chao Li) (18)

サーバーに未接続の場合、%P（パイプラインステータス）が他のプロンプトエスケープと同様に何も表示されないように修正されました。

pg_dumpのシーケンスを収集するロジックが修正されました。 (Nathan Bossart) (18)

これまでは、pg_dumpの実行と同時にシーケンスが削除された場合、それがダンプ対象ではない場合でも、エラーとなっていましたが、エラーにならないように修正されました。

また、pg_dumpの実行でシーケンスの読み取り権限がない場合、誤った値をバックアップに出力していましたが、正しくエラーになるように修正されました。

§ §

pg_dumpでoauth_validator_libraries設定値を引用符で正しくクォートするように修正されました。 (ChangAo Chen) (18)

この設定の値をダンプする必要がある場合、pg_dumpは間違った引用符ルールを適用していました。

pg_dumpの--binary-upgradeオプションでアサート失敗が起きる問題が修正されました。 (Vignesh C) (18)(17)

サブスクリプション関連のオブジェクトの処理でアサート失敗が起きていました。アサートを無効にした実運用むけビルドでは障害の悪影響は特にありません。

§ §

pgbenchのパイプラインモードで複数の\syncpipelineを使用した場合に発生する誤ったエラー処理が修正されました。 (Yugo Nagata) (18)(17)

パイプラインモードで問合せのエラーが発生した後に複数の\syncpipelineコマンドが実行された場合、これまでは「ERROR: failed to exit pipeline mode」と誤ったエラーメッセージを表示するか、アサートを有効ビルドではアサート失敗となっていました。

§ §

pg_resetwalでOldestXIDを変更したときに、変更後の値を表示するように修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

他の変更できる変数では、変更後の値を表示するようになっています。

§ § § § §

pg_upgradeで、次のマルチトランザクションIDに0を設定することと、次のマルチトランザクションオフセットにUINT32_MAXの値を設定することが、可能になりました。 (Maxim Orlov) (18)(17)(16)(15)

これらが有効な値であるのに設定ができないために、マルチトランザクションIDが周回するタイミングでpg_upgradeが失敗する可能性がありました。

§ § § §

contrib/amcheckでBTreeインデックスの親ページ検査で正しいスナップショットを使うように修正されました。 (Mihail Nikalayeu) (18)(17)(16)(15)(14)

このために「CREATE INDEX CONCURRENTLY」で作成されたインデックスに対して、誤ってエラーを報告していました。

§ § § § § § §

contrib/amcheckでBTreeインデックスの「half-dead」ページを正しく処理するように修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

これまでは、half-deadページに親のダウンリンクが存在しない状態を「ERROR: mismatch between parent key and child high key ...」と誤ってエラー報告していました。

§ § § § §

contrib/amcheckでBTreeインデックスのルートページ分割が未完了の状態を正しく処理するように修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

これまでは「ERROR: block ... is not true root」エラーを誤って報告していました。

§ § § § §

contrib/pg_buffercacheで、メモリを必要以上に使ってしまう問題が修正されました。 (David Geier) (18)

これまでは、NUMAページの状態を保存する配列の要素サイズを、本来はintで十分なところをuint64として扱っていたため、必要な量の2倍のメモリを確保していました。

contrib/intarrayの「@@」演算子用の選択度推定において、特定の条件下で整数オーバーフローが発生する問題が修正されました。 (Chao Li) (18)(17)(16)(15)(14)

プランナ統計情報に整数最大値（INT_MAX）が含まれる場合にオーバーフローが発生して、不正確な選択度推定による劣ったプランが作成される可能性がありました。

§ § § § §

conrib/ltreeにおけるマルチバイトエンコーディング処理の問題が修正されました。 (Jeff Davis) (18)(17)(16)(15)(14)

従来の実装では、不完全なマルチバイト文字が内部実装上のlower()関数に引数として渡されるケースがあり、その結果、文字エンコーディングに関する予期せぬエラーや、誤った問い合わせ結果がもたらされる可能性がありました。

§ § § § §

contrib/pg_stat_statementsを使用しているときに、IN句内に定数と非定数式が混在している場合に、そのSQLを実行するバックエンドプロセスのクラッシュやアサート失敗が発生しており、修正されました。 (Sami Imseih) (18)

タイムゾーンデータファイルがtzdata release 2025cへ更新されました。 (Tom Lane) (18)(17)(16)(15)(14)

今回の変更は1976年以前のバハ・カリフォルニアの歴史的データのみです。

§ § § § §

インプレイスによるカタログ更新に関する問題が修正されました。 (Noah Misch) (17)(16)(15)(14)

インプレイス（データを直接書き換える形）での更新はトランザクションのロールバックでも保持されるため、非トランザクション型の無効化メッセージを送信するようになりました。また、他のセッションが更新内容を参照できるようになる前に、更新内容をWALに記録することを保証されるようになりました。これらの修正により、リレーションのfrozen-XID属性が不整合になるシナリオを防止されます。frozen-XID属性の不整合が発生すると、CLOG（コミットログ）の早期切り捨てや、その後の「could not access status of transaction」エラーの原因となる可能性があります。

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

SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

PostgreSQL 17 増分バックアップの実践活用と運用上の考慮点

越野太基 (Taiki Koshino) — Tue, 16 Dec 2025 05:00:10 +0000

この記事は SRA Advent Calendar 2025 18 日目の記事です。

PostgreSQL には様々なバックアップの方法が提供されています。
それぞれのバックアップの方法は利点が違い、運用方法も手順も異なります。
今回はバックアップ方法の簡単なおさらいと、PostgreSQL 17 で標準機能として追加された増分バックアップについて紹介します。

PostgreSQLのバックアップの種類

PostgreSQL のバックアップは大きく論理バックアップと物理バックアップの 2 種類に分類できます。

論理バックアップ

SQL レベルでデータを取得する方式です。
CREATE TABLE や INSERT 文などで現在のデータベースの状態を再現できるファイルを生成します。
異なるOSアーキテクチャ間や PostgreSQL メジャーバージョン間でもリストア可能という柔軟性が大きな利点です。

物理バックアップ

データベースクラスタ全体のディレクトリを丸ごと保存する方式です。
Linux の cp コマンドや PostgreSQL 標準ツールである pg_basebackup を利用できます。
pg_basebackup では PITR（Point-In-Time Recovery）や PostgreSQL 17 で追加された増分バックアップを利用できる点が最大の特徴です。

今回は、この「増分バックアップ」について詳しく紹介します。

増分バックアップとメリット

増分バックアップは、ある時点で取得したフルバックアップをベースとし、その後に変更された部分だけを保存する方式です。

たとえば、10 TB のデータベースを毎日 30 日分フルバックアップで保存すると、
10 TB × 30 日 = 300 TB もの容量が必要になります。

しかし増分バックアップであれば、
初日のフル 10 TB + 毎日の変更分のみを保存すればよく、大幅なストレージ削減が可能です。
上記の図は毎日の変更分を10GBと想定した場合の比較図となります。

また、バックアップ取得時間も短縮できます。
フルバックアップではすべてのデータをコピーするため時間がかかりますが、増分バックアップは変更分だけを取得するためバックアップ時間の短縮につながります。
また結果としてサーバー負荷の軽減にも寄与します。

増分バックアップの手順

従来、PostgreSQL で増分バックアップを行いたい場合は、サードパーティツールである pg_rman の利用が一般的でした。
ただし、pg_rman は Windows 非対応という課題がありました。

PostgreSQL 17 ではこれらの問題が解消され、標準機能として増分バックアップがサポートされました。
主な追加項目は以下のとおりです。

pg_basebackup に増分バックアップを取得する --incremental オプションが追加
フルバックアップと増分バックアップを統合する pg_combinebackup コマンドの追加
増分バックアップの制御にかかわる summarize_wal, wal_keep_summary パラメータの追加

これらによって増分バックアップの取得が可能になっています。
それぞれのコマンドやパラメータの扱い方について詳しく見ていきましょう。

動作確認環境と postgresql.conf のパラメータは以下です。

動作環境

領域	パス	備考
データベースクラスタ	data
WAL領域	data/pg_wal
バックアップ格納先	backup	フルバックアップ、増分バックアップを保存

postgresql.conf パラメータ

パラメータ名	設定値	備考
summarize_wal	on(off がデフォルト)	on でないと増分バックアップ不可
wal_level	replica(デフォルト) 以上	summarize_wal が on の時は replica 以上が必須

増分バックアップのコマンド

増分バックアップの手順は大きく分けて以下です。

pg_basebackup によるフルバックアップの取得
pg_basebackup --incremental による増分バックアップの取得
pg_combinebackup によるフルバックアップと増分バックアップの統合

コマンド実行例をもとに見ていきましょう。

フルバックアップ取得前の時点では full_backup というテーブルがあるのみです。

これから各増分バックアップ取得時点でテーブルを追加していき、各世代のバックアップの状態にリストアできるかを見ていきます。

$ psql
psql (17.6)
"help"でヘルプを表示します。
postgres=# \d
               リレーション一覧
 スキーマ |    名前     |  タイプ  |  所有者
----------+-------------+----------+----------
 public   | full_backup | テーブル | postgres
(1 行)

最初に pg_basebackup コマンドでフルバックアップを取得します。

# -P オプションでサイズや進捗を確認可能
$ pg_basebackup  -D backup/full -P
23818/23818 kB (100%), 1/1 テーブル空間

その後 inc1 テーブルを作成し、一回目の増分バックアップを取得します。

ここで pg_basebackup に新規で追加された --incremental オプションを用います。
引数には前回取得したバックアップ、つまりフルバックアップの backup_manifest ファイルを指定します。
backup_manifest ファイルはバックアップのトップディレクトリにあるのでそちらのパスを指定してください。

postgres=# create table inc1 (i int);
CREATE TABLE
$ pg_basebackup --incremental=backup/full/backup_manifest -D backup/inc1

二回目の増分バックアップも同様に inc2 テーブルを作成後取得します。

この時注意が必要なのが前回のバックアップを指定することです。
今回だとフルバックアップではなく一回目の増分バックアップの backup_manifest を指定します。

postgres=# create table inc2 (i int);
CREATE TABLE
$ pg_basebackup --incremental=backup/inc1/backup_manifest -D backup/inc2

最後に pg_combinebackup で各世代を統合していきます。
pg_combinebackup の -o オプションでは統合バックアップの出力先を指定し、その後の引数はフルバックアップから統合したい世代までの増分バックアップをすべて指定します。

統合後はpg_verifybackupでバックアップの整合性も忘れずチェックするようにしてください。

# フルバックアップからinc1(inc1 テーブルがある時点)まで
$ pg_combinebackup -o backup/combine_full_inc1 backup/full/ backup/inc1
# フルバックアップからinc2(inc1, inc2 テーブルがある時点)まで
$ pg_combinebackup -o backup/combine_full_inc2 backup/full/ backup/inc1 backup/inc2/
# 各統合バックアップを pg_verifybackup で検証
$ pg_verifybackup backup/combine_full_inc1
バックアップが正常に検証されました
$ pg_verifybackup backup/combine_full_inc2
バックアップが正常に検証されました

各世代増分バックアップの中身を確認

では、各世代のバックアップが正しく取得できているか確認してみましょう。

統合バックアップを、それぞれ異なる port 番号に設定して起動すると、各世代におけるinc1、inc2テーブルの状態が、作成時点の内容として保持されていることが分かります。

この検証により、全ての世代でバックアップが正しく取得されていることを確認できました。

$ pg_ctl -o "-p 5433" start -D backup/combine_full_inc1/
$ psql –p 5433
postgres=# \d
               リレーション一覧
 スキーマ |    名前     |  タイプ  |  所有者
----------+-------------+----------+----------
 public   | full_backup | テーブル | postgres
 public   | inc1        | テーブル | postgres
$ pg_ctl -o "-p 5434" start -D backup/combine_full_inc2/
$ psql –p 5434
postgres=# \d
               リレーション一覧
 スキーマ |    名前     |  タイプ  |  所有者
----------+-------------+----------+----------
 public   | full_backup | テーブル | postgres
 public   | inc1        | テーブル | postgres
 public   | inc2        | テーブル | postgres

増分バックアップのストレージコストと取得時間

最初に挙げたメリットとして、ストレージコストとバックアップ取得時間を抑えられる点がありました。
ここでは、実際にどの程度削減できているのか確認してみます。

まずストレージ使用量を比較すると、初回に取得したフルバックアップは 888 MB と比較的大きなサイズでした。
一方、続いて取得した増分バックアップはどれも約 4 MB 程度と非常に小さく抑えられています。

これを「すべての世代をフルバックアップで保存する場合」と比べてみると、毎回 888 MB 近く消費することになります。
それに対して増分バックアップは変更分のみを保存すればよいため、世代を重ねてもバックアップ容量を大幅に抑えられることが分かります。

$ du -h  --max-depth=1 backup/
888M     backup/full
6M     backup/inc1
4M     backup/inc2

また time コマンドでバックアップ取得の時間も比べてみましょう。

pg_basebackup --incremental と --incremental オプションなしのフルバックアップの取得時間を比べてみると、--incremental での増分バックアップは取得時間がかなり短いことが分かります。

$ time pg_basebackup -D backup/inc_3 --incremental=backup/inc2/backup_manifest -c fast -P
  4045/888986 kB (100%), 1/1 テーブル空間
real    0m4.391s
$ time pg_basebackup -D backup/full_3 -c fast -P
888986/888986 kB (100%), 1/1 テーブル空間
real    0m32.777s

pg_combinebackup のオプション

pg_combinebackup には統合のファイルコピーを高速化するオプションが用意されています。

ファイルコピーを高速化するオプション

オプション	説明	環境	メリット
--copy	ファイルをコピー [デフォルト]
--copy-file-range	copy_file_rangeを利用したファイル部分コピー	FreeBSDかカーネル4.5+の Linux	カーネル空間で完結するため高速
--clone	Reflink機能でのファイルクローンコピー	カーネル 4.5+の Linux の Btrfs、Reflinkが有効なXFS macOS の APFS	Inodeとブロックマップコピーのみのため高速
-k, --link(v18で追加)	ハードリンクを作成するコピー		リンク作成のみのため高速

デフォルトのオプション以外はすべて高速化できるものの、すべて入出力のディレクトリが同じファイルシステムである必要がある点には注意してください。
--copy-file-range, --clone については実行できる環境に上記表のような制限もあります。

同期のオプション

オプション	バックアップ統合の対象	メリット
--fsync	バックアップディレクトリ内全ファイル [デフォルト]	最小限のバックアップで済む
--plain	WALファイルとテーブル空間全体のシンボリックリンクまで	左記をバックアップに含められる
--syncfs	バックアップディレクトリを含むファイルシステム全体	ファイル一つ一つを開かないため統合が早い

同期する範囲を指定できるオプションもあり、
同期対象を増やすほどディスクへの書き込みがより確実に行われるようになります。

デフォルトではバックアップ対象のディレクトリのみですが、--plain で WAL ファイルとテーブル空間全体のシンボリックリンクまで、--syncfs ではバックアップディレクトリを含むファイルシステム全体を同期の対象とできます。

--syncfs はファイルを一つ一つ開かず同期をチェックするため同期が素早く完了できるというメリットもあります。

増分バックアップ使用上の注意点

注意点は大きく分けて以下の3つです。それぞれ見ていきます。

パラメータの管理
フルバックアップ～増分バックアップの保存
ストレージ容量

パラメータの管理

増分バックアップで管理すべきパラメータは以下です。

summarize_wal
wal_level
wal_summary_keep_time

summarize_wal は pg_basebackup --incremental をする際に参照する wal の情報をまとめたサマリファイルを作成するか否かを制御するパラメータです。

このファイルがない状態で増分バックアップを取得しようとするとエラーとなり取得に失敗してしまいます。
デフォルトでは off となっていますので忘れずに on としてください。

# summarize_wal が off で取得したフルバックアップを対象とするとエラー
$ pg_basebackup --incremental=backup/full/backup_manifest -D backup/inc1
pg_basebackup: エラー: ベースバックアップを開始できませんでした: 
ERROR:  WAL集約が有効でなければ差分バックアップは取得できません

wal_level についても replica 以上が必要です。
これが replica 以上でないと summarize_wal のパラメータが無効となる仕様となっています。

wal_summary_keep_time はサマリファイルを保存する期間を指定するパラメータです。
例えば以下のように 1d に設定し、2 日後に増分バックアップを取得しようとすると必要なサマリファイルが削除されているため、取得に失敗してしまいます。
そのため、増分バックアップを取得する運用間隔よりも長い期間を設定する必要があります。

# postgresql.conf の wal_summary_keep_time を 1d に設定
wal_summary_keep_time = '1d'

$ ls –l  data/pg_wal/summaries/
-rw-------. 1 postgres postgres 32 11月 1 16:52 0000000100000001CF00002800000001D0000028.summary
# 2 日後に増分バックアップを取得しようとすると失敗
$ date
2025年 11月 3日 月曜日 15:37:55 JST
$ pg_basebackup -D backup/inc_1 --incremental=backup/full/backup_manifest -P -c fast
pg_basebackup: エラー: ベースバックアップを開始できませんでした:
ERROR:  WAL集計がタイムライン1上の1/CD000060から1/CF000028まで必要ですが、そのタイムライン上のそのLSN範囲での集計は不完全です
DETAIL:  この範囲で集計されていない最初のLSNは1/CD000060です

フルバックアップ～増分バックアップの保存

pg_combinebackup をする際に引数フルバックアップ～統合したい世代までのフルバックアップがすべてないと以下エラーとなります。

# 最初の引数にフルバックアップを指定せずに実行
$ pg_combinebackup -o backup/combine_test backup/inc1 backup/inc2
pg_combinebackup: エラー: "backup/inc1"のバックアップは差分バックアップですが、最初のバックアップはフルバックアップである必要があります
# backup/inc_1 を引数に渡さず実行
# LSN 位置に飛びが見られエラーとなる
$ pg_combinebackup -o backup/combine_1 backup/full/ backup/inc_2
pg_combinebackup: エラー: "backup/full/"のバックアップはLSN 1/1A000060で始まっていますが、1/1C000028を期待していました

そのため、実際の運用ではフルバックアップと、最新世代までのすべての増分バックアップを保持しておく必要があります。
削除のタイミングとしては、定期的に pg_combinebackup を実行し、統合によって不要になった過去のフルバックアップおよび増分バックアップを削除するフローになります。

また、統合して生成されたバックアップは、次回の pg_combinebackup におけるフルバックアップとして利用可能であるため、統合元となった古いフルバックアップは削除して問題ありません。

ストレージ容量

ストレージコストの低さがメリットの増分バックアップですが、pg_combinebackup をした直後は古いバックアップと統合バックアップが共存する状態になりますので、それらすべてを保存できるストレージサイズを確保する必要があります。

増分バックアップと
PITR と両立したリストア手順

増分バックアップ PITR と両立しての増分バックアップを利用することができます。

PITR(Point In Time Recovery) は WAL アーカイブをもとにして任意の時点までのリストアを可能にするリストア方法です。

WAL アーカイブはデータの変更履歴が記載されたもので、事前に取得しておいたフルバックアップに WAL アーカイブの変更履歴を任意の時点まで適用することで任意の時点に復旧できることが強みのリストア方法です。

この PITR と増分バックアップと両立することで以下メリットが得られます。

増分バックアップによるバックアップ取得でストレージコストや取得時間を短く抑えられる
PITR によるリストアでより任意の時点に復旧することができる

今回はこれらを両立する設計で具体的な設定手順を紹介します。

まずパラメータの設定を行います。

#wal をアーカイブする設定
#%p は保管するWALファイルの相対パス, %f がWALのファイル名に置き換わる
archive_mode = on
archive_command = 'cp "%p" "/pg_arc/%f"'
#restore を行う設定
restore_command = 'cp "/pg_arc/%f" "%p"'

その後増分バックアップ取得を行います。
フルバックアップ、増分バックアップ取得、バックアップの統合、検証の手順で取得します。

# フルバックアップ～バックアップの取得・統合、検証まで実施
$ pg_basebackup  -D backup/full
$ pg_basebackup --incremental=backup/full/backup_manifest -D backup/inc1
$ pg_combinebackup -o backup/combine_full_inc1 backup/full/ backup/inc1
$ pg_verifybackup backup/combine_full_inc1

その後 mv コマンドで疑似的にデータベースのデータが消えてしまった状態を作ります。

そして統合したバックアップを元のデータディレクトリに mv で移動し、recovery.signal を作成して起動すると PITR のリカバリモードで起動します。
リカバリ終了後に状態を見に行くとデータが指定した時点に復旧していることが分かります。

# データを移動して障害を疑似的に起こす
$ mv data data_crash
# 統合したバックアップを元ディレクトリにコピー
$ cp –r databackup/combine_full_inc1 data
# リカバリモードで起動するよう指示するrecovery.signal を作成して起動
$ touch data/recovery.signal
# 必要に応じて postgresql.conf を設定し復旧タイミングを指定
recovery_target_time = '2025-10-20 14:05:00'
$ pg_ctl start
# ログに以下が出力されていれば復旧完了
LOG: starting archive recovery
LOG: archive recovery complete

まとめ

今回は PostgreSQL 17 で追加された増分バックアップの運用方法と注意点について紹介しました。

PostgreSQL18ではさらに機能が追加されたりと今後より便利になっていく注目の手法です。
紹介した手順を参考に増分バックアップの利用を検討いただけると幸いです。

SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

PostgreSQL 17.7 に関する技術情報

データベース技術グループ — Mon, 15 Dec 2025 03:07:13 +0000

このリリースは 17.6 からの修正リリース（2025年 11月 13日リリース）です。
17.X からのアップデートではダンプ、リストアは不要です。

また、17.6 よりも前のバージョンからアップデートする場合には、17.6のリリース情報も参照してください。

PostgreSQL 17.6 から 17.7 への変更点

18.1, 17.7, 16.11, 15.15, 14.20, 13.23 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。

CREATE STATISTICSで、スキーマに対する「CREATE」権限の検査を行うようになりました。 (Jelte Fennema-Nio) (18)(17)(16)(15)(14)(13)

これまでこの検査が省略されており、テーブル所有者は任意のスキーマに拡張統計情報を作ることができて、予期せぬ名前衝突をもたらすおそれがありました。(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で、メモリ割り当てサイズ計算での整数オーバーフローを回避するようになりました。 (Jacob Champion) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

JSON_VALUEなどのSQL/JSON関数がCOLLATE式を含むDEFAULT句を持つときの、内部エラー発生が防止されました。 (Jian He) (18)(17)

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

§ § § §

グルーピングセットを伴った列指定の無いHAVING句での不正な最適化が回避されました。 (Richard Guo) (18)

ここでのグルーピングセットは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)

§ §

Hash Right Semi Joinでパラレル処理を行なわないようになりました。 (Richard Guo) (18)

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

ソートされたAppend（ordered-append）プランの作成で起こりうるゼロ除算が回避されました。 (Richard Guo) (18)

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

ソート順のアクセスが可能であるけれどもインデックスオンリースキャンはできないインデックスタイプに対して、プランナでのエラー発生が修正されました。 (Maxime Schoemans) (18)

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

Btreeインデックスのクリーンアップ処理で過度なアサートを除去しました。 (Peter Geoghegan) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

パラレルGINインデックスの作成で発生するおそれのあったメモリ不足エラー(「ERROR: out of memory」)や「ERROR: invalid memory alloc request size」エラーを回避するようになりました。 (Tomas Vondra) (18)

BRINの自動サマライズが必要なインデックス式のスナップショットを確実に提供するようになりました。 (Álvaro Herrera) (18)(17)(16)(15)(14)(13)

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

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

ERROR:  cannot execute SQL without an outer snapshot or portal

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

テーブルサイズが2の32乗ページ近くなる場合、BRINインデックススキャンで整数オーバーフローが発生する可能性があり、修正されました。 (Sunil S) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

JITが生成するタプルデフォーミングのコードで、格納データを誤ってゼロ拡張してしまう問題が修正されました。 (David Rowley) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

ハッシュ化されたGROUPING SETSの処理中に、まれにクラッシュする問題が修正されました。 (David Rowley) (18)

ハッシュ結合において、ハッシュテーブルのサイズ選択ロジックが誤っていた問題が修正されました。 (Tomas Vondra) (18)

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

統計情報を操作する関数について、テーブルを参照する際のロジックが改善されました。 (Nathan Bossart) (18)

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

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

§ §

トリガーで使用される結果リレーション情報(ResultRelInfo)のキャッシュ処理に存在した誤ったロジックによるクラッシュが修正されました。 (David Rowley, Amit Langote) (18)(17)(16)(15)

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

§ § § §

パーティションテーブルに対してEvalPlanQualが再チェックを行う際にクラッシュする問題が修正されました。 (David Rowley, Amit Langote) (18)

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

EvalPlanQual用の代替となるローカルでの結合プランを持たないforeign結合またはカスタム結合を、EvalPlanQualが適切に扱えない問題が修正されました。 (Masahiko Sawada, Etsuro Fujita) (18)(17)(16)(15)(14)(13)

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

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

§ § § § § §

DETACH CONCURRENTLY実行時に、ハッシュパーティションの制約が重複して追加されてしまう問題が修正されました。 (Haiyang Li) (18)(17)(16)(15)(14)

従来は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以前では、影響を最小化するためハッシュパーティションの場合のみ制約のコピーをスキップするよう修正されました。

§ § § § §

パーティションキーに生成列が利用できないようになりました。 (Jian He, Ashutosh Bapat) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

COPY ... FROM ... WHERE句で生成列が使用できないようになりました。 (Peter Eisentraut, Jian He) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

無効とマークされているNOT NULL制約が付いた列を、識別列として設定できないようにされました。 (Jian He) (18)

識別列は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.

並列VACUUMにおいて、解放済みメモリ使用（use-after-free）が発生する可能性が回避されました。 (Kevin Oommen Anish) (18)(17)

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

§ §

pg_temp内の統計オブジェクトに対する可視性チェックが修正されました。 (Noah Misch) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

データベース作成のWALリプレイ時に発生していた軽微なメモリリークが修正されました。 (Nathan Bossart) (18)(17)(16)(15)

§ § § §

pg_stat_replicationビューにおけるレプリケーション遅延の誤った報告が修正されました。 (Fujii Masao) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

無効なprimary_slot_name設定に関する重複したログメッセージが出力されないようにされました。 (Fujii Masao) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

synchronized_standby_slotsが存在しないレプリケーションスロットを参照している場合の障害が回避されました。 (Shlok Kyal) (18)(17)

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

§ §

レプリケーションスロットの状態をディスクへ書き込む際に失敗した場合、未完成のスロット状態ファイルが削除されるようにされました。 (Michael Paquier) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

論理レプリケーションの並列適用ワーカにおけるロックタイムアウトシグナルの誤処理が修正されました。 (Hayato Kuroda) (18)(17)(16)

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

§ § §

ストリーミングWALからアーカイブWALへ切り替える際に、不要なWAL受信プロセスのシャットダウンを回避するよう修正されました。 (Xuneng Zhou) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

pgoutputの論理デコーディング中にエラーが起きた際に、既に解放されたキャッシュメモリにアクセスしてクラッシュする問題が修正されました。 (Vignesh C, Masahiko Sawada) (18)(17)(16)(15)

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

§ § § §

ロジカルレプリケーションスロットの不必要に無効化されていたのが修正されました。 (Bertrand Drouvot) (18)(17)(16)

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

§ § §

ロケール設定において、C照合順序の特殊ケースが再度有効化されました。 (Jeff Davis) (18)

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

Windows管理者権限の確認処理で失敗した際のメッセージ出力が正しく行われるように修正されました。 (Bryan Green) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

libsanitizer使用時に発生する可能性のあるクラッシュを回避するよう修正されました。 (Emmanuel Sibi, Jacob Champion) (18)(17)(16)

§ § §

64bit Windowsのデバッグビルドで発生していた、誤ったメモリコンテキストチェック警告が修正されました。 (David Rowley) (18)(17)(16)(15)(14)(13)

§ § § § § §

PL/pgSQLの代入文でGROUP BY DISTINCTが正しく処理されるように修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

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

§ § § § §

PL/Python内でSQLエラーを処理する際のメモリリークが修正されました。 (Tom Lane) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

libpqのGSSAPI処理におけるWindows上のソケット関連エラーの扱いが修正されました。 (Ning Wu, Tom Lane) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

継承子テーブルの列に対する非継承の（子テーブル固有の）NOT NULL制約が、正しくダンプされるよう修正されました。 (Dilip Kumar) (18)(17)

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

§ §

pg_dumpにおいて外部キー制約の並び順について修正されました。 (Álvaro Herrera) (18)

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

§ § § § § §

pg_dumpおよびpg_restoreにおけるデータ圧縮ロジックについて、各種のエラーが修正されました。 (Daniel Gustafsson, Tom Lane) (18)(17)(16)(15)(14)(13)

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

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

§ § § § § § § § § § §

pgbenchで「COPY」操作が開始された場合に正しくエラーを返すようになりました。 (Anthonin Bonnefoy) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

pgbenchにおける複数エラーの報告が修正されました。 (Yugo Nagata) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

pgbenchのパイプラインモードにおいて、エラー処理に関する不正確なアサートが修正されました。 (Yugo Nagata) (18)(17)(16)(15)

§ § § §

pg_combinebackupでファイルごとのメモリリークが修正されました。 (Tom Lane) (18)(17)

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

§ §

contrib/pg_buffercacheの関数が確実にキャンセルできるようになりました。 (Satyanarayana Narlapuram, Yuhang Qiu) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

contrib/pg_prewarmで、インデックスの権限チェックが修正されました。 (Ayush Vatsa, Nathan Bossart) (18)(17)(16)(15)(14)(13)

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

§ § § § § § § § §

contrib/pg_stat_statementsで、SQL文のテキスト内で複数の定数が同じ位置に割り当てられた場合にクラッシュする不具合が修正されました。 (Sami Imseih, Dmitry Dolgov) (18)

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

contrib/pgstattupleで、すべてゼロのページ、無効なインデックスページについて、より頑健な動作になりました。 (Nitin Motiani) (18)(17)(16)(15)(14)(13)

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

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

§ § § § § §

Clangコンパイラの仕様に合わせて、読み取りと書き込みのバリアマクロが強化されました。 (Thomas Munro) (18)(17)(16)(15)(14)(13)

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

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

§ § § § § §

PGXS拡張構築基盤が各国語対応のpoファイルのビルドに対応するように修正されました。 (Ryo Matsumura) (18)(17)(16)(15)(14)(13)

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

§ § § § § §

JSON作成関数（JSON_OBJECT()など）を非STRICTとして正しく処理するようになりました。 (Tender Wang, Richard Guo) (17)(16)

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

§ §

「SIMILAR TO」正規表現内の文字クラスの処理の不具合が修正されました。 (Laurenz Albe) (17)(16)(15)(14)(13)

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

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

§ § § § §

集約関数の引数に含まれるサブクエリが、スコープ外のCTEをFROMで参照している場合の解析が修正されました。 (Tom Lane) (17)(16)(15)(14)(13)

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

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

§ § § § §

プランナがSubPlanのコストを見積もる際に、稀にエラー「ERROR: no relation entry for relid」が発生する不具合が修正されました。 (Richard Guo) (17)(16)(15)(14)(13)

§ § § § §

プランナがパーティションテーブルを展開する際に解放済みメモリ使用(use-after-free)の脆弱性が生じる可能性があり、修正されました。 (Bernd Reiß) (17)(16)(15)

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

§ § §

複数のスキャン条件を持つGINインデックススキャンで無限ループに陥る可能性があり、修正されました。 (Tom Lane) (17)(16)(15)(14)(13)

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

§ § § § §

GINインデックススキャンを割り込みでキャンセルできるようになりました。 (Tom Lane) (17)(16)(15)(14)(13)

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

§ § § § §

プランノードTID ScanおよびTID Range Scanに、欠けていたEvalPlanQual再チェックが追加されました。 (Sophie Alpert, David Rowley) (17)(16)(15)(14)(13)

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

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

§ § § § § § § § §

pg_event_trigger_dropped_objects()関数の戻り値のis_temporary列の挙動が修正されました。 (Antoine Violin, Tom Lane) (17)(16)(15)

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

§ § § § § §

ハッシュ化されたサブプラン(hashed SubPlan)でのメモリリークが修正されました。 (Haiyang Li) (17)(16)(15)(14)(13)

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

§ § § § §

スタンバイサーバの起動プロセスでのSMgrRelationオブジェクトのメモリリーク不具合が修正されました。 (Jingtang Zhang) (17)

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

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

メモリ不足エラー後に統計情報を管理する共有テーブルが破損する不具合が修正されました。 (Mikhail Kot) (17)(16)(15)

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

§ § §

MERGEにおける同時更新の問題が修正されました。 (Yugo Nagata) (17)(16)(15)

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

§ § §

MERGEおよびINSERT ... ON CONFLICT DO UPDATEに不足しているレプリカアイデンティティチェックが追加されました。 (Zhijie Hou) (17)(16)(15)(14)(13)

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

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

パブリッシャがサブスクライバと同一サーバ上にある場合に発生するDROP SUBSCRIPTION実行時のデッドロックが回避されました。 (Dilip Kumar) (17)(16)(15)(14)(13)

§ § § § §

通常のテーブルと一時テーブルとの間でファイル番号が偶然衝突することによる論理レプリケーションの失敗が回避されました。 (Vignesh C) (17)(16)(15)(14)(13)

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

§ § § § §

シングルユーザーモードでレプリケーションスロットを解放しようとする際のアサート失敗が回避されました。 (Hayato Kuroda) (17)(16)(15)(14)(13)

§ § § § §

macOSおよびBSDプラットフォームで、既存のセマフォセットとの競合が発生した場合の起動失敗が回避されました。 (Tom Lane) (17)(16)(15)(14)(13)

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

§ § § § §

libpqのトレース出力関数PQtrace()について、最上位ビットが設定された場合の出力が修正されました。 (Ran Benita) (17)(16)(15)(14)

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

§ § § §

pg_dumpでサブスクリプションとイベントトリガのセキュリティラベルがダンプされるようになりました。 (Jian He, Fujii Masao) (17)(16)(15)(14)(13)

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

§ § § § §

pg_dumpのデフォルトACLと外部キー制約のソートが修正されました。 (Kirill Reshke, Álvaro Herrera) (17)(16)(15)(14)(13)

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

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

pg_dumpで別々にダンプされたドメイン制約のコメントに、適切な依存関係を示すラベルが付与されるようになりました。 (Noah Misch) (17)(16)(15)(14)(13)

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

§ § § § §

pg_restoreでリストア対象外のパブリケーションおよびサブスクリプションのコメントとセキュリティラベルがスキップされるようになりました。 (Jian He, Fujii Masao) (17)(16)(15)(14)(13)

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

§ § § § § § § § § §

LLVMバージョン21以降でビルドが可能なように修正されました。 (Holger Hoffstätte) (17)(16)(15)(14)(13)

§ § § § §

mesonでビルドする場合、makefileビルドと同様に特別な最適化フラグをnumeric.cとchecksum.cに適用するようになりました。 (Nathan Bossart, Jeff Davis) (17)(16)

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

§ § § §

SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

PostgreSQL 17.6 に関する技術情報

データベース技術グループ — Sun, 07 Sep 2025 23:55:47 +0000

このリリースは 17.5 からの修正リリース（2025年 8月 14日リリース）です。
17.X からのアップデートではダンプ、リストアは不要です。

ただし、BRIN numeric_minmax_multi_opsインデックスを使用している場合には、インデックス再作成することを推奨します。下記の4番の項目を参照してください。

また、17.5 よりも前のバージョンからアップデートする場合には、17.5のリリース情報も参照してください。

PostgreSQL 17.5 から 17.6 への変更点

17.6, 16.10, 15.14, 14.19, 13.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。

プランナの見積もり関数におけるセキュリティチェックが強化されました。 (Dean Rasheed) (17.6)(16.10)(15.14)(14.19)(13.22)

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

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

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

§ § § § § §

pg_dumpスクリプトが、リストアを実行するユーザーへの攻撃に使われるのが防止されました。 (Nathan Bossart) (17.6)(16.10)(15.14)(14.19)(13.22)

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

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

§ § § § § § § §

pg_dumpの出力にあるコメント内の名前に含まれる改行がスペースに変換されるようになりました。 (Noah Misch) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

BRINの組み込み演算子クラスnumeric_minmax_multi_opsが誤った距離計算をしてしまう問題が修正されました。 (Peter Eisentraut, Tom Lane) (17.6)(16.10)(15.14)(14.19)

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

§ § § § §

元々は存在しなかった受け入れ可能なXML入力サイズに関する上限がなくなりました。 (Michael Paquier, Erik Wienhold) (17.6)(16.10)(15.14)(14.19)(13.22)

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

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

同時更新によるMERGEの不具合が修正されました。 (Dean Rasheed) (17.6)

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)

§ §

継承の親テーブルへのMERGEが修正されました。 (Dean Rasheed) (17.6)(16.10)(15.14)

継承の親テーブルへの挿入は、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).

§ § §

文レベルのトリガを持つテーブルが、パーティションまたは継承の子テーブルになれるように修正されました。 (Etsuro Fujita) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

子テーブルである外部テーブルからの遷移タプルの収集を禁止するよう修正されました。 (Etsuro Fujita) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

予約済みプレフィックス付きの不明なカスタムパラメータのリセットを許可するようになりました。 (Nathan Bossart) (17.6)(16.10)(15.14)

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

§ § § §

ALTER SUBSCRIPTION ... DROP PUBLICATION実行時に発生しうるデッドロックが修正されました。 (Ajin Cherian) (17.6)(16.10)(15.14)(14.19)

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

§ § § § §

競合する名前を持つインデックスを作成する際に、競合状態となる時間が短縮されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § §

1つのコマンドで複数のテーブルをVACUUMする場合に、VACUUMオプションが間違って適用されてしまう問題が修正されました。 (Nathan Bossart, Michael Paquier) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § §

インデックスのないテーブルをVACUUMする際に、そのテーブルの空き領域マップが適切なタイミングで更新されるようになりました。 (Masahiko Sawada) (17.6)

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

§ §

SIMILAR TO正規表現内の文字クラスの処理が修正されました。 (Laurenz Albe) (17.6)(16.10)(15.14)(14.19)(13.22)

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:]]のように前に%_を記述した場合は、修正以前も期待どおりの結果が返ってきていました。

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

pg_dumpなどでビューや関数の定義を取得するため、問い合わせを逆解析する際、「FETCH FIRST 式 ROWS WITH TIES」句の式部分を常に括弧で囲むように修正されました。 (Heikki Linnakangas) (17.6)(16.10)(15.14)(14.19)(13.22)

単純でない式は括弧で囲む必要がありますが、型キャスト付きの値などを誤って単純な式と見なし、括弧で囲まず、構文として誤った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;
                      ^

checkpointerプロセスのfsyncリクエストキューのサイズを制限するように修正されました。 (Alexander Korotkov, Xuneng Zhou) (17.6)(16.10)(15.14)(14.19)(13.22)

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

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

ロジカルデコーディングで不完全なWALレコードの読み取り時に無限に待機し続けないように修正されました。 (Vignesh C) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

「MultiXactOffsetSLRU」と「MultiXactMemberSLRU」のLWLock待機イベント名の表記ゆれが修正されました。 (Bertrand Drouvot) (17.6)

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

§ §

pg_classのrelaclなど、データベースオブジェクトのアクセス権限を表す、ACL文字列内のロール名の引用符付けの一貫性のなさが修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

テーブルと外部テーブルのオプション名に等号 (=) を使用できないように修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § §

LZ4圧縮されたアーカイブデータの解凍が特定の条件下で失敗する問題が修正されました。 (Mikhail Gribkov) (17.6)(16.10)(15.14)

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

§ § § §

btreeインデックスのスキャン処理で稀にインデックスエントリを誤って削除済みとして扱ってしまう問題が修正されました。 (Peter Geoghegan) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § §

論理レプリケーションで他プロセスからのキャッシュ無効化メッセージを再送信しないように修正されました。 (vignesh C) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

レプリケーションスロットの同期設定が誤っていても、サーバが予期せず停止しないように修正されました。 (Fujii Masao) (17.6)

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

§ §

チェックポイント処理中の早過ぎる古いWALファイル削除が回避されました。 (Vitaly Davydov) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § §

レプリケーションスロットの確定済みフラッシュ位置を後方に移動しないようになりました。 (Shveta Malik) (17.6)(16.10)(15.14)(14.19)(13.22)

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

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

§ § § § §

新しい論理レプリケーションワーカを起動する前に過剰な遅延が発生しないようになりました。 (Tom Lane) (17.6)(16.10)

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

§ §

INSERT ... ON CONFLICTの論理レプリケーション中のメモリ解放後使用（use-after-free）が修正されました。 (Ethan Mertz, Michael Paquier) (17.6)(16.10)

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

§ § §

スタンバイサーバでのトランザクション待機を中断できるようになりました。 (Kevin K Biju) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § §

物理レプリケーションのスタンバイサーバで動作する論理wal senderが、スタンバイサーバでリプレイ済のデータのみ送信するようになりました。 (Alexey Makhmutov) (17.6)(16.10)

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

§ §

自動VACUUMにおけるリレーションごとのメモリリークが修正されました。 (Tom Lane) (17.6)(16.10)(15.14)

§ § §

XMLSERIALIZE(... INDENT) でのセッション存続期間のメモリリークが修正されました。 (Dmitry Kovalenko, Tom Lane) (17.6)(16.10)

§ § § § §

「バンプ」アロケータを使用して大きなメモリブロックを割り当てる際、メモリ不足となった後に発生する可能性のあるクラッシュが修正されました。 (Tom Lane) (17.6)

スナップショットなしでシステムカタログのTOASTされたフィールドを取得しようとする箇所が修正されました。 (Nathan Bossart) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § §

複数のテーブルまたがる制約がある場合に、制約を更新するとアサート失敗する問題が修正されました。 (Tom Lane, Jian He) (17.6)(16.10)(15.14)(14.19)(13.22)

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

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

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

§ § § § § § § § § § §

内部実装関数PortalRunMulti() の終了時点で必ずコマンドタグが決定されているとする誤ったアサートが削除されました。 (Álvaro Herrera) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

XMLTABLEのパース処理でアサート失敗する問題が修正されました。 (Richard Guo) (17.6)(16.10)(15.14)

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

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

§ § §

PL/pgSQLで式を並列実行できる機能が復元されました。 (Dipesh Dhameliya) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

PL/Pythonにおけるエラー報告処理で発生する特殊なケースのメモリリークが修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § § § § § §

hostaddrを使ってサーバのアドレスを指定した場合に、libpqのPQcancelCreate()関数が正しく動作するよう修正されました。 (Sergei Kornilov) (17.6)

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

§ §

libpqのPQport()関数が修正され、引数として渡された接続がNULL でない限りこの関数はNULLを返さないようになりました。 (Daniele Varrazzo) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

GSSAPI認証で16kBを超えるパケットが必要な場合に、認証処理が失敗しないよう修正されました。 (Jacob Champion, Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § §

SSLおよびGSSAPIによるデータ送信におけるタイミング依存の失敗が修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § §

ECPGアプリケーションにおける接続の検索時に、NULLポインタ参照が発生しないよう修正されました。 (Aleksander Alekseev) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

psqlのタブ補完がCOPYおよび\copy のオプションについて改善されました。 (Atsushi Torikoshi) (17.6)(16.10)(15.14)(14.19)

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

§ § § § §

pgbench で、複数のパイプライン同期メッセージを受けたときのアサート失敗が回避されました。 (Fujii Masao) (17.6)(16.10)(15.14)

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

§ § § §

pg_createsubscriberコマンドでサブスクリプションを初期化するときの、トランザクションリプレイの重複が修正されました。 (Shlok Kyal) (17.6)

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

§ §

pg_dumpがドメイン型におけるNOT NULL制約のコメントを確実にダンプするようになりました。 (Jian He, Alvaro Herrera) (17.6)

§ §

pg_dumpがドメイン型の制約のコメントを有効な順序で出力するようになりました。 (Jian He) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

全ての種類のデータベースオブジェクトについて、pg_dumpで安定したソート順を保つようになりました。 (Noah Misch, Andreas Karlsson) (17.6)(16.10)(15.14)(14.19)(13.22)

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

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

pg_dumpのフィルタファイルでオブジェクトタイプの誤った解析が修正されました。 (Fujii Masao) (17.6)

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

§ §

pg_restoreが、PostgreSQL 12より前のバージョンの pg_dumpで作られたディレクトリ形式のダンプからのラージオブジェクトのリストアにできない障害が修正されました。 (Pavel Stehule) (17.6)

（修正前のエラー発生例）
$ 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

pg_upgradeで一貫しない継承されたNOT NULL制約を検査するようになりました。 (Ali Akbar) (17.6)(16.10)(15.14)(14.19)(13.22)

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

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

pg_upgrade でターゲットデータベースクラスタの postgresql.conf の max_slot_wal_keep_size に設定があるときエラーが発生していたものが、修正されました。 (Dilip Kumar) (17.6)

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

§ §

initdb実行時に（すなわち-cで指定して）、track_commit_timestampが有効であるときのアサート失敗が回避されました。 (Hayato Kuroda, Andy Fan) (17.6)(16.10)(15.14)(14.19)(13.22)

§ § § § § §

pg_waldumpが「PREPARE TRANSACTION」のWALレコードで、不正な情報（削除された統計）を表示していたものが、修正されました。 (Daniil Davydov) (17.6)(16.10)(15.14)

§ § §

contrib/dblink の接続確立のときに接続リークの可能性があり、回避されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § §

contrib/pg_prewarmで巨大なshared_buffers設定に対処できるようになりました。 (Daria Shanina) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § §

contrib/pg_prewarm において、アサート失敗が発生しないよう修正されました。 (Masahiro Ikeda) (17.6)

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

contrib/pg_stat_statementsで、正規化されたクエリの$1、$2などのパラメータ番号に欠番が生じないよう修正されました。 (Sami Imseih) (17.6)(16.10)(15.14)(14.19)(13.22)

(欠番が発生する例)
=# 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)

§ § § § §

contrib/postgres_fdwのメモリリークが修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

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

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

§ § § § §

configureの--with-includesおよび--with-librariesオプションで指定されたディレクトリが、システム標準ディレクトリよりも先に検索されるようになりました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

configureでの__cpuid()および__cpuidex()のチェックが修正されました。 (Lukas Fittl, Michael Paquier) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

Solaris系プラットフォームで--with-pamオプションを指定した場合ビルドが失敗する問題が修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

GNU Hurdへ移植できるようコードが修正されました。 (Michael Banck, Christoph Berg, Samuel Thibault) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § § § § §

memset_s()の使用をC11標準に厳密に準拠するよう修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

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

§ § § § § §

MSVCでMesonを利用してビルドする際に、互換性に関する警告が出力されていたものが修正されました。 (Peter Eisentraut) (17.6)(16.10)

§ §

JSONBの比較を行う内部実装関数compareJsonbContainers()で、未初期化値に関するコンパイラ警告が出力されないよう修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

§ § § § § §

libxml2 2.14以上を利用してビルドした際に、deprecatedである旨の警告が出力されていたものが、修正されました。 (Michael Paquier) (17.6)(16.10)(15.14)(14.19)(13.22)

§ § § § § §

pg_locale.hをC++ でコンパイルする際の問題が修正されました。 (John Naylor) (17.6)(16.10)(15.14)(14.19)(13.22)

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

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

§ § § § § §

SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

PostgreSQL 18検証報告

データベース技術グループ — Mon, 18 Aug 2025 23:00:24 +0000

更新日: 2025年9月18日

2025年秋にリリース予定となっている PostgreSQL 18 の新機能や性能向上、非互換変更点の主要なものについて動作検証を行った結果を報告します。

本検証レポートは実施手順をコマンドレベルで記載しているため、PostgreSQL 18 の新機能を実際に動作させて確認したい方のガイドブックとしても活用できます。

PostgreSQL 18 の主要な強化点は以下の通りです。

性能向上
- 非同期I/O
- Btreeインデックスのスキップスキャン
- プランナ改善（WHERE句内にOR条件がある場合の最適化、ほか）
- GINインデックスの並列作成
- 大量のテーブルアクセス時のロック処理の改善
- 組み込み照合順序pg_unicode_fast
メジャーバージョンアップ
- プランナ統計情報の移行
- チェック処理の並列化オプションの追加
- –swapオプションの追加
SQL機能
- 仮想生成列の追加
- 更新系DMLのRETURNING句へOLD, NEWの追加
- UUID v7関数の追加
- 非決定論的な照合順序利用時のLIKE句のサポート
- CASEFOLD関数の追加
- 各種制約の追加（WITHOUT OVERLAPS、ほか）
- ラージオブジェクトに対するデフォルト権限設定のサポート
セキュリティ機能
- TLS v1.3 暗号スイートの追加
- postgres_fdw、dblinkへのSCRAM認証のパススルーオプションの追加
運用管理
- プランナ統計情報のダンプ／リストア
- EXPLAIN文の強化
- pg_stat_all_tablesへのVACUUM、ANALYZE総実行時間の追加
- 接続単位でのI/O・WAL利用量の取得
- 論理レプリケーション時の書き込み衝突の情報詳細化

本検証レポートではこれらを取り上げています。

検証レポート

レポートは以下リンクから参照できます。

PostgreSQL 18 検証レポート(2025年 9月 18日版、PDFファイル、88ページ、2MB)

PostgreSQL 18の機能のさらなる詳細はPostgreSQL 18公式ドキュメントを参照してください。

PostgreSQL 18 公式ドキュメント（英語）

SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

PostgreSQL 17.5 に関する技術情報

データベース技術グループ — Fri, 23 May 2025 00:04:40 +0000

このリリースは 17.4 からの修正リリース（2025年 5月 8日リリース）です。
17.X からのアップデートではダンプ、リストアは不要です。

ただし、パーティションテーブルに自己参照の外部キー制約がある場合には、これらの制約を再作成する必要があります。下記の2番の項目を参照してください。
また、BRIN bloomインデックスを使用している場合には、インデックス再作成することを推奨します。下記の3番の項目を参照してください。

また、17.1 よりも前のバージョンからアップデートする場合には、17.1のリリース情報も参照してください。

PostgreSQL 17.4 から 17.5 への変更点

17.5, 16.9, 15.13, 14.18, 13.21 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン番号を項目末尾に括弧書きで記載しています。

不正にエンコードされた文字列の検査で、1バイトのバッファ超過読み取りが防止されました。 (Noah Misch, Andres Freund) (17.5)(16.9)(15.13)(14.18)(13.21)

文字エンコーディングGB18030であるものとして文字列を検査するときに発生します。可能性は低いですが、メモリの末尾で非互換のマルチバイト文字が現れた場合に、SIGSEGVのクラッシュが発生するおそれがあります。サーバとlibpqを用いたクライアントアプリケーションの両方で該当します。(CVE-2025-4207)

§ § § § § § § § § §

パーティションテーブルで自己参照の外部キーを正しく扱えるようになりました。 (Álvaro Herrera) (17.5)(16.9)(15.13)(14.18)(13.21)

制約に参照されたテーブルが同じパーティションテーブルであるとき、子パーティションを作成または付加するときに外部キー制約に対するカタログエントリの作成に失敗していました。この結果、制約が完全には強制されませんでした。これは12.13、13.9、14.6時点の修正で混入したバグです。

パーティションテーブル上に自己参照外部キー制約を作成した後に、子パーティションの作成や付加を行っていた場合、不適切なカタログ内容を修正するために、このような外部キー制約を削除して作成し直すべきです。制約に違反している行が既にあるかもしれず、そのような場合、制約の再作成はエラーになり、データ修正の対応が必要となることに、注意してください。

§ § § § § § § § §

BRIN のサポートプロシージャ brin_bloom_union() で圧縮されたBRIN のサマリをマージするときにデータ損失を回避するように修正されました。 (Tomas Vondra) (17.5)(16.9)(15.13)(14.18)

当該コードでは圧縮したものの展開結果が入力と同一でないことを考慮しておらず、インデックス検索をしたときに行数が少なく返り、誤った問い合わせ結果が生じる可能性がありました。

この誤りはBRIN bloomインデックスが導入されたv14時点から存在しましたが、当該のコードパスは使われることが稀でした。v17でパラレルインデックス作成が導入されて、問題が顕在化しやすくなりました。

FROMのビューや関数に対する行全体のテーブル参照を使うUPDATE、DELETE、MERGEの問い合わせで、予期せぬエラー「ERROR: attribute ... has wrong type」が生じることがあり、修正されました。 (Tom Lane) (17.5)(16.9)(15.13)(14.18)(13.21)

（エラー発生例）
db1=# CREATE TABLE t4 (f1 int, f2 int);
db1=# INSERT INTO t4 VALUES (1, 10), (2, 20), (3, 30);
db1=# CREATE VIEW v4 AS SELECT * FROM t4 OFFSET 0;
db1=# UPDATE t4 SET f2 = v4.f2 FROM v4 WHERE v4.f1 = t4.f1 RETURNING v4;
ERROR:  attribute 3 of type record has wrong type
DETAIL:  Table has type record, but query expects v4.

§ § § § § § § § § § §

「DO NOTHING」アクションのパーティションテーブルに対するMERGEが修正されました。 (Tender Wang) (17.5)(16.9)(15.13)

一部の場合に予期せぬエラー「ERROR: unknown action in MERGE WHEN clause」が発生していました。

（エラー発生例 - マッチしないので 1行挿入されるのが正しい動作）
db1=# CREATE TABLE pt5 (a int, b int) PARTITION BY LIST(a);
db1=# CREATE TABLE p51 PARTITION OF pt5 FOR VALUES IN (1);
db1=# CREATE TABLE p52 PARTITION OF pt5 FOR VALUES IN (2);
db1=# MERGE INTO pt5 USING (SELECT 2 AS a) AS q ON pt5.a = q.a
      WHEN NOT MATCHED THEN INSERT VALUES (1, 2)
      WHEN MATCHED THEN DO NOTHING;
ERROR:  unknown action in MERGE WHEN clause

§ § §

INSERTコマンドで、テーブルがNULLを禁止する制約を伴うドメインデータ型の生成列（GENERATED）を持つときのエラーが防止されました。 (Jian He) (17.5)(16.9)(15.13)(14.18)

生成式が問題ない値を返す場合でも制約違反のエラーになっていました。

（エラー発生例 - 値が NULL ではないのにドメイン制約違反のエラーになる）
db1=# CREATE DOMAIN d6 AS int CHECK (VALUE IS NOT NULL);
db1=# CREATE TABLE t6 (a int, b d6 GENERATED ALWAYS AS (a * 2) STORED);
db1=# INSERT INTO t6 (a) VALUES (2);
ERROR:  value for domain d6 violates check constraint "d6_check"

§ § § §

WITH句の内にあるINSERT、UPDATE、DELETE、MERGEコマンドに付加された外側のCTE名の参照を正しく扱えるようになりました。 (Tom Lane) (17.5)(16.9)(15.13)(14.18)(13.21)

このような場合にパーサは、再帰が許されない場合であることを検出できず、CTEを使用可能な順序に並べ替える際にそのような参照を考慮することもできませんでした。

本来エラーになるべき問い合わせで、何らか結果が返ったり、アサート失敗が生じる動作が報告されました。潜在的にはクラッシュを引き起こす可能性があります。

（修正後の正常動作例 - このエラーが出ないというのがバグ）
db1=# CREATE TABLE t7 (id int);
db1=# INSERT INTO t7 VALUES (1),(2);
db1=# WITH RECURSIVE out_cte(n) AS 
      (WITH sub_cte AS (SELECT * FROM out_cte) DELETE FROM t7 RETURNING id)
      SELECT * FROM out_cte;
ERROR:  recursive query "out_cte" must not contain data-modifying statements

§ § § § §

JSONコンストラクタ式のキーでのキャストの誤った処理が修正されました。 (Amit Langote) (17.5)

以下のようにキーがjsonに暗黙キャストされる場合に、非スカラーのキーであることが検査されず、クラッシュを引き起こすことが報告されました。

（修正後の動作例 - 最後のSELECTでクラッシュすることがあった）
db1=# CREATE TYPE typ8 AS ENUM ('happy', 'sad', 'neutral');
db1=# CREATE FUNCTION f8_to_json(typ8) RETURNS json LANGUAGE sql IMMUTABLE
        AS $$ SELECT to_json($1::text); $$;
db1=# CREATE CAST (typ8 AS json) WITH FUNCTION f8_to_json(typ8) AS IMPLICIT;
db1=# SELECT JSON_OBJECT('happy'::typ8 : '123'::jsonb);
ERROR:  key value must be scalar, not array, composite, or json

引数が無名レコード型であるとき、array_agg()の並列化を行わないようになりました。 (Richard Guo, Tom Lane) (17.5)(16.9)

パラレルワーカーとの通信プロトコルでは、返されたレコードの型を特定することに対応していないためです。これまでパラレル実行時に「ERROR: input of anonymous composite types is not implemented」が発生することがありました。

（障害発生例 - 例でarray_dimsを使っているのは成功時の出力を小さくするため）
db1=# CREATE TABLE t9 (id int, v text);
db1=# INSERT INTO t9 SELECT g, md5(g::text) FROM generate_series(1, 400000) g;
db1=# VACUUM ANALYZE t9;
db1=# SET debug_parallel_query TO on;
db1=# SELECT array_dims(array_agg(s)) FROM (SELECT * FROM t9) s;
ERROR:  input of anonymous composite types is not implemented

§ §

入力がint2vector型、またはoidvector型であるとき、配列コンストラクタのARRAY(subquery)とARRAY[expression, ...]が正常に配列を生成できるように修正されました。 (Tom Lane) (17.5)(16.9)(15.13)(14.18)(13.21)

以下のように、生成した配列をunnest関数に与えるとクラッシュが発生していました。

（障害発生例 - oidv列を指定した場合も同様にクラッシュする）
db1=# CREATE TABLE t10 (i2v int2vector, oidv oidvector);
db1=# INSERT INTO t10 VALUES ('1', '10000');
db1=# SELECT ARRAY(SELECT i2v) FROM t10;
      array
------------------
 [1:1][0:0]={{1}}
(1 row)

db1=# SELECT unnest(ARRAY(SELECT i2v)) FROM t10;
server closed the connection unexpectedly

この修正はPostgreSQL 9.5より前の振る舞いに戻すものです。

§ § § § §

Ispell辞書のパース時に、無効な接辞が誤って報告される可能性が修正されました。 (Jacob Brazeal) (17.5)(16.9)(15.13)(14.18)(13.21)

§ § § § §

デフォルトを持つドメイン型の場合を正しく処理するようにALTER TABLE ADD COLUMNが修正されました。 (Jian He, Tom Lane, Tender Wang) (17.5)(16.9)(15.13)(14.18)(13.21)

ドメイン型にデフォルトがある場合、（明示的なDEFAULT句を指定せずに）その型の列を追加すると、既存の行にドメインのデフォルト値が設定されず、新しい列はNULLのままになっていました。

§ § § § § § § § § §

外部キー制約のON DELETE SET DEFAULTまたはSET NULLアクションで重複した列名がある場合の不正動作が修正されました。 (Tom Lane) (17.5)(16.9)(15.13)

本障害でアサート失敗やメモリエラーが出る動作が報告されました。クラッシュを引き起こす可能性もあります。

（報告された障害発生例）
db1=# CREATE TABLE t13 (c01 INT, c02 TEXT);
db1=# CREATE INDEX i13 ON t13 (c01);
db1=# INSERT INTO t13 (c01, c02) VALUES (0, 'abc');
db1=# CREATE LOCAL TEMP TABLE IF NOT EXISTS v878825600 ( c878825601 INT
  COMPRESSION DEFAULT CONSTRAINT cons_878825602 REFERENCES v878825600 MATCH
  SIMPLE ON UPDATE NO ACTION ON DELETE SET DEFAULT ( c878825601, c878825601,
  c878825601, c878825601, c878825601, c878825601, c878825601 ) PRIMARY KEY )
  ON COMMIT DELETE ROWS;
db1=# CREATE LOCAL TEMP TABLE IF NOT EXISTS v878825601 ( c878825601 INT
  COMPRESSION DEFAULT CONSTRAINT cons_878825602 REFERENCES v878825600 MATCH
  SIMPLE ON UPDATE NO ACTION ON DELETE SET DEFAULT ( c878825601, c878825601,
  c878825601, c878825601, c878825601, c878825601, c878825601 ) PRIMARY KEY )
  ON COMMIT DELETE ROWS;
ERROR:  pfree called with invalid pointer 0x103e61f (header 0x0000006000000001)

§ § §

外部キー制約のプロパティ変更が許可されなかった場合のエラーメッセージが改善されました。 (Álvaro Herrera) (17.5)(16.9)(15.13)(14.18)(13.21)

（報告された不適切なエラーメッセージ）
db1=# CREATE TABLE pk14 (a int PRIMARY KEY);
db1=# CREATE TABLE fk14 (a int REFERENCES pk14);
db1=# ALTER TABLE fk14 ALTER CONSTRAINT fk14_a_fkey DEFERRABLE,
      ALTER CONSTRAINT fk14_a_fkey NO INHERIT;
ERROR:  ALTER CONSTRAINT statement constraints cannot be marked NO INHERIT

（本来出力されるべきエラーメッセージ）
ERROR:  FOREIGN KEY constraints cannot be marked NO INHERIT

§ § § § §

ON COMMIT DELETE ROWSとマークされた一時テーブルのrelhassubclassフラグをリセットする際のエラーが回避されました。 (Noah Misch) (17.5)(16.9)(15.13)(14.18)(13.21)

（報告されたエラー発生例）
db1=# CREATE TEMPORARY TABLE p15 (a int PRIMARY KEY) ON COMMIT DELETE ROWS;
db1=# CREATE TEMPORARY TABLE c15 () INHERITS (p15);
db1=# ANALYZE;
db1=# DROP TABLE c15;
db1=# ANALYZE;
ERROR:  tuple to be updated was already modified by an operation triggered by the current command

§ § § § §

XMLSERIALIZE()のINDENTオプションで不足していた逆解析が追加されました。 (Jim Jones) (17.5)(16.9)

以前は、XMLSERIALIZE(... INDENT)を使用するビューまたはルールがINDENT句なしでダンプされ、リストア後に誤った問い合わせ結果が発生していました。

§ § § §

FILTERオプションとORDER BY（またはDISTINCT）の両方のオプションを持つ集約関数の引数を早期評価しないようになりました。 (David Rowley) (17.5)(16.9)

ORDER BYまたはDISTINCTが指定されている場合、Aggプランノード内でソートを行うのではなく、集約入力値を事前にソートすることを検討します。しかし、集約入力に失敗する可能性のある式（例えば、入力の除数の一部が0になる可能性がある除算など）が含まれ、そのような失敗を防ぐためのFILTER句がある場合、これは問題となります。事前にソートすると、式の評価がFILTERテストの前に押し出され、いずれにせよエラーが発生する可能性があります。FILTERがあり、入力式が単純なVarやConstよりも複雑なものである場合は、事前ソートを行わないようにすることで、これを回避するようになりました。

（報告された障害発生例）
db1=# CREATE TABLE t17 (id int, data jsonb);
db1=# INSERT INTO t17 (id, data) VALUES
      (1,'{"a": null}'), (2,'{"a": "2"}'), (3,'{"a": "2"}'), (4,'{"a": ""}');
db1=# SELECT array_agg(distinct (data->>'a')::int)
        FILTER (WHERE data->>'a' IS NOT NULL AND data->>'a' != '') FROM t17;
ERROR:  invalid input syntax for type integer: ""

§ §

外部結合が存在する場合のNOT NULL制約列からの誤った推論が修正されました。 (Richard Guo) (17.5)

外部結合の後に適用されるので冗長ではない（外部結合で NULL が生じうる）にもかかわらず、場合によってはプランナが問い合わせ条件「IS NOT NULL」を破棄していました。

複合型の値に適用される「IS [NOT] NULL」テストに基づく誤った最適化が回避されました。 (Bruce Momjian) (17.5)

要素がNULLである複合型の値は、NOT NULL制約では排除されませんが、IS NULL／IS NOT NULL式ではNULLとして扱われます。そうではない一貫性に欠けた振る舞いがあり、誤った問い合わせ結果が生じていました。ドキュメントにも複合型についてはNOT NULL制約とCHECK (VALUE IS NOT NULL)制約は同じでは無いことが明記されました。

（修正前バージョンでの誤動作例 - id=1 の行のみ選択されるのが正しい動作）
db1=# CREATE TYPE typ19 AS (m1 int, m2 int);
db1=# CREATE TABLE t19 (id int, v typ19 NOT NULL);
db1=# INSERT INTO t19 VALUES (1, '(10,20)'), (2, '(,)');
db1=# SELECT id, v, (v IS NULL) AS isnull FROM t19 WHERE v IS NOT NULL;
 id |    v    | isnull
----+---------+--------
  1 | (10,20) | f
  2 | (,)     | t
(2 rows)

プランナがトップレベルの式内で複数のハッシュ可能なScalarArrayOpExpr部分式を認識できない問題が修正されました。 (David Geier) (17.5)(16.9)(15.13)(14.18)

この結果、ハッシュテーブルで処理できるはずの追加の部分式（すなわち、右辺が全て定数のIN、NOT IN、= ANY）が不必要に非効率的に実行されることがありました。

内部でハッシュテーブルを使うかどうかはEXPLAINの出力には現れませんが本修正で性能改善が期待できます。以下のような形状の問い合わせが該当します。

SELECT * FROM t20
  WHERE c1 IN ('certainstring1', 'certainstring3', 《...多数の項...》)
     OR c1 IN ('certainstring2', 'certainstring4', 《...多数の項...》);

§ § § §

低いfillfactor設定値による誤ったテーブルサイズの推定値が修正されました。 (Tomas Vondra) (17.5)

まだANALYZEが実行されていないテーブルの行数をプランナが推定する時、テーブルのfillfactor設定を推定に使用しますが、その結果を少なくとも1ページあたり1行に制限する処理が省略されていました。fillfactorの値が低い場合、推定値が不当に小さくなる可能性がありました。

Bitmap Heap Scanにおけるskip fetch最適化が無効になりました。 (Matthias van de Meent) (17.5)(16.9)(15.13)(14.18)(13.21)

この最適化を使用すると、並行して実行されるVACUUM処理がページをall-visibleとマークした時に、デッドタプルが返されることがあることが判明しました。これにより誤った問い合わせ結果が生じる可能性があります。

§ § § § §

多数の検索キーがある場合のGINインデックス検索起動時の性能問題が修正されました。 (Tom Lane, Vinod Sridharan) (17.5)(16.9)(15.13)(14.18)(13.21)

多くのキーを持つインデックス可能な句（例えば、配列要素が数万個ある「jsonbcol ?| array[...]」）は、クエリの開始に O(N2) の時間を要しており、またその処理中にキャンセルもできませんでした。

§ § § § § § § § § §

BRINインデックスの演算子クラスでサポートされてないプロシージャを検出して、エラーが報告されるようになりました。 (Álvaro Herrera) (17.5)(16.9)(15.13)(14.18)(13.21)

これまでクラッシュが生じていました。

§ § § § §

Appendプランノードの非同期サブプランの待機中に、クエリキャンセルなどの割り込みに応答できるようになりました。 (Heikki Linnakangas) (17.5)(16.9)(15.13)(14.18)

以前の動作では、サブプランのいずれかが準備完了するまで何も処理されませんでした。

§ § § §

稼働中のwal senderのI/O統計をより高頻度に報告するようになりました。 (Bertrand Drouvot) (17.5)(16.9)

これまでは、pg_stat_ioビューはwal senderによるI/O実行をプロセス終了まで集計していませんでした。これからはそのようなI/Oも最大1秒遅れで報告されます。

§ §

起動直後のsynchronous_standby_names設定の扱いについて、競合状態が修正されました。 (Melnikov Maksim, Michael Paquier) (17.5)(16.9)(15.13)(14.18)(13.21)

起動後の短時間において、synchronous_standby_namesが有効であるのに、バックエンドプロセスが同期コミットを待機しない場合があり得ました。

§ § § § §

問い合わせ内での設定パラメータio_combine_limitの変更が有効になりました。 (Thomas Munro) (17.5)

設定パラメータscram_iterationsがINT_MAX（2147483647）に設定されている場合の無限ループが回避されました。 (Kevin K Biju) (17.5)(16.9)

「ALTER ROLE role1 WITH PASSWORD 'pass'」などで応答がなくなります。

§ §

json_array()関数の副問い合わせの二重変換によりクラッシュを起こす可能性があり、回避されました。 (Tom Lane) (17.5)(16.9)

json_array()関数にWITH句を伴う問い合わせを渡した場合にアサート失敗や予期せぬエラーが生じる動作が報告されました。

（エラー発生例）
db1=# SELECT json_array( WITH x AS (SELECT 1) VALUES (TRUE) );
ERROR:  unexpected utility statement in WITH

（修正後バージョンでの出力）
 json_array
------------
 [true]
(1 row)

§ §

内部関数pg_strtof()の引数endptrがNULLの場合にクラッシュする問題が修正されました。 (Alexander Lakhin, Tom Lane) (17.5)(16.9)(15.13)(14.18)(13.21)

引数endptrにNULLが指定されているコードはリリース済のPostgreSQLには存在しないので、通常影響はありません。

§ § § § §

GUCパラメータの一部設定において、メモリ不足発生後にクラッシュする問題が修正されました。 (Daniel Gustafsson) (17.5)(16.9)

§ §

Snowball語幹処理でメモリ不足が発生した場合にクラッシュする問題が修正されました。 (Maksim Korotkov) (17.5)(16.9)(15.13)(14.18)(13.21)

§ § § § §

実行計画作成時に、メモリ解放してはいけないSpecialJoinInfo構造体まで解放してしまう問題が修正されました。 (Richard Guo) (17.5)

これにより、パーティションワイズ結合が有効な場合に、クラッシュすることがありました。

無効化済のレプリケーションスロットがコピーできないようになりました。 (Shlok Kyal) (17.5)(16.9)

これまでは、削除済みのWALを指している無効なスロットをコピーできてしまい、意図しないエラーやデータ破損につながる可能性がありました。

§ §

ホットスタンバイではないスタンバイサーバ上で論理レプリケーションスロットをリストアできないようになりました。 (Masahiko Sawada) (17.5)(16.9)

wal_levelがlogicalより低く設定されていると、スロットが有効なまま残り、昇格後にアサート失敗する可能性がありました。

ここでの「リストア」はPostgreSQLサービス起動時にファイルに記録されていたスロットを読み込んで有効化することを指します。

§ §

論理デコーディングでデコーディング位置を指定の位置まで進める処理で、レプリケーションスロットのcatalog_xminが過剰に進められてしまう問題が修正されました。 (Zhijie Hou) (17.5)(16.9)(15.13)(14.18)(13.21)

本来WAL読取処理に必要なはずのカタログ情報がVACUUMで削除され、誤動作やデータの不整合を引き起こす可能性がありました。

§ § § § §

強いロックを取らないDDL操作が論理レプリケーションの対象テーブルである場合にデータ破損を起こす可能性があり、修正されました。 (Shlok Kyal, Hayato Kuroda) (17.5)(16.9)(15.13)(14.18)(13.21)

ALTER PUBLICATION ADD TABLEやALTER TYPEなど、強いロックを取らないDDLによりカタログが更新された場合、WALをデコードする処理がその情報を取得できず、古いカタログ情報を使ってデコードしてしまうことで、結果としてデータが破損してしまう可能性がありました。

§ § § § § § § § § §

apply workerがエラーに遭遇したものの、PL/pgSQLの関数などでエラー処理された場合に、レプリケーションオリジンを誤ってリセットする問題が修正されました。 (Hayato Kuroda) (17.5)(16.9)

この結果、同じデータが再度適用されデータが重複してしまうことがありました。

§ §

サブスクライバ側のパーティションテーブルにBRINインデックスが存在する場合に、論理レプリケーションのapply workerプロセスがクラッシュすることがあり、修正されました。 (Tom Lane) (17.5)

論理レプリケーションのインデックス検索で重複したスナップショットの作成を回避するようになりました。 (Heikki Linnakangas) (17.5)(16.9)(15.13)(14.18)(13.21)

この誤りによる実害はありません。

§ § § § § § § § § §

サブスクリプション作成時に、オリジンが混在している場合の検知が改良されました。 (Hou Zhijie, Shlok Kyal) (17.5)(16.9)

サブスクリプション作成時に、サブスクライブ先のテーブルが他のパブリケーションを追随している場合、重複したデータの受信につながる可能性があるため、警告が表示されます。今回の変更では、パーティションの親テーブルまたは子テーブルが別のパブリケーションを追随している場合も警告が出力されるようになりました。

§ §

リカバリタイムラインの選択が不適切である場合、エラーメッセージに誤ったチェックポイントに関する情報が出力されていましたが、修正されました。 (David Steele) (17.5)(16.9)(15.13)

要求されたリカバリタイムラインに到達できない場合、報告されるチェックポイントとタイムラインは、存在する場合、backup_labelから読み取られた値になります。このメッセージは以前はpg_controlファイルから値を報告していましたが、これはbackup_labelのない制御ファイルからリカバリする場合は正しいのですが、backup_labelがある場合には正しくありませんでした。

§ § §

smgropen()内の操作順序が修正されました。 (Andres Freund) (17.5)

smgr_openコールバックを呼び出す前にSMgrRelationオブジェクトが完全に初期化されていることを確認するようになりました。これにより、コールバックが失敗した場合でも適切にクリーンアップされます。

pgstat_report_stat()内の誤ったアサートが削除されました。 (Michael Paquier) (17.5)(16.9)(15.13)

pgstat_report_stat()は、実行中のプロセスが自身の統計情報を定期的にサーバに報告するための関数です。特にPostgreSQL 16以降では、WAL senderは定期的に自身のI/O統計情報を報告するようになりましたが、このレポート処理が、他の状況で発生する可能性のあるpgstat_report_stat()の呼び出しと競合するケースが発生しました。また、非常に稀ではありますが、15.xでもバックグラウンドワーカーなどのプロセスによるpgstat_report_stat()の同時呼び出しによって同様の競合が引き起こされる可能性がありました。

§ § §

gistFindCorrectParent()の過度に厳密なアサートが修正されました。 (Heikki Linnakangas) (17.5)(16.9)(15.13)(14.18)(13.21)

§ § § § §

maintenance_work_memの値が非常に小さい場合、並列バキュームでのアサート失敗が回避されるようになりました。 (Masahiko Sawada) (17.5)

プライマリサーバの再起動時にスタンバイサーバで稀に発生するアサート失敗が修正されました。 (Heikki Linnakangas) (17.5)(16.9)(15.13)(14.18)

内部関数が、古いトランザクションを「実行中でなくなった」とマークする際に、トランザクションの実行状況に関する変数を更新しておらず、ホットスタンバイ中にアサート失敗が発生する可能性がありました。

§ § § §

PL/pgSQLで、単純なSELECT式クエリでスクロール可能なカーソルが定義されている場合に発生するエラー「ERROR: unexpected plan node type」を回避するようになりました。 (Andrei Lepikhov) (17.5)(16.9)(15.13)(14.18)(13.21)

§ § § § §

pg_dumpの--cleanモードで、個々のインデックスパーティションを削除しようとしないようになりました。 (Jian He) (17.5)(16.9)(15.13)(14.18)(13.21)

サーバはこのようなDROPコマンドを拒否します。パーティションは、親テーブルまたはパーティションインデックスのいずれかの後続のDROPで、いずれにせよ削除されるため、実際には何の影響もありません。ただし、エラーは発生するため、psqlの--single-transactionモードでリストアする際にはリストアのトランザクション全体が失敗するため、問題を引き起こしました。

§ § § § §

pg_dumpallにおいて、pg_auth_membersに無効なロールのOIDが含まれている場合、無効なロールに対するGRANTコマンドが出力されないようになりました。 (Tom Lane) (17.5)(16.9)(15.13)(14.18)(13.21)

代わりに警告を出して該当エントリをスキップするようになりました。これは、GRANTとDROP ROLEが競合するタイミングで発生する可能性があったカタログ破損への対策です。過去のバージョンではこのような破損が確認されていました。

§ § § § §

pg_amcheckおよびpg_upgradeにおいて、libpqが確保したメモリを解放する際に正しい関数が使用されるようになりました。 (Michael Paquier, Ranier Vilela) (17.5)(16.9)(15.13)(14.18)

これまで、Windows環境の特定のビルド構成、たとえばlibpqがデバッグビルドで、それを使用するアプリケーションが非デバッグビルドである場合などに、クラッシュが発生する可能性がありました。

§ § § § § § § §

reindexdbコマンドの並列リインデックス処理におけるスケジューリング (Alexander Korotkov) (17.5)

の問題が修正されました。従来は、指定した並列数にならない場合がありました。

contrib/pageinspectのheap_page_items()関数において、破損したページを読み込んでもクラッシュしないようになりました。 (Dmitry Kovalenko) (17.5)(16.9)(15.13)(14.18)(13.21)

§ § § § §

contrib/pg_freespacemapのpg_freespacemap()関数が、ビューなどストレージを持たないリレーションを指定するとアサート失敗する問題が修正されました。 (Tender Wang) (17.5)(16.9)(15.13)(14.18)(13.21)

このような対象を指定した場合は、エラーとして拒否されるようになりました。

§ § § § §

contrib/postgres_fdwで、サブクエリからの制限条件を引き出さないようになりました。 (Alexander Pyhalov) (17.5)

この修正により、稀に発生するエラー「ERROR: expected expression in subquery output」が回避されます。

システムのインクルードディレクトリに古いバージョンのlibpq_fe.hが存在する場合にビルドが失敗する問題が修正されました。 (Tom Lane) (17.5)

macOS 15.4でビルドが失敗する問題が修正されました。 (Tom Lane, Peter Eisentraut) (17.5)(16.9)(15.13)(14.18)(13.21)

このmacOSアップデートにより、strchrnul()関数の設定プローブが機能しなくなっていました。

§ § § § §

読み込みストリームのバッファ単位データのvalgrindラベル付けが修正されました。 (Thomas Munro) (17.5)

これはPostgreSQLのリリース版のコアコードには影響しませんが、バッファ単位のデータ機能を使用する拡張がvalgrindでのテスト中に誤ったエラーが発生する可能性がありました。

文字列ハッシュコードに関するvalgrindの警告がでないようになりました。 (John Naylor) (17.5)

タイムゾーンデータファイルが tzdata release 2025b に更新されました。 (Tom Lane) (17.5)(16.9)(15.13)(14.18)(13.21)

中国の夏時間法の変更とイランの歴史的修正が含まれます。また、チリのアイセン州のタイムゾーンが年間を通じて UTF-03 に変更されてAmerica/Santiago から分離したため、新たに America/Coyhaique が追加されました。

§ § § § §

contrib/dblinkの問い合わせがキャンセルできるようになりました。 (Noah Misch) (16.9)(15.13)(14.18)(13.21)

これは17.xバージョンむけの変更の後方適用です。デッドロック検出の失敗のためにCREATE DATABASEとDROP DATABASEで起こりうるハングアップを防止します。

§ § § § § § §

スナップショット作成で起きるアサート失敗が修正されました。 (Masahiko Sawada) (15.13)(14.18)

ロジカルレプリケーションで問題が報告されました。

§ §

アーカイブからリストアされたWALファイルの破損を防ぐため、アーカイブリカバリ時にはWALファイルの再利用と事前割り当てを行わないようになりました。 (Noah Misch, Arun Thirupathi) (14.18)(13.21)

これは15.x以降バージョンむけの修正の後方適用です。当初は外観的な修正と考えられていましたが、その後の修正を通してデータ破損の防止に有効と判明しました。

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

SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

PostgreSQL 17.4 に関する技術情報

データベース技術グループ — Fri, 28 Feb 2025 04:37:37 +0000

このリリースは 17.3 からの修正リリース（2025年 2月 20日リリース）です。
17.X からのアップデートではダンプ、リストアは不要です。

ただし、17.1 よりも前のバージョンからアップデートする場合には、17.1のリリース情報も参照してください。

PostgreSQL 17.3 から 17.4 への変更点

17.4, 16.8, 15.12, 14.17, 13.20 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。

libpqのクォート付加を行うAPI関数について追加の修正が行われました。 (Andres Freund, Tom Lane) (17)(16)(15)(14)(13)

CVE-2025-1094への対応で、1つ重大な見落としがありました。PQescapeLiteral() およびPQescapeIdentifier() は、文字列の長さを指定するパラメータを適切に考慮せず、入力文字列のヌル終端文字までを常に読み取っていました。この結果、呼び出し側が長さを指定するパラメータを使用して文字列を切り詰めようとしていた場合でも、不要なテキストが出力に含まれる可能性がありました。さらに、入力テキスト文字列がヌル終端文字がない場合、不正なメモリを読み込み、クラッシュを引き起こす可能性がありました。

合わせて、これらのクオート関数のすべてにおいて、無効なエンコーディングが検出された際の処理が変更されました。これまでは無効なシーケンス全体を置き換えていましたが、今回の変更では、その文字の最初のバイトのみが置き換えられました。これにより、クオート済みの文字列に対して呼び出し側アプリケーションが追加の処理を行った場合のリスクを低減できます。

pg_createsubscriberの小さなメモリリークが修正されました。 (Ranier Vilela) (17)
mesonがbsd_auth.hを利用できるか正しく検知できるよう修正されました。 (Nazir Bilal Yavuz) (17)(16)
遷移テーブルを利用するパーティションテーブルのトリガーに関するクラッシュが修正されました。 (Kyotaro Horiguchi) (14)(13)

AFTER UPDATEトリガーとAFTER DELETEトリガーの両方が存在する場合、遷移テーブルの必要性が誤って判定されていました。この誤判定により、パーティションをまたぐ更新をした際にクラッシュする問題がありました。

SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

PostgreSQL 17 – SRA OSS Tech Blog

PostgreSQL 17.11 に関する技術情報

PostgreSQL 17.10 から 17.11 への変更点

PostgreSQL 17.10 に関する技術情報

PostgreSQL 17.9 から 17.10 への変更点

PostgreSQL 17.9 に関する技術情報

PostgreSQL 17.8 から 17.9 への変更点

PostgreSQL 17.8 に関する技術情報

PostgreSQL 17.7 から 17.8 への変更点

PostgreSQL 17 増分バックアップの実践活用と運用上の考慮点

PostgreSQLのバックアップの種類

論理バックアップ

物理バックアップ

増分バックアップとメリット

増分バックアップの手順

増分バックアップのコマンド

各世代増分バックアップの中身を確認

増分バックアップのストレージコストと取得時間

pg_combinebackup のオプション

増分バックアップ使用上の注意点

パラメータの管理

フルバックアップ～増分バックアップの保存

ストレージ容量

増分バックアップと PITR と両立したリストア手順

まとめ

PostgreSQL 17.7 に関する技術情報

PostgreSQL 17.6 から 17.7 への変更点

PostgreSQL 17.6 に関する技術情報

PostgreSQL 17.5 から 17.6 への変更点

PostgreSQL 18検証報告

検証レポート

PostgreSQL 17.5 に関する技術情報

PostgreSQL 17.4 から 17.5 への変更点

PostgreSQL 17.4 に関する技術情報

PostgreSQL 17.3 から 17.4 への変更点

増分バックアップと
PITR と両立したリストア手順