クライアントライブラリ libpq で提供されるクォートを付加する関数群は、これからは入力のエンコーディング正当性の検査を十分に行うようになります。無効な文字が検出された場合、可能であればエラーを返します。エラーを返す規則が無い場合には、確実にサーバが無効なエンコーディングを報告し、介在するプロセスがシングルクォートやバックスラッシュ等に偶然一致するバイト列に騙されないように、出力文字列が調整されます。

本変更は、作りこまれた入力をこれらの関数でクォートすることで可能となる SQL インジェクション攻撃を防止する目的です。サーバ側で必ずエンコーディング検査が行われるので、関数でクォートした結果の文字列を直接 PostgreSQL サーバに送っているときには危険はありません（一般的にはこのように使用しているはずです）。しかしながら、結果の文字列を psql や他のクライアント側のコードに渡している場合に危険がありました。歴史的にこれらのコードはエンコーディングを注意深く検査しておらず、また、多くの場合に不正コードに対する挙動が明確にされていませんでした。

本修正が有効なのは、クォート関数とサーバ、および、介在する処理が、使用する文字エンコーディングについて合意している場合に限られます。信用できない入力を SQL コマンドに挿入するアプリケーションはこの点を確実にしなければなりません。

本修正に該当する libpq の API関数:
PQescapeLiteral()
PQescapeIdentifier()
PQescapeString()
PQescapeStringConn()

これは一部で問題を引き起こすと判明した 17.0 の変更を元に戻すものです。name 型の最大長 64バイト（実装コードでは NAMEDATALEN - 1）以上の名前を切り捨てるときに文字エンコーディングを認識するようになりましたが、従来の単にバイト数で切り捨てる動作に戻されました。

長さが超過したデータベース名やユーザ名で接続できていたものが、できなくなってしまった事象が報告されました。

（16.x と本修正以降では以下の「FATAL:  role ... does not exist」は発生しない）
db1=# CREATE USER aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggggggg;
NOTICE:  identifier "aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggggggg" will be truncated to "aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffggg"
CREATE ROLE
db1=# \c db1 aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggggggg
connection to server on socket "/tmp/.s.PGSQL.5432" failed: FATAL:  role "aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggggggg" does not exist
Previous connection kept

pg_database の datallowconn、pg_roles の rolcanlogin、および（GRANT/REVOKE で制御する）ロールのデータベースに対する CONNECT 権限を、パラレルワーカー開始時に検査しなくなりました。リーダープロセスで同様の検査を通っているので、それだけで十分と判断されました。これにより、例えば、パラレル問い合わせでログイン権限の無いロールでリーダープロセスが動作しているときの予期せぬエラーを回避できます。

同様に、reserved_connections 設定や pg_database の datconnlimit、pg_roles の rolconnlimit による接続数上限の検査も、通常のバックエンドのみに行うようになりました。

pg_wait_events ビューでは「Lock」が付加されない待機イベント名（name列）が出力されるため、pg_stat_activity ビューの wait_event 列の値と不一致が生じていました。本修正で「LWLock」型については「Lock」が付加されない待機イベント名に統一されます。

17.0～17.2 に対して非互換の変更となります。

Run Condition: 最適化を伴う WindowAgg プラン要素が使われて、結果データ型が（text などの）リファレンス渡しの型であった場合に、新たな計算結果ではなく手前のパーティションの結果が再利用されてしまい、クラッシュや誤った問い合わせ結果が生じる可能性がありました。

この誤りにより、プロセスが VACUUM 済みのデータにアクセスを試みてしまう可能性がありました。知られている症状は一時的にエラー「ERROR: could not access status of transaction」が発生することです。

TransactionXmin と MyProc->xmin はいずれも実装コード中の変数で、実行中トランザクションの最小トランザクションID を意味します。

これにより例えば、既存セッション内で新たに作られた関数を使用できない、といったことが発生します。

リレーション切り詰めを実行するためのファイルシステムコールは失敗する可能性があり、例えば削除されたデータが生き返ってしまうなど、ストレージに一貫性に欠けた状態を残します。これを本当に防ぐことはできませんが、そのような失敗を PANIC にすることで回復することができます。すなわち、リカバリ起動の WAL リプレイで切り詰めを試みた直前まで復旧することで一貫性が回復します。これはとても望ましい振る舞いではありませんが、ファイル切り詰め失敗は十分に稀な事象であり、受け入れ可能な解決策と判断されました。

PANIC を起こさない従来の振る舞いはスタンバイでのエラーやデータ不一致の原因となっていて、これまでは VACUUM 処理でファイル切り詰めを無効化することが対策でした。

これにより修正されたファイルがチェックポイント完了前に fsync されず、そこで OS がクラッシュしたときにデータ破損の危険が生じるという、競合状態を回避します。

一部の場合に tg_updatedcols ビットマップに同トランザクション内の手前のコマンドで更新された列がセットされる可能性があり、これはトリガの誤動作の原因となります。

tg_updatedcols は C 言語で記述する更新トリガで受け取ることができる変数で、どの列が更新されたかを示すビットマップ値が格納されます。

外部キー制約が（パーティションテーブル全体ではなく）特定のパーティションに定義されていて、それが何らか別のパーティションテーブルを参照している場合、その外部キー制約を持つパーティションをデタッチすると、対応する pg_constraint のエントリが誤って更新されました。

これにより、「ERROR: could not find ON INSERT check triggers of foreign key constraint」のようなエラーが発生しました。

（障害動作例）
db1=# CREATE TABLE pt1 (id int PRIMARY KEY, d text) PARTITION BY RANGE(id);
db1=# CREATE TABLE pt1p1 PARTITION OF pt1 FOR VALUES FROM (0) TO (100);
db1=# CREATE TABLE pt2 (a int, b int) PARTITION BY LIST (a);
db1=# CREATE TABLE pt2p1 PARTITION OF pt2 FOR VALUES IN (1);
db1=# ALTER TABLE pt2p1 ADD FOREIGN KEY (a) REFERENCES pt1 (id);
db1=# ALTER TABLE pt2 DETACH PARTITION pt2p1;
ERROR:  could not find ON INSERT check triggers of foreign key constraint 103641

pg_get_constraintdef 関数がドメインの NOT NULL制約に対応した、システムカタログ pg_constraint の行の OID に対して、「NOT NULL」という文字列を返すべきところ、エラー「ERROR: invalid constraint type "n"」を出していました。

数値をつなげた書式の場合に、FF1 から FF6 の指定がいずれも正しく動作しませんでした。

（誤動作例）
db1=# SELECT to_timestamp('20251122123456123456', 'YYYYMMDDHH24MISSFF1');
ERROR:  date/time field value out of range: "20251122123456123456"

（期待される応答）
       to_timestamp
--------------------------
 2025-11-22 12:34:56.1+09
(1 row)

（問題が生じない区切り文字があるケース）
db1=# SELECT to_timestamp('2025-11-22 12:34:56.123456', 'YYYY-MM-DD HH24:MI:SS.FF3');
        to_timestamp
----------------------------
 2025-11-22 12:34:56.123+09
(1 row)

JSON_EXISTS()、JSON_QUERY()、JSON_VALUE() が該当します。逆パースはビューをダンプ出力したり定義表示したりするときに行われます。

（誤動作例: 「AS "Xyz"」が「AS Xyz」になってしまっている）
db1=# CREATE VIEW v17 AS
        SELECT JSON_QUERY(jsonb 'null', '$"Xyz"' PASSING 1 AS "Xyz");
db1=# \sv v17
CREATE OR REPLACE VIEW public.v17 AS
 SELECT JSON_QUERY('null'::jsonb, '$"Xyz"' PASSING 1 AS Xyz RETURNING jsonb WITHOUT WRAPPER KEEP QUOTES) AS "json_query";

逆パースはビューをダンプ出力したり定義表示したりするときに行われます。

（誤動作例:「AS "Zz"」が「AS Zz」になってしまっている）
db1=# CREATE VIEW v18 AS SELECT * FROM
        XMLTABLE(XMLNAMESPACES('http://x.y/' AS "Zz"), '/Zz:rows/Zz:row'
		PASSING '10'
        COLUMNS a int PATH 'Zz:a');
db1=# \sv v18
CREATE OR REPLACE VIEW public.v18 AS
 SELECT a
   FROM XMLTABLE(XMLNAMESPACES ('http://x.y/'::text AS Zz), ('/Zz:rows/Zz:row'::text) PASSING ('10'::xml) COLUMNS a integer PATH ('Zz:a'::text))

この障害は、誤ったソート演算子によるデータのソートを引き起こし、その結果はクラッシュから目に見える問題が無い場合まで様々です。

（報告されたクラッシュする例）
db1=# CREATE TABLE t20 (c1 int, c2 numeric);
db1=# INSERT INTO t20 VALUES (0, NULL), (8, NULL);
db1=# SELECT c2, c2 FROM t20
      UNION
      SELECT DISTINCT c2, ta1.c1 FROM (
        SELECT c1, c2 FROM t20) AS ta1
        JOIN (SELECT c1, c1 FROM t20) AS ta2 ON true;
server closed the connection unexpectedly

以前は、いくつかの UNION 操作を 1つに統合しても安全か判断する際に、照合順序が無視されていました。これは非決定論的照合順序が導入される前はおそらく有効でしたが、現在は有効ではありません。照合順序が一意性の定義に影響を与える可能性がありました。

db1=# CREATE TABLE t21a (c text);
db1=# CREATE TABLE t21b (c text);
db1=# CREATE TABLE t21c (c text COLLATE "ja_JP");
db1=# explain SELECT c FROM t21a UNION SELECT c FROM t21b UNION SELECT c FROM t21c;
（17.2の実行プラン - 1つの Append と HashAggregate にまとめられている）
                                    QUERY PLAN
----------------------------------------------------------------------------------
 HashAggregate  (cost=128.60..169.40 rows=4080 width=32)
   Group Key: (("*SELECT* 1".c)::text)
   ->  Append  (cost=0.00..118.40 rows=4080 width=32)
         ->  Subquery Scan on "*SELECT* 1"  (cost=0.00..37.20 rows=1360 width=32)
               ->  Seq Scan on t21a  (cost=0.00..23.60 rows=1360 width=32)
         ->  Subquery Scan on "*SELECT* 2"  (cost=0.00..37.20 rows=1360 width=32)
               ->  Seq Scan on t21b  (cost=0.00..23.60 rows=1360 width=32)
         ->  Seq Scan on t21c  (cost=0.00..23.60 rows=1360 width=32)
(8 rows)
（17.3の実行プラン - 2段階に分かれている）
                                   QUERY PLAN
---------------------------------------------------------------------------------
 HashAggregate  (cost=149.00..189.80 rows=4080 width=32)
   Group Key: ((t21a.c)::text)
   ->  Append  (cost=67.60..138.80 rows=4080 width=32)
         ->  HashAggregate  (cost=67.60..94.80 rows=2720 width=32)
               Group Key: t21a.c
               ->  Append  (cost=0.00..60.80 rows=2720 width=32)
                     ->  Seq Scan on t21a  (cost=0.00..23.60 rows=1360 width=32)
                     ->  Seq Scan on t21b  (cost=0.00..23.60 rows=1360 width=32)
         ->  Seq Scan on t21c  (cost=0.00..23.60 rows=1360 width=32)
(9 rows)

本障害により、外部結合を含む問い合わせで、式に関する統計が使用できなかったり、「ERROR: corrupt MVNDistinct entry」が発生する可能性がありました。

この見落としにより、パーティションテーブルにアクセスする問い合わせで「ERROR: unrecognized node type ..」やその他の問題が発生する可能性がありました。

これは slotsync ワーカーの追加時に見落とされ、その結果、そのプロセススロットが通常のバックエンドプロセス用のプールから実質的に取得されていました。これにより、通常のバックエンドプロセス数が max_connections に近づいた場合、ワーカーの起動に失敗したり、構成された設定に従って成功するはずだった接続要求が失敗したりする可能性がありました。

slotsync ワーカーはストリーミングレプリケーションのフェイルオーバに対応したロジカルレプリケーションを構成するときに使われます。

これにより「ERROR: invalid DSA memory alloc request size ..」などのエラーを回避できるようになりました。これは、例えば数百万のテーブルを処理するトランザクションで発生する可能性があります。

dshash テーブルは実装内部の要素で、動的共有メモリ（DSM）を利用してプロセス間でデータ共有するためのハッシュデータ構造です。

bringetbitmap() は brin インデックスの実装コード内の関数です。結果値は統計目的のみで使用されるため、この誤りの動作への影響はほとんどありません。

このエラーにより、意図したよりも少ない数のバンクが使用され、競合が増加しましたが、機能上の不具合はありませんでした。

ワーカーを起動したり終了したりするバックエンドの負荷が非常に大きいことで、親プロセスがクライアントからの接続要求に即応できなくなるおそれがありました。

ラッチは PostgreSQL 実装内の排他制御の仕組みの 1つです。

これは、レコードの続きが別の WAL ソースから読み取る必要があるページにある場合に発生します。

これにより、稀に発生していた「PANIC: proc_exit() called in child process」が生じるケースを回避できます。

場合によっては、データ型が削除されても、その OID への参照が pg_amop または pg_amproc に残っている可能性がありました。これによってすぐに問題が発生することはありませんが、それを所有する演算子族を削除しようとすると失敗し、演算子族をダンプするときに pg_dump が誤った出力を生成することになります。

この修正により、演算子族/クラスの作成と変更によって必要な依存関係エントリが追加され、データ型を削除すると、依存する演算子族要素も削除されます。ただし、これは脆弱な既存の演算子族には役立ちません。そのため、不正なメンバーを持つ演算子族を削除するときに失敗しないように、DROP OPERATOR FAMILY コマンドにも手当てが行われました。

非常に大きなリレーションを作成したトランザクションが、誤ってリレーションを fsync する代わりに WAL にコピーすることで耐久性を確保すると決定し、wal_skip_threshold の目的を否定する可能性がありました。これは、wal_level が minimal に設定されている場合にのみ関係し、それ以外の場合は、いずれにしても WALコピーが必要です。

判明している症状は GRANT TABLESPACE の際に、「WARNING: you don't own a lock of type ExclusiveLock」が出力されることだけで、これは通常無害です。

本障害は標準的なビルドでは影響がないと考えられますが、理論的には危険です。

これは、gcc と clang 間の -moutline-atomics のデフォルト設定に関する不一致の結果として発生する可能性がありました。少なくとも Debian と Ubuntu は、armv8-a をターゲットとする gcc コンパイラと clang コンパイラを同梱していることが知られていますが、アウトラインアトミックを使用するかのデフォルトが異なります。

読み書きポインタが渡されると、等価関数はオブジェクトを変更したり削除したりする可能性があります。これは、NULLIF() の結果としてそれを返すことにした場合、好ましくありません。組み込みの等価関数ではおそらく問題はありませんが、PL/pgSQL でコーディングされた等価関数では簡単に失敗を実証できます。

対象列がドメイン型の場合、プランナは単なる NULL 定数だけでなく coerce-to-domain ステップを挿入する必要があり、この式は必要なステップをいくつか実行できませんでした。コアデータ型に基づくドメインでは既知の影響はありませんが、理論的には、拡張型に基づくドメインでエラーが発生する可能性がありました。

既存のデータはすべてゼロで上書きされます。コア PostgreSQL ではこのようなことは決しておこなわれませんので、これは PostgreSQL のコアでは問題ではありません。しかし、一部の拡張ではこのようなことがおこなわれます。

PostgreSQL のコアにはこれを実行するコードはありませんが、拡張では実行を希望するかもしれません。

PLyPlan.execute または plpy.cursor を繰り返し使用すると、PL/Python 関数の呼び出し中にメモリリークが発生していました。

以前は、タイプミスが原因で意図した警告が発行されていませんでした。

SJIS の一部の 2 バイト文字には、2 バイト目が ASCII バックスラッシュ ("\") に等しいものがあります。これらの文字はパス名の正規化によって破壊され、そのような文字を含む名前を持つファイルへのアクセスが妨げられていました。

このエラーにより、中断されたシステムコールが期待どおりに再開されないため、pgbench の -T オプションを使用する際、もしくは psql の \watch コマンドを使用する際に、誤動作につながる可能性がありました。

結果が false となる \if 分岐中に現れる \if コマンドが誤って \elif と同じように処理されていました。

pg_controlldata は CRC チェックが失敗した場合でも pg_control の内容を出力しようとするため、無効なフィールド値に対して誤動作しないように注意する必要があります。このパッチにより、無効なタイムスタンプと明らかに負の WAL セグメントサイズによって引き起こされるいくつかの問題が修正されました。

メモリリークは解凍操作ごとに発生するため、多数のテーブルや大きなオブジェクトを含むダンプで最も顕著になります。

これにより、拡張機能インストール時に contrib/cube への依存関係を解決できるようになり、検索パスに基づく障害や攻撃のリスクが軽減されます。

とくに v17 では、セキュリティ上の理由で検索パスが制限されたため、生成列などで使用できず、サーバをバージョンアップできないと報告を受けていました。そのため、この修正は v16 にも含まれており、拡張機能を事前にバージョンアップすれば、サーバをバージョンアップできるようになります。

以前は、brin_page_items()呼び出し時にクラッシュが発生する可能性がありましたが、代わりに拡張機能の更新を推奨するエラーが出力されます。

これにより、リモートサーバでクエリ処理開始前にキャンセルしようとして発生する競合状態が解消され、最初のリクエストが無視されるようになります。

CRC 命令をデフォルトで非対応の ARM 環境で使用するには -march オプションが必要ですが、最近の gcc では誤った設定でもエラーにならず、代わりに低速なソフトウェア CRC が選択されていました。

古いライブラリ名 ssleay32 および libeay32 がサポートされます。

これにより、拡張機能ビルド時の unresolved external symbol エラーが解消されます。

これは、 make および古い MSVC ビルド時と動作を一致させるための変更です。

これは、make ビルド時と動作を一致させるための変更です。

タイムゾーンデータファイルが tzdata release 2025a に更新されました。

以前は、既存ファイルが誤って上書きされるのを防ぐため、そうなっていましたが、途中で処理に失敗すると、同じファイルへのリンクが2つ存在した状態となり、後続の処理が混乱し、データ破損のリスクがありました。実際には、変更先のファイルが存在する状況でこの処理は行われないため、上書き防止よりデータ破損のリスクを回避したほうがよいと判断されました。

以前は、データディレクトリに相対パスでジャクションポイントを指定した場合や、ジャクションポイントが別のジャンクションポイントを指している場合、initdb が失敗していました。

v16 より前は C23 規格ではコンパイルできないため、検出されたコンパイラが C23 以降の場合、-std=gnu17 オプションで変更するようになりました。それでもコンパイルできない場合、 CFLAGS に手動でオプションを指定してください。

この変更は、アーカイブのパフォーマンスが極端に低下し、ダウンタイムやレプリカ損失につながるという報告を受け、もとは v15 で行われた修正がバックパッチされたものとなります。

2024/11/14のマイナーリリースにより、timescaledb や他のいくつかの拡張機能とのバイナリ互換性が意図せず壊れていました。ResultRelInfo 構造体を以前のサイズに戻されたことで、影響を受けたエクステンションをビルドし直す必要がなくなりました。

§ § § §

CVE-2024-10978 の修正により、非対話的なソース（ ALTER {ROLE|DATABASE} コマンドや PGOPTIONS 環境変数など）から設定されたロールの設定が適用されなくなる問題が発生していましたが、修正されました。

§ § § § § §

以前は、論理レプリケーションを再起動すると、スロットの再起動ポイントが、pg_replication_slots で以前に通知されていた値よりも古い値として再計算されることがありました。 これは、たとえば WALファイルが後の restart_lsn 値に基づいて削除される可能性があるため、好ましくありません。その場合、レプリケーションの再起動に失敗します。

§ § § § §

以前は、不運なケースで、pg_rewind がプライマリからリカバリに必要なWAL ファイルを削除してしまうことがありました。

特に、WALファイルがアーカイブ可能であるものの、まだアーカイブされていない場合（つまり、.ready ファイルが作成されているとき）に問題がありました。 以前のpg_rewind この状況ではこれらの WAL ファイルを削除してしまいました。さらに、新しく昇格したノードから取得でもこれらのWAL ファイルがリサイクル・削除してしまうと、 pg_rewind を実行したノードはリカバリに必要な WAL ファイルを入手することができずリカバリが失敗していました。

§ § § §

これらのバグにより 統計データの損失、アサート失敗、または「ERROR: can only drop stats once」というエラーが発生する可能性がありました。

§ § §

以前までは実装の見落としによりカウントがされていませんでした。

§ § § § §

テーブルにデフォルト以外の演算子クラスオプションを持つインデックスがある場合、ALTER TABLE の一部の処理が失敗していました。

§ § § § §

このバグは、 configure 実行時に --enable-cassert オプションを利用してアサーション検査を有効にしたビルドでのみ影響があります。

§ § § §