
このリリースは 13.18 からの修正リリース(2025年 2月 13日リリース)です。
13.X からのアップデートではダンプ、リストアは不要です。
ただし、13.17 よりも前のバージョンからアップデートする場合には、13.17のリリース情報も参照してください。
PostgreSQL 13.18 から 13.19 への変更点
17.3, 16.7, 15.11, 14.16, 13.19 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。
- PQescapeString などの関数が無効なエンコーディングの入力文字列に対して頑強になりました。(CVE-2025-1094) (Andres Freund, Noah Misch) (17)(16)(15)(14)(13)
- 接続要求でのデータベース名とユーザ名の自動切り捨てが元に戻されました。 (Nathan Bossart) (17)
- 接続権限と接続数上限の検査からパラレルワーカーが除外されました。 (Tom Lane) (17)(16)(15)(14)(13)
- 待機イベント型が「LWLock」の待機イベント名から、接尾辞「Lock」が取り除かれました。 (Bertrand Drouvot) (17)
- ScalarArrayOp の条件(「IN (...)」や「= ANY」)で Btree インデックスをスキャンして一致する全タプルを返すときに、誤った問い合わせ結果が生じる可能性があり、修正されました。 (Peter Geoghegan) (17)
- ウィンドウ集約で古い結果を再利用してしまう可能性があり、修正されました。 (David Rowley) (17)(16)(15)
- TransactionXmin と MyProc->xmin の同期が維持されるようになりました。 (Heikki Linnakangas) (17)(16)(15)(14)(13)
- カタログキャッシュリストに新たに挿入されたカタログエントリを追加することに失敗するかもしれない競合状態が修正されました。 (Heikki Linnakangas) (17)(16)(15)(14)(13)
- システムカタログが UPDATE と並行して VACUUM されたときにデータ破損する可能性があり、防止されました。 (Noah Misch) (17)(16)(15)(14)(13)
- リレーション切り詰めに失敗したときのデータ破損が修正されました。 (Thomas Munro) (17)(16)(15)(14)(13)
- リレーション切り詰め中のチェックポイント開始を防止するようになりました。 (Robert Haas) (17)(16)(15)(14)(13)
- データベース所有者を変更する REASSIGN OWNED と VACUUM が同時実行するときに pg_database.datfrozenxid の更新が失われる可能性があり、修正されました。 (Kirill Reshke) (17)(16)(15)(14)(13)
- AFTER UPDATE のトリガに誤った tg_updatedcols 値が渡されており、修正されました。 (Tom Lane) (17)(16)(15)(14)(13)
- パーティションテーブルを参照する外部キー制約を持つパーティションのデタッチが修正されました。 (Amul Sul) (17)(16)(15)
- pg_get_constraintdef のドメインに対する NOT NULL制約の対応が修正されました。 (Alvaro Herrera) (17)
- to_timestamp 関数の「FFn」書式コードの誤った処理が修正されました。 (Tom Lane) (17)(16)(15)(14)(13)
- SQL/JSON問い合わせ関数で PASSING 句を逆パースするときに、必要なとき確実に変数名がダブルクォートされるようになりました。 (Dean Rasheed) (17)
- XMLTABLE() 関数の式の逆パースで、XML ネームスペース名が必要なとき確実にダブルクォートされるようになりました。 (Dean Rasheed) (17)(16)(15)(14)(13)
- pg_hba_file_rules() 関数の出力に、これまで欠落していた ldapscheme オプションを含めるようになりました。 (Laurenz Albe) (17)(16)(15)(14)(13)
- 入力列のデータ型が全ては一致しない場合における、ソート済 UNION 操作のプラン作成が修正されました。 (David Rowley) (17)
- 列の照合順序が一貫していない場合は、UNION 操作を併合しないように修正されました。 (Tom Lane) (17)(16)(15)(14)(13)
- 外部結合の下にあるサブクエリをプルアップした後に生じるプランナのエラー「ERROR: wrong varnullingrels ...」を防止するようになりました。 (Tom Lane) (17)(16)
- プランナが統計情報を調べるときに、NULL になるリレーションのマーカービット(nullingrels)を無視するように修正されました。 (Richard Guo) (17)(16)
- パーティションプルーニングで式を書き換えする処理が欠落しており、修正されました。 (Tom Lane) (17)(16)(15)(14)(13)
- slotsync ワーカープロセスに独自のプロセススロットを割り当てるようになりました。 (Tom Lane, Hou Zhijie) (17)
- dshash テーブルの 1GB を超える割り当てが許可されるようになりました。 (Matthias van de Meent) (17)(16)(15)(14)(13)
- bringetbitmap() で整数オーバーフローが発生する可能性があり、回避するようになりました。 (James Hunter, Evgeniy Gorbanyov) (17)(16)(15)(14)(13)
- SLRU のバンク数の計算誤りが修正されました。 (Yura Sokolov) (17)
- すでに設定されているプロセスのラッチによって、親プロセス(postmaster)によるソケットイベントの認識が妨げられないように、修正されました。 (Thomas Munro) (17)(16)
- ページをまたぐ WAL レコードの読み取り時に、ストリーミングスタンバイサーバが無限ループするのを防ぐようになりました。 (Kyotaro Horiguchi, Alexander Kukushkin) (17)(16)(15)(14)(13)
- プロセスの起動初期に意図せず FATAL エラーが PANIC に昇格する問題が修正されました。 (Noah Misch) (17)(16)(15)(14)(13)
- 演算子族メンバーの演算子、またはサポートプロシージャが不正参照となる可能性があり、修正されました。 (Tom Lane) (17)(16)(15)(14)(13)
- ロジカルデコーディング出力における複数のメモリリークが修正されました。 (Vignesh C, Masahiko Sawada, Boyu Yang) (17)(16)(15)(14)(13)
- application_name または cluster_name 設定を更新するときに発生する小さなメモリリークが修正されました。 (Tofig Aliev) (17)(16)
- バックグラウンドプロセスが synchronized_standby_slots の新しい値を検査しようとした時に発生するクラッシュが回避されました。 (Alvaro Herrera) (17)
- wal_skip_threshold 条件を検査するときの整数オーバーフローが回避されるようになりました。 (Tom Lane) (17)(16)(15)(14)(13)
- キャッシュ検索中の安全でない操作順序が修正されました。 (Noah Misch) (17)(16)(15)(14)(13)
- 並列バキュームで解放後メモリアクセスの可能性が回避されました。 (Vallimaharajan G, John Naylor) (17)
- 古い ARM プラットフォームで JIT を使用するときに「ERROR: failed to resolve name」エラーが発生する可能があり、修正されました。 (Thomas Munro) (17)(16)(15)(14)(13)
- 「WITH RECURSIVE ... UNION」の問い合わせでのアサート失敗が修正されました。 (David Rowley) (17)(16)(15)(14)(13)
- 集合操作のリーフクエリに集合操作が含まれている場合に、ルールの逆解析でアサーションエラーが発生しなくなりました。 (Man Zeng, Tom Lane) (17)(16)(15)(14)(13)
- 並列クエリ起動時に発生するエッジケースのアサーション失敗が回避されました。 (Tom Lane) (17)(16)(15)(14)(13)
- シャットダウン時に統計ファイルを書き出す際のアサーション失敗が修正されました。 (Michael Paquier) (17)(16)(15)
- 文字列ハッシュコードに関する Valgrind エラーが回避されました。 (John Naylor) (17)
- NULLIF() では、読み書き拡張オブジェクトポインタをデータ型の等価関数に渡さないようになりました。 (Tom Lane) (17)(16)(15)(14)(13)
- INSERT のデフォルトの NULL 値に式の前処理が確実に適用されるようになりました。 (Tom Lane) (17)(16)(15)(14)
- すでにデータが含まれているリレーションフォークで一括書き込みを開始したときのデータ損失が回避されました。 (Matthias van de Meent) (17)
- サーバプロセスが作成していない共有基数木を反復処理しようとした場合のクラッシュが回避されました。 (Masahiko Sawada) (17)
- PL/Python のメモリリークが修復されました。 (Mat Arye, Tom Lane) (17)(16)(15)(14)(13)
- PL/Tcl が Tcl 9 でコンパイルできるように修正されました。 (Peter Eisentraut) (17)(16)(15)(14)(13)
- ecpg プリプロセッサで、スコープ外の変数を参照するカーソルを誤って処理する可能性が修正されました。 (Tom Lane) (17)(16)(15)(14)(13)
- ecpg で、サポートされていない COPY ... FROM STDIN の使用に関するコンパイル時の警告が修正されました。 (Ryo Kanbayashi) (17)(16)(15)(14)(13)
- SJIS でエンコードされたファイルパス名を安全に扱えるように psql が修正されました。 (Tom Lane) (17)(16)(15)(14)(13)
- COPY (MERGE INTO) のための psql タブ補完機能が追加されました。 (Jian He) (17)
- pgbench および psql での pqsignal() の間違ったバージョンの使用が修正されました。 (Fujii Masao, Tom Lane) (17)(16)(15)(14)(13)
- pgbench 内の一部のネストされた \if 構造の誤った実行が修正されました。 (Michail Nikolaev) (17)(16)(15)(14)(13)
- pgbench でテーブルの初期化中に進行状況メッセージが誤って表示される可能性がある問題が修正されました。 (Yushi Ogiwara, Tatsuo Ishii, Fujii Masao) (17)(16)(15)(14)(13)
- pg_controlldata が破損した pg_control ファイルに対してより堅牢になりました。 (Ilyasov Ian, Anton Voloshin) (17)(16)(15)(14)(13)
- 拡張のメンバであるテーブルに ID シーケンスで添付されている場合にpg_dump で発生する可能性があるクラッシュが修正されました。 (Tom Lane) (17)(16)(15)(14)(13)
- zstd で圧縮されたデータを使用した際の pg_restore メモリリークが修正されました。 (Tom Lane) (17)(16)
- Windows で pg_basebackup が 2GB を超える pg_wal.tar ファイルを扱えるようになりました。 (Davinder Singh, Thomas Munro) (17)(16)(15)(14)(13)
- contrib/earthdistance の SQL 関数宣言がSQL標準形式に変更されました。 (Tom Lane, Ronan Dunklau) (17)(16)
- contrib/pageinspect で SQL 宣言と共有ライブラリ間のバージョン不一致を検出するようになりました。 (Tomas Vondra) (17)
- contrib/postgres_fdw でリモートクエリキャンセル時に反応がない場合に数回再リクエストするになりました。 (Tom Lane) (17)
- ARM で CRC 命令を使用するようにコンパイラ設定が更新されました。 (Tom Lane) (17)(16)(15)(14)(13)
- Windows で meson ビルド時に古い OpenSSL ライブラリをサポートするようになりました。 (Darek Slusarczyk) (17)(16)
- Windows で meson ビルド時に全 libcommon および libpgport 関数のエクスポートを確認するようになりました。 (Vladlen Popolitov, Heikki Linnakangas) (17)(16)
- meson ビルド時に MSVC で OSSP の uuid.h ヘッダファイルが検出できるようになりました。 (Andrew Dunstan) (17)(16)
- meson ビルド時の pgevent インストール先が bindir から pkglibdir に変更されました。 (Peter Eisentraut) (17)(16)
- meson ビルド時の sepgsql.sql インストール先が share/extension/ から share/contrib/ に変更されました。 (Peter Eisentraut) (17)(16)
- パラグアイの DST 法変更とフィリピンの歴史的修正のため、 (Tom Lane) (17)(16)(15)(14)(13)
- ファイル名変更時に link()/unlink() ではなく、 rename() を使用するようになりました。 (Nathan Bossart) (15)(14)(13)
- malloc() 失敗時の戻り値チェック漏れのため、メモリ不足時にまれに発生するクラッシュが修正されました。 (Karina Litskevich) (15)(14)(13)
- Windows でジャンクションポイントの扱いを修正しました。 (Thomas Munro) (15)(14)(13)
- configure 中に C23 規格のコンパイラが検出されても、 C17 を使用するようになりました。 (Thomas Munro) (15)(14)(13)
- archive_status ディレクトリ内に状態ファイルが大量に存在する状況で、archiver プロセスのパフォーマンスが改善されました。 (Nathan Bossart) (14)
- リレーション切り捨て中にまれに発生するアサート失敗が修正されました。 (Heikki Linnakangas) (13)
クライアントライブラリ 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 '' 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)) 10
この障害は、誤ったソート演算子によるデータのソートを引き起こし、その結果はクラッシュから目に見える問題が無い場合まで様々です。
(報告されたクラッシュする例) 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 で行われた修正がバックパッチされたものとなります。