fsync()は OS にバッファをストレージに確実に書き出しさせる命令です。PostgreSQL は PANIC になるとサービス全体が停止します。

いくつかの人気の OS はカーネルデータバッファを書き出しできないときに、そのバッファを廃棄し、fsync() に失敗したものとして報告します。ここで PostgreSQL が fsync()要求を再発行して成功したとしても、実際にはデータは既に失われているので、データベース破損の危険性が残ります。代わりに PANIC状態にすることで、次に WALからのリカバリができます。WAL にはおそらく、ここにしか残っていないデータのコピーが含まれているでしょう。この振る舞いは確かに見苦しく非効率的ですが、あまり代替策がなく、また、幸いにもこのようなことは大変稀にしか起きません。

本動作の制御のため、新たな設定パラメータ data_sync_retry が追加されました。PostgreSQL を動作させるプラットフォームのカーネルがこのようなときにダーティデータバッファを廃棄しないと確信できるなら、これを on に設定して、従来通りの振る舞いにすることができます。

※本ページでは引き続き、各バージョン系列を統合した形でリリース情報を掲載します。

このような場合にユニーク条件が適切に検査されませんでした。

以下のように実行したときにパーティション（子テーブル）に NOT NULL 制約が付与されない動作がありました。

db=# CREATE TABLE t4 (a int DEFAULT 1, b int NOT NULL DEFAULT 0)
       PARTITION BY LIST (a);
db=# CREATE TABLE t4c1 PARTITION OF t4 (a NOT NULL, b DEFAULT 1)
       FOR VALUES IN (1);
db=# INSERT INTO t4 (b) VALUES (NULL);
（修正前はここで violates not-null constraint のエラーが出ない）

これまでは、パーティションテーブルの制約に対するpg_constraint.conislocalフィールドが、不適切に 'f'（false）のままになって、制約が除去（DROP）不能になることがありました。

本マイナーバージョンでは既におかしくなっているフィールドの値自体は補正されません。ダンプ/リストアや pg_upgrade でこの問題を解消できます。また、必要であれば、このカタログのフィールドを手動で補正することができます。デタッチ済みのパーティションに対する制約の本フィールドの値は 't'（true）です。

（フィールド値を確認する SQL の例）
db=# SELECT conname, conislocal FROM pg_constraint;
           conname            | conislocal
------------------------------+------------
 cardinal_number_domain_check | t
 yes_or_no_check              | t
 t1_pkey                      | t
     （後略）

パーティションをデタッチした後に外部キー制約が正しく動作しないケースや、外部キー制約の除去（DROP）が出来なくなるケースが報告されました。

これまで、各パーティションに対する外部キー制約とパーティションテーブル全体に対する外部キー制約が同じであった場合、そのようなパーティションには重複して制約が付加されていました。

これからは、このような場合でも一つの外部キー制約だけ作られるようになります。

このような場合に INVALID になっていましたが、その後で INVALID を解除する（有効にする）手段がありませんでした。

（これまで以下のように実行したとき、t8_id_idx が INVALID になっていました）
db=# CREATE TABLE t8 (id int, v text) PARTITION BY RANGE (id);
db=# CREATE UNIQUE INDEX t8_id_idx ON ONLY t8 (id);

（上記の t8_id_idx は後に以下のようにすれば、無意味な使用法ではありません）
db=# CREATE TABLE t8_1 PARTITION OF t8 FOR VALUES FROM (0) TO (1000) ;
db=# CREATE UNIQUE INDEX t8_1_id_idx ON ONLY t8_1 (id);
db=# ALTER INDEX t8_id_idx ATTACH PARTITION t8_1_id_idx;

これまでのロックレベルは弱すぎで、同時のテーブルに対する DDL実行が可能で、悪い結果をもたらすかもしれませんでした。

具体的には、パーティションに対するロックで、ACCESS SHARE であったロックレベルが SHARE UPDATE EXCLUSIVE に変更されました。また、特に 11.x 以降バージョンにおいて、インデックスに対するロックの保持期間がトランザクション終了までに延ばされました。

トランザクションのコミット時に以下のエラーが発生するケースが報告されました。

ERROR: XX000: could not open relation with OID 16420

このような COPY は意図せぬエラーが発生し、エラーが生じない場合も正しく動作していませんでした。これからは以下のエラーが出るようになります。

ERROR:  cannot perform FREEZE on a partitioned table

高速デフォルトとは、既にデータが格納されているテーブルに対してNULL 以外のデフォルト値を指定した ALTER TABLE ... ADD COLUMN により追加した列であることを指します。バージョン11 からこのような場合にも ALTER TABLE が高速に実行されるようになりました。

「高速デフォルト」については前項を参照してください。

この修正はバージョン10 で導入された性能改善を部分的に元に戻します。それは GIN のポスティングツリーのページを削除するときに、ロックされるインデックスページ数を減らそうとするものでした。

なお、ここでのデッドロックは、デッドロック自動検出で ERROR を生じさせるものではなく、ハングアップを生じさせるものです。

修正前バージョン同士のレプリケーションでクラッシュが起きるのは、通常はパブリッシャ側です。

潜在的に同期レプリケーションによる保証を毀損するおそれがありました。また、9.4.xバージョンではアサート失敗を起こす可能性もありました。

ここでのWAL出力省略による最適化とは以下のようなケースです。このときトランザクション内で作成するのがビューや外部テーブルであるなら、本来 WAL出力の省略はできません。

BEGIN;
CREATE TABLE t21 (id int, v text);
COPY t21 FROM STDIN CSV;
1,aaaaa
2,bbbbb
.
COMMIT;

これによりタイムライン変更の追随をより早期に行えるようになります。

なお、明らかにクラッシュが生じるのはバージョン 9.6.x と 10.x のみです。以下のような SQL でクラッシュする例が報告されました。

db=# CREATE TABLE t23_1 (a VARCHAR(1));
db=# CREATE TABLE t23_2 (b VARCHAR(1));
db=# INSERT INTO t23_1 VALUES ('A');
db=# INSERT INTO t23_2 VALUES ('A');
db=# UPDATE t23_1 SET (a) = (SELECT b FROM t23_2 WHERE t23_2.b = t23_1.a)
       WHERE 'X' NOT IN ('Y', 'Z');

（クラッシュをひき起こす実行例）
db=# CREATE TYPE typ24 AS (id int);
db=# SELECT * FROM json_populate_recordset(NULL::typ24,'[]');

SQL実行時のバックエンドプロセスのクラッシュが報告されました。

一部のケースでは、照合順序が適用されるデータ型での処理があるときに、マッチすべき式がマッチしませんでした。すなわち、誤った問い合わせ結果が返る可能性があります。

CASE式とグループ化（GROUP BY）を使った問い合わせで障害が報告されました。

例えば以下のような CALL文は 'a' と 'b' が当該ロケールでどちらが先になるかということの影響を受けます。修正前はこのような場合にロケールに基づく照合順序が反映されませんでした。

db=# CALL proc29(least('a', 'b'), 'c');

引数に関するエラーが出る CALL文を繰り返し実行したときに、2回目以降に不適切なエラーメッセージが出る動作が報告されました。

これまで検査していませんでした。実際の Btree 比較関数からの情報漏れを起こすのは一般に困難ですが、原理的には起こりえます。

誤った問い合わせ結果が返る動作が報告されました。

両階層の入れ子ループが同じ変数を各々のプランナツリー構造上の右手側に渡す必要がある場合、誤ったプランが生成されると考えられます。

LATERAL句による副問い合わせを伴う外部テーブルに対する SELECT文で以下のようなエラーが出るケースが報告されました。

ERROR:  attribute number 2 exceeds number of columns 1

以下のようなエラーが発生します。

db=# CREATE TABLE t34 (c1 int, c2 int, c3 int, c4 int,
       CONSTRAINT covering PRIMARY KEY (c1, c2) INCLUDE (c3, c4));
db=# SELECT * FROM t34 WHERE (c1, c2, c3) < (1, 2, 3);
ERROR:  operator 97 is not a member of opfamily 8

外側のキー範囲が内側のキー範囲よりもとても小さいときに、たとえ内側に重複キーが大量にあって不適切な選択であるとしても、プランナがマージ結合を好んでいた可能性があります。

1000パーティションのパーティションテーブルで 11.1バージョンのプラン作成時間が10.x や 11.0 と比べて 1000倍以上になる動作が報告されました。

これまで、実行中のトランザクションで削除された行を ANALYZE の統計情報採取では無視していましたが、これを含めるのと比べてより大きな不整合をもたらすことがわかりました。これからは事実上、ANALYZE開始時の MVCCスナップショットに一致するようになりました。

これは TRUNCATE を他のコマンドの振る舞いに合わせます。これまでは、このような場合にたいていエラーになっていました。

以下の動作が発生します。

db=# CREATE TABLE t39 (id int);

    （別セッションで）
    db=# CREATE TEMP TABLE t39c (LIKE t39) INHERITS (t39);

db=# TRUNCATE t39;
ERROR:  cannot truncate temporary tables of other sessions

TRUNCATEするテーブルが TOASTテーブルを持っている場合、TOASTテーブルのカウンタが代わりにリセットされていました。

「ONLY」を付けると「IF NOT EXISTS」指定が効きませんでした。

db=# CREATE TABLE t41 (c1 int);
db=# ALTER TABLE ONLY t41 ADD COLUMN IF NOT EXISTS c1 int;
ERROR:  column "c1" of relation "t41" already exists
（IF NOT EXISTS 指定が効かない）

db=# ALTER TABLE t41 ADD COLUMN IF NOT EXISTS c1 int;
NOTICE:  column "c1" of relation "t41" already exists, skipping
ALTER TABLE
（ONLY が無ければ機能する）

ホットスタンバイで LISTEN はできないので、これは必然的に何もしません。しかしながらダミー操作を可能にすることで、クライアントでのセッション状態のリセットを簡単にします。

一部の場合に許可を与えられたロールを落としてしまうことがあり得ました。これが直ちに問題をひき起こすことはありませんが、後のダンプ/リストアや pg_upgrade実行で失敗します。症状としては、全てが数字のロール名に権限を付与しようとします。

以下は pg_upgrade の中で pg_restore を実行したときのエラー発生例です。

pg_restore: [archiver (db)] could not execute query: ERROR: role "33757" does not exist
Command was: GRANT ALL ON SCHEMA "regress_rls_schema" TO "33757";

二相トランザクション内で一時テーブルにアクセスすることは、長らく禁止されていましたが、一時オブジェクトに対する他の操作で問題が起きる可能性がまだありました。

この見落としにより、既存セッションにおいて新たに作られた制約が効かなかったり、削除された制約が継続して効いていたりする可能性がありました。

ALTER TABLE ... RENAME CONSTRAINT ... TO ... を実行した後に、続いてそのテーブルに関連する DDL を実行したときに、変更する前の名前の制約が存在しないという以下のようなエラーが出る動作が報告されました。

ERROR:  constraint "const_aaa" for table "t46" does not exist

本障害によりハングアップが生じるケースが報告されました。

最大の有効な整数値を僅かに上回る値は拒絶されないおそれがありました。それで、オーバーフローして、替わりに最小の有効な整数が生じました。また、最小あるいは最大の整数値に丸めるべき値が誤って拒絶されるかもしれませんでした。

（障害動作例）
db=# SELECT '32767.4'::float8::int2;
ERROR:  smallint out of range
　→ 32767 となるべき

db=# SELECT '9223372036854775807'::float8::int8;
         int8
----------------------
 -9223372036854775808
(1 row)
　→ 「ERROR:  bigint out of range」を出すべき

以下のエラーになって、複数ホストの指定が動作しないことが報告されました。

LOG:  could not initialize LDAP: Bad parameter to an ldap routine

これまでは、この変数に「[local]」を設定していましたが、これはホスト名であるはずなので全く役に立ちませんでした。「[local]」の文字列で DNS検索が発生して認証によけいな遅延が生じました。

これまでは FATAL や PANIC を設定して、通常のエラーメッセージをクライアントに送らないようにすることができました。しかしながら、これは PostgreSQLプロトコル仕様で提示される保証事項に反し、一部のクライアントを大変に混乱させます。

リリース済みのバージョン系列においては、FATAL、PANIC の設定は ERROR と解釈されます。バージョン 12.x 以降においては、これら設定は拒絶されます。

setlocale() がスレッドローカルでなく、おそらくスレッドセーフでもないため、以前のコードはマルチスレッド化された ecpgアプリケーションで問題を起こしました。

ゼロから始まる値が正しくコピーされませんでした。

これまでは g は COPYコマンドを実行できましたが、g の書き出し先オプションは何であれ無視されていて、データはいつでも通常の問い合わせの出力先に出されていました。

バックスラッシュやその他の ASCII記号文字が正しく処理されず、ドキュメントの構文エラーや誤った文字の出力をもたらしていました。

プラットフォームによっては標準ライブラリの srandom()/random() が非決定的な乱数を返すことがあるため、PostgreSQL自身で実装した乱数生成関数を用いるようになりました。

本障害はこのようなビューに対して紛らわしいダンプアーカイブエントリをもたらし、アーカイブ項目が正しいセクション順序に無いという無害な警告をひき起こしました。「--section」など、このラベルに依存している選択的なリストアのオプションでは、無害でもなくて、誤動作するかもしれません。

以下の WARNING が発生します。

pg_dump: [archiver] WARNING: archive items not in correct section order

インデックス式に統計情報ターゲット数を付与できるようになったときに、pg_dump についても対応すべきところ、取りこぼされていて、ダンプ/リストアで設定が失われていました。

最初のテーブルに対して、必要な場合でも WITH OIDS句が取りこぼされていました。

このケースは実際のところ直接の COPY では到達可能でありませんが、contrib/file_fdw を使うときには発生する可能性があります。

これまでの実装では新たなバージョンで作られた空の hstore値に対して同じ結果を返しませんでした。そのため、ハッシュ結合やハッシュ集約で誤った結果がもたらされる可能性がありました。テーブルに8.4以前に当初格納されたデータが含まれていて、これまでダンプ/リストアをしていない場合、hstore型の列に対するハッシュインデックスを全て再作成することが推奨されます。

intarray拡張を使って整数配列にインデックスを作って、データを投入するとき、クラッシュする動作が報告されました。また、巨大なメモリ確保を試みて「ERROR: invalid memory alloc request size ...」になるケースもあります。

バージョン番号付きの python実行ファイルが無いプラットフォームで、明示的に PYTHON 変数を指定することなく PL/Python が設定できるようになります。

既存のユースケースには影響を与えないと考えられます。

カザフスタン、メトラカットラ、サントメ・プリンシペの夏時間法の変更、香港と多数の太平洋諸島での歴史的修正が含まれます。

また、カザフスタンの Qyzylordaゾーンは 2つに分かれ、新ゾーン Asia/Qostanay が作られました。一部の地域は UTCオフセットを変更しません。

これにより、クラッシュしたセッションの残骸がより速やかに片付けられます。

これにより PL/Ruby を壊す Ruby 関数との名前衝突を避けます。影響を受ける他の拡張は無いと思われます。PostgreSQL 11.1 で修正されていましたが、10.x 系列にも適用されました。

9.4および9.5バージョン系列で以前に使われたコードは、一部の新しいプラットフォームでは完全に失敗するため、9.6以降で使われるものに一致されました。

この見逃しは、ダンプのリストアや pg_upgrade実行で権限の無いユーザがスーパーユーザ権限を得るようにする攻撃を可能にしていました。(CVE-2018-16850)

これまでは、子インデックスは常にデフォルトテーブルスペースに作られていました。

ハッシュキーに NULL値を伴う外側リレーションの行が、結合結果から抜け落ちていました。本障害のため enable_parallel_hash = on のときに、誤った問い合わせ結果が返る可能性がありました。

以下のような奇妙な動作が発生していました。

（enum_range関数は配列 '{e,f,g}' を返すので '{a,b,c,d,e,f,g}' が正しい結果）
db=# CREATE TYPE typ_efg AS ENUM ('e', 'f', 'g');
db=# SELECT
       CASE 'foo'::text WHEN 'foo'
         THEN ARRAY['a', 'b', 'c', 'd'] || enum_range(NULL::typ_efg)::text[]
         ELSE ARRAY['x', 'y']
       END;
         array
-----------------------
 {a,b,c,d,foo,foo,foo}
(1 row)

本障害により、最近に追加された列をもつテーブルの制約トリガ動作でクラッシュをひき起こすことが知られています。また、その他の症状を示す可能性もあります。

（知られている障害発生パターン）
db=# CREATE TABLE leader (a int PRIMARY KEY, b int);
db=# CREATE TABLE follower (a int REFERENCES leader ON DELETE CASCADE, b int);
db=# INSERT INTO leader VALUES (1, 1), (2, 2);
db=# ALTER TABLE leader ADD c int;
db=# ALTER TABLE leader DROP c;
db=# DELETE FROM leader;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

CALLでそのような引数をもつプロシージャを実行するときに、エラーが発生する動作が報告されていました。

STRICTな集約とは NULLを処理対象から除外する動作をするものです。ORDER BY を付与したときこの動作が働きませんでした。

（1 が返るのが正しいが、NULLが返っていた）
 db=# SELECT min(x ORDER BY y) FROM (VALUES(1, NULL)) AS d(x,y);
  min
 -----
 
 (1 row)

これはバージョン11から登場した最適化機能ですが、クラッシュをひき起こすとがあり、ひとまず無効化されました。

クラッシュをひき起こすことがありました。理想的にはこのような使い方も可能とすべきですが当面は禁止とされました。トリガ駆動時に以下のようなエラーが出るようになります。

ERROR:  cannot ALTER TABLE "..." because it is being used by active queries in this session

ERROR:  cannot CREATE TABLE .. PARTITION OF "..." because it is being used by active queries in this session

このような一次パーティションテーブルを作るときに以下のようなエラーが発生していました。

db1=# CREATE TEMP TABLE t10 (id int, v text)
        PARTITION BY RANGE (id) ON COMMIT DELETE ROWS;
ERROR:  could not open file "base/16543/t3_45678": No such file or directory

この障害はテキスト検索、contrib/ltree、contrib/pg_trgm に影響があります。絵文字に対して pg_trgm の関数を実行して以下エラーが出る例が報告されました。

ERROR: invalid multibyte character for locale

以前はより早くに処理されていたのが、9.6.3、9.5.7 のリリースから本修正前まででは、後回しに処理されるようになっていました。

SP-GiST を使った排他制約が一つのコマンドで多数の新たなインデックスエントリを受け付ける場合に、大きなリーク量が生じることが知られています。

これは psql が NOTIFYメッセージ受信を次コマンドまで報告しないケースを修正します。

一部ケースでチェックサムを持つと想定されないファイルについて、問題報告されることがありました。

pg_read_all_stats は全ての統計情報が参照できるという意味であるため、データを変更できることは不適切でした。変更の反映には導入先の各データベースで以下コマンド実行が必要です。

ALTER EXTENSION pg_stat_statements UPDATE;

Ruby の関数との名前衝突を回避します。PL/Ruby を導入する場合に問題がありました。

PL/Perl と PL/Tcl のビルドに失敗していました。対応として、configureスクリプトが CPPFLAGS に -isysroot を加えるようになりました。そのほか、macOS むけにビルドスクリプトがいくつか修正されました。

Perlは最早カレントディレクトリをデフォルトではサーチパスに含めず、本修正はこれに対応したものです。

Administratorアカウントから駆動したとしても安全であるように、実行プロセスは制約された権限で動作するようになっています。

チリ、フィジー、モロッコ、ロシア（ヴォルゴグラード）の夏時間法の変更と、中国、ハワイ、日本、マカオ、北朝鮮の歴史的修正が含まれています。

これら関数はオブジェクトの不正な OID与えられたときエラーではなく NULLを返すことが期待されていますが、一部においてそうなっていませんでした。さらに、has_column_privilege() 関数は一部プラットフォームでクラッシュする可能性がありました。

この障害によりパースエラーや不正な優先順位が生じる可能性がありました。演算子の後に数値の + や -、あるいはコメント開始記号の -- や /* が続いている場合に誤認されるケースがありました。

（報告された障害動作例）
db=# CREATE FUNCTION f26(a int) RETURNS int LANGUAGE sql
        AS $$ SELECT a; $$;
db=# SELECT f26(a => -1);
 f
----
 -1
(1 row)

db1=# select f(a =>-1);
ERROR:  column "a" does not exist

カーソルを使って FETCH BACKWARD で結果を取得する場合に誤った SELECT結果が返る動作が報告されていました。実行プランとして逆向きスキャンが選ばれる場合にも問題が起きる可能性があります。

複数のリレーション（特に親テーブルを継承した複数のテーブルなど）をスキャンするカーソルは、手前のリレーションに巻き戻された場合に誤動作を起こす可能性がありました。

同時更新をしたときに、なかなか再現しないクラッシュや誤った問い合わせ結果が生じていました。CASE や COALESCE の中にある無関係な副SELECT を含む更新SQL（例えば以下のような形状）で該当します。

WITH d(val) AS (SELECT 'Val'::text FROM generate_series(1,1))
  UPDATE t30 SET v = COALESCE(v, (SELECT val FROM d)) WHERE id = 1;

このような場合、行順序の変化により不確定な結果となって、ワーカごとに異なる応答を得ることから、整合性に欠けた振る舞いが生じることがありました。

所有者変更はこのようなシーケンスにも伝播すべきでしたが、外部テーブルについて見逃されていました。

特に多次元配列のときに確保サイズが大きくなっていました。

これまでファイル記述子のリークがあり、結果としてロジカルデコーディングでのエラーをひき起こしていました。

（エラー例）
ERROR:  53000: exceeded maxAllocatedDescs (492) while trying to open file "pg_logical/mappings/map-4000-4eb-1_60DE1E08-5376b5-537c6b"
LOCATION:  OpenTransientFile, fd.c:2161

VACUUM FULL や CLUSTER コマンドで以下のようなエラーが生じる可能性がありました。

ERROR, "could not map filenode "base/16543/19876" to relation OID"

これまでスタンバイで以下のエラーが出ることがありました。

FATAL:  out-of-order XID insertion in KnownAssignedXids

本障害について、イベントトリガが働く状態で入れ子のパーティションテーブルを作成するときのクラッシュが報告されました。

これにより、transaction_timestamp() などの関数がワーカ上で実行されたときの誤動作が防止されます。

配列型の値などが該当します。SQL実行時に Bus error によるクラッシュが発生していました。

archive_mode の設定によってはスタンバイで一部の本来削除可能なWALファイルの削除に失敗することがありました。

コミットタイムスタンプ追跡が有効または無効に変更されると、それを記録していないトランザクションに対してコミットタイムスタンプを取得しようとしてリカバリに失敗することがありました。

（本障害でリカバリ起動に失敗した報告例）
FATAL: could not access status of transaction 3003911820
DETAIL: Could not read from file "pg_commit_ts/6FEE" at offset 557056: Success.

この変更により、常に同じランダムシードを使うことで生じる名前衝突によって、initdb が POSIX共有メモリが無効であると誤って判断するのを回避できます。

主として問い合わせの並列処理で問題が不具合が発生します。

SQLのパラレル処理とキャンセルで無限ループが生じる可能性がありました。

本障害により以下のエラーが発生するケースが報告されました。

ERROR:  invalid cache ID: 11
LOG: worker process: parallel worker for PID 12345 (PID 12354) exited with exit code 1

off から on に変えた後もフルページ書き出しが行われない動作が報告されました。

バックエンドのアドレス空間にロードされた共有ライブラリは、関数のリンク先に意図しているそれらが持つコピーではなく、バックエンドにあるバージョンを使う可能性がありました。両関数実装が一致していない場合、この振る舞いのために障害がひき起こされます。

クラッシュが発生する例が報告されています。

本障害によりデータ破壊の可能性があります。

該当する場合、本障害によりデータ破壊をひき起こす可能性があります。

サーバ側（WAL送出側）の遅延をタイムアウト判定に含めないように調整されました。

この修正は、スタンバイサーバが WALリプレイでデータベース整合状態に達した直後の誤動作を防止します。

スタンバイサーバのクラッシュ後の起動で、以下メッセージが出て失敗する動作が報告されました。

PANIC:  WAL contains references to invalid pages
DETAIL:  xlog redo at AB3/50323E78 for Btree/DELETE: 182 items

これまで FSM（空き領域マップ）は重要なデータではないと考えられていましたが、FSM が古くなりすぎるとサーバがスタンバイからプライマリに昇格した後、パフォーマンスが大幅に低下する可能性がありました。

呼び出し側が後で逆向きスキャンを求める場合を考慮する必要がありました。

シグナルを受けてハングアップする可能性がありました。

拡張のスクリプトで CREATE USER MAPPING を実行すると、ユーザのマッピングに対して予期せぬ拡張依存関係が作成されました。ロールは拡張の要素にすることはできないため、ユーザマッピングも含めるべきではありませんでした。

これまではファイルを開けなかった場合にそれを報告しようとして無限再帰ループに陥る可能性がありました。

これにより、リスト内の手前にあるサーバに正常に接続できる場合の不要な障害や接続遅延を防止します。

以前は、次の対象ホストに切り替える際にタイマーがリセットされないことがあり、設定よりも早くタイムアウトとなる可能性がありました。

pg_dump で本オプションが機能していませんでした。

これにより制限された検索パスでリストアを実行する場合の障害を回避します。

以前の pg_upgrade はイベントトリガが拡張に属することを維持できせんでした。

以前は、一部の cube 関連関数が cube_in（cube型の入力関数）で拒否される値を生成する可能性があり、ダンプ/リストアの失敗をひき起こしました。

use_remote_estimate = on の場合に「ORDER BY 0」がリモートで実行されて、「ERROR: ORDER BY position 0 is not in select list」が生じるケースがありました。

これまでは search_path を使用して辞書を探していましたが、search_path が制限的な設定であるとき失敗する可能性がありました。

これまでは、データ型固有の比較関数が INT_MIN を返すことを禁止していました。これにより関数の呼び出し元は、比較結果を否定するだけでソート順を逆転させることができました。しかし、POSIX はそのような制限を設けていないので、memcmp() や strcmp() などの結果を直接返す比較関数では、これは安全ではありませんでした。少なくとも最新のバージョンの memcmp() は INT_MIN を返すことがあり、誤った並べ替え順序が発生します。

この制限は削除されました。ソート順を逆にする場合は、INVERT_COMPARE_RESULT() マクロを使用する必要があります。

この障害で VACUUM FULL によって処理されたばかりのシステムカタログやインデックスへのアクセスに失敗することがあります。以下のエラーが報告されました。FATALが生じることもあります。

ERROR:  could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes

本修正で、待機イベントである LockAcquire に対する新しい結果コードが追加されました。このイベントの外部呼出し元に影響を与える可能性があります。しかし、これは非常に珍しい使われ方でのみ発生する問題です。

これにより、1つの SPI を使用する関数が、別の関数を呼び出すときに起こり得る干渉を防ぎます。

新しく UNION型の PGAlignedBlock、PGAlignedXLogBlock を設けて、これらを 単なる char配列の代わりに使用して、コンパイラがアラインメントを外れた開始アドレスにバッファを置くことがないようになりました。これにより一部プラットフォームでのクラッシュを回避します。問題がなかったプラットフォームでもパフォーマンス向上が期待できます。

これまでは C99 以前の振る舞いをしていました。主にWindowsなど、このコードが使われているプラットフォームでは、呼び出しコードが C99 のセマンティクスを前提としていた場合にバッファオーバーランを検出できない可能性がありました。

configure スクリプトの修正です。これにより浮動小数点のオーバーフローチェックが失敗することを回避できます。

以前のリリースでは、Linux 上で icc を使ってビルドする際、間違った結果となりました（恐らく他の組み合わせでも）。これにより、システムから報告されたエラーに対して libpq が有用なエラーメッセージを返さない動作が生じました。

これらのマクロは 9.6 以降は存在していましたが、古いバージョンにも追加して、固有のコーディングなしで拡張機能を利用したいという要望がありました。