PostgreSQL 14.20 – SRA OSS Tech Blog

PostgreSQL 14.21 に関する技術情報

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

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

PostgreSQL 14.20 から 14.21 への変更点

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 14.20 に関する技術情報

データベース技術グループ — Mon, 15 Dec 2025 03:01:22 +0000

このリリースは 14.20 からの修正リリース（2025年 11月 13日リリース）です。
14.X からのアップデートではダンプ、リストアは不要です。

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

PostgreSQL 14.19 から 14.20 への変更点

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 のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。