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

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

§ § § § §

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

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

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

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

§

これらの関数は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）でこれを行なってください。

§

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

§ § §

バージョン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.

§

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

§ § § § §

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

§ § § § §

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

§ § § § §

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

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

§ § § § §

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

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

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

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

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

§ § § § §

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

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

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

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

§ §

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

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

§ §

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

§

本修正で、外側の集約では入れ子の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;

§ § § § §

文単位の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は行ロックや可視性制御のための内部的に使われるメタデータです。

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

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

§

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

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

§ § § § §

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

（障害を起こす問合せ例 - いずれも 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.

§

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

（誤動作例： '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)

§

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

§ § §

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)

§

プランナが、このようなグループ化された列を参照する外部クエリの制約をプッシュダウンしようとしたため、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)

§

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

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

§

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

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

§

コードが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句を削除します。なぜなら、すべてのインデックスエントリに対して必ず成立するため、テストする意味がないからです。しかし、ハッシュインデックスのように先頭インデックスキーに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 の実行プランになってしまう

§ § § § §

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

§ § § § §

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

§

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

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

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

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

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

§ § § § §

以前は、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の出力でスキップされた(skipped)タプルの数が誤っていたり、アサートが有効なビルドではアサート失敗が発生していました。

§ §

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

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

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

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

§ § § § §

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

§ §

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

§ § § § §

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

§

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

§ § § § §

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

§ § § § §

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

§ § § § §

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

§ § § § §

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

§ § § § § § § § § §

以前は、自動更新可能ビューやルール付きのリレーションを更新するときに、元の問合せにデータ変更を伴う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）のエントリの初期化途中で失敗したとしても、次にそのエントリの使用を試みる際に初期化を再度試行できるようになりました。これまで一度初期化が失敗したエントリは、失敗した状態のままで残り続けていました。

§ §

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

§

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

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

§

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

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

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

§ § § § §

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

§ § § § §

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

§ § § §

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

§ § § § § § § § §

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

§ § § § §

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

§ § § § §

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

§ § §

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

§ §

§ § § § §

これまでは、型が正しくない場合に本来出すべきエラーの代わりに、「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

§ §

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

（誤動作例: 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"

§ § § § §

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

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

§ § § § §

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

§ § § § §

§ §

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

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

§

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

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

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

§ § §

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

§ § § § § § § § §

§ § §

§ § § § §

§

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

§

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

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

§ §

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

§

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

§ §

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

§ §

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

§ § § § §

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

§ § § §

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

§ § § § § § §

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

§ § § § §

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

§ § § § §

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

§

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

§ § § § §

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

§ § § § §

§

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

§ § § § §

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

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