一部のプランナの選択性見積り処理ではプランナ統計情報(pg_statistic の 最頻値など)で見つかった値にユーザ定義演算子を適用します。そのため、実行したユーザにその列を参照する権限がなくとも、漏洩のある演算子が一部行の列データ値を露出させることができます。9.6.3、9.5.7、9.4.12、9.3.17、9.2.21 での CVE-2017-7484 セキュリティ障害の修正で同様の問題に対する対処が行われていましたが、行単位セキュリティについては対応されていませんでした。

本修正により、漏洩のある（LEAKPROOF属性が真でない）演算子は関連する行単位セキュリティ(RLS)ポリシーが無い場合に限ってプランナ統計情報に適用が許されるようになります。

この障害はクラッシュをひき起こします。また、原理的にはサーバメモリ内容を露出させる攻撃に利用できる可能性があります。なお、上記のパーティション振り分けのエラーとは以下の類です。

db=# CREATE TABLE parted_tbl (id int, v text) PARTITION BY RANGE (id);
db=# CREATE TABLE part1 PARTITION OF parted_tbl FOR VALUES FROM (1) TO (100);
db=# INSERT INTO parted_tbl VALUES (105, 'XX');
ERROR:  no partition of relation "parted_tbl" found for row
DETAIL:  Partition key of the failing row contains (id) = (105).

例えば、ALTER TABLE .. ALTER COLUMN TYPE 実行時に物理テーブルの書き換えは不要と判断したケースで発生します。ALTER TABLE を行って定義情報の破損が生じたパーティションテーブルを、次に DROP したときにバックエンドプロセスがクラッシュ終了する動作が報告されました。

以下のような発生例が報告されました。

（あるセッションで以下のように一時テーブルを作った後、）
db=# CREATE TEMP TABLE t4 (c int GENERATED BY DEFAULT AS IDENTITY)
       ON COMMIT DROP;

（別セッションで別の一時テーブルを作ろうとした際に不明なエラーが出る）
db=# CREATE TEMPORARY TABLE t4_2 (d text);
ERROR: could not open relation with OID 16345

これにより pg_upgrade を失敗させる可能性もあります。以下の予期せぬエラーが発生します。

ERROR:  incorrect attribute map

この障害は、アタッチ後に実行する当該パーティションインデックスを使う DDL で以下のような予期せぬエラーを発生させます。

ERROR:  index ... not found in partition ...

これは、READ COMMITTED 隔離レベルを使用していて、他のセッションが問い合わせの対象行を同時並行に更新していた場合にEPQ(EvalPlanQual)の再チェック処理で発生します。

パーティションテーブルに列削除が行われていた場合に INSERT 実行に対して、以下の予期せぬエラーが発生する場合がありました。

ERROR: cannot extract attribute from empty tuple slot SQL state: XX000

（権限の問題などで）fast-path処理が使えない場合という、一般的でない場合以外では、この問題は顕在化しません。fast-path、slow-path は検査処理実装の内部的な区別です。前者が使えない場合に後者が使われます。

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

db=# CREATE ROLE test_role WITH LOGIN;
db=# CREATE TABLE t9_ref(a int PRIMARY KEY);
db=# GRANT REFERENCES ON t9_ref TO test_role;
db=# SET ROLE test_role;
db=> CREATE TABLE t9(a int, b int) PARTITION BY LIST (a);
db=> ALTER TABLE t9 ADD CONSTRAINT t9_b_key
        FOREIGN KEY (b) REFERENCES t9_ref(a);
ERROR:  could not open file "base/16432/49876": No such file or directory

このような場合、RETURNING句があっても問い合わせが正しい列セットを報告せず、文レベルトリガがあっても実行されませんでした。

（障害動作例: WHERE false の場合の RETURNING句の応答は列が無く不正）
db=# CREATE TABLE t10 (a int, b int);
db=# CREATE TABLE t10c () inherits (t10);
db=# INSERT INTO t10c VALUES (1,2);
db=# UPDATE t10 SET a = a + 1 WHERE false RETURNING b, a;
--
(0 rows)
UPDATE 0

db1=# UPDATE t10 SET a = a + 1 WHERE true RETURNING b, a;
 b | a
---+---
 2 | 2
(1 row)
UPDATE 1

この変更は 10.xバージョンの振る舞いに戻したことになります。

db=# CREATE TABLE t11p (a int) PARTITION BY LIST (a);
db=# CREATE TABLE t11c PARTITION OF t11p FOR VALUES IN (1);
db=# SET constraint_exclusion TO on;
db=# EXPLAIN SELECT * FROM t11c WHERE a = 2;
（修正前の結果、範囲外の値でもテーブルスキャンが発生）
                     QUERY PLAN
----------------------------------------------------
 Seq Scan on t11c (cost=0.00..41.88 rows=13 width=4)
   Filter: (a = 2)
(2 rows)

（本来期待される結果）
                QUERY PLAN
------------------------------------------
 Result  (cost=0.00..0.00 rows=0 width=4)
   One-Time Filter: false
(2 rows)

プロシージャがオープンされた明示的あるいは暗黙的なカーソル（PL/pgSQLのFORループ問い合わせなど）を持つときにコミットしようとした場合、カーソルはコミット前に完全に実行され結果を保存して以降で利用可能にします。このような処理の中でエラーが生じた場合にバックエンドプロセスのクラッシュが起こっていました。

このようなテーブルはパブリケーション用には無視されるべきでしたが、一部コードでそうなっていませんでした。

以下例のように複数行を同時に挿入した場合、ビューにデフォルト値が無い列で元テーブルのデフォルト値ではなく NULL が使われてしまいます。

（障害動作発生例: a=14 の行と a=15,16 の行で振る舞いが違う）
db=# CREATE TABLE t14 (a int, b text default 'Table default',
                       c text default 'Table default', d text, e text);
db=# CREATE VIEW v14 AS SELECT * FROM t14
db=# ALTER VIEW v14 ALTER b SET DEFAULT 'View default';
db=# ALTER VIEW v14 ALTER d SET DEFAULT 'View default';
db=# INSERT INTO v14 VALUES (14, default, default, default, default);
db=# INSERT INTO v14 VALUES (15, default, default, default, default),
                            (16, default, default, default, default);
db=# SELECT * FROM t14;
 a  |      b       |       c       |      d       | e
----+--------------+---------------+--------------+---
 14 | View default | Table default | View default |
 15 | View default |               | View default |
 16 | View default |               | View default |
(3 rows)

これによりゼロ列テーブルが作成可能であることと一貫性を持ち、テーブルをビューで置き換える際に失敗するケースを回避できます。

db=# CREATE TABLE t15 (id int primary key, v text);
db=# CREATE TABLE t15_0 ();
db=# CREATE VIEW v15 AS SELECT FROM t15;
db=# CREATE VIEW v15_0 AS SELECT * FROM t15_0;
（修正前バージョンでは上記両CREATE VIEVで以下のエラーが出ました）
ERROR:  view must have at least one column

AS の後に問い合わせにプリペアド文を実行する EXECUTE文を記述することは可能であるべきでしたが対応していませんでした。

これまで、行単位セキュリティ(RLS)ポリシーを持つテーブルがビューを通してアクセスされる場合に、セキュリティ検査がビューを呼び出したユーザで行われ、ビュー所有者ユーザで行われませんでした。後者が本来の正しい動作です。

これまでは PostgreSQL は SQL:2003 の定義に従っていて、このような場合にはデータを受け入れませんでした。しかし、ダンプ/リストアで全ての有効なXMLデータを受け入れる xmloption の設定値が無いという重大な問題が問題が生じることから、SQL:2006 の定義に変更されました。

加えて、確実にダンプ/リストアできるように pg_dump が SET xmloption = contentを出力するようになりました。

PostgreSQLのマスタプロセス(postmaster)は、たとえ postmaster.pid ファイルが削除されていても、以前の postmasterから生じた実行中プロセスが無いかを調べるようになりました。

これにより PostgreSQL二重起動によるデータ破損を予防します。

これは vacuum_cleanup_index_scale_factor 設定値に基づいてインデックスのクリーンアップが必要かどうかについて不正確な判断をひき起こします。

パラレル問い合わせ実行があるときに、実行時統計情報のトランザクション数が本来より多く計数されていました。

前回のマイナーリリースには後方互換性に問題がありました。ストリーミングレプリケーション等で更に以前のマイナーバージョンが生成したWAL を適用する場合にロック処理の問題からハングアップする動作が報告されました。

本修正で WALレコードを適用する際に、前マイナーリリースの修正があるWALレコードも、無いレコードも両方読めるように修正されました。

特に JDBCで問い合わせ結果を1行ずつ取得する場合に顕在化します。

このメモリリークはセッション内で継続します。

ファイル同期に失敗が生じたなら PANIC とする前回リリースでの変更は、失敗が想定できて本質的に操作がサポートされないことによる場合については、過度に偏執的でした。

例えば Windows Subsystem for Linux において sync_file_range がサポートされないために PANIC が起きていました。

以前は誤ってデータベース名が報告されていました。

（エラー発生例）
db=# SELECT * FROM (VALUES (1),(2)) v1(r1)
       LEFT JOIN LATERAL (
         SELECT * FROM generate_series(1, v1.r1) AS gs1
           LEFT JOIN LATERAL (
             SELECT * FROM generate_series(1, gs1) AS gs2
               LEFT JOIN generate_series(1, gs2) AS gs3 ON TRUE
           ) AS ss1 ON TRUE
           FULL JOIN generate_series(1, v1.r1) AS gs4 ON FALSE
       ) AS ss0 ON TRUE;
ERROR:  failed to build any 3-way joins

この障害により、10.x バージョンでは僅かに非効率なプランが生成されるだけですが、11.x バージョンでは「ERROR: set-valued function called in context that cannot accept a set 」エラーをひき起こす可能性があります。

元となるテーブルにビューを通してアクセスするとき、漏洩のある演算子をテーブルの統計データに適用して良いかの判断に、問い合わせを実行するユーザの権限ではなく、ビュー所有者の権限を考慮するようになりました。これにより、プランナのどのデータが可視かのルールをエグゼキュータのルールと一致させて、劣ったプランを回避します。

これまでは、並列化されている可能性のある対象リストを評価する動作が無いかもしれませんでした。この問題によりプランの劣化が発生していました。

本障害により、含められた列を持つユニークインデックスが問い合わせ結果の唯一性を保証することをプランナが認識しなくなる可能性があり、プランの劣化がもたらされました。

以下例のように STRICT を指定した SQL関数に NULL を渡しても、応答が NULL にならない動作が発生していました。

db=# CREATE TABLE t34 (c1 int);
db=# INSERT INTO t34 VALUES (1), (NULL);
db=# CREATE FUNCTION f34 (int) RETURNS int[] LANGUAGE sql AS 
     $$ SELECT array[0, $1]::bigint[]::int[] $$ STRICT;
db=# SELECT f34(c1) FROM t34;
（修正前の応答）
   f34
----------
 {0,1}
 {0,NULL}
(2 rows)

（正しい応答、2番目は NULL が返る）
  f34
-------
 {0,1}

(2 rows)

これにより「ERROR: dsa_area could not attach to segment」や「ERROR: cannot unpin a segment that is not pinned」のエラーが生じる可能性がありました。

pg_identify_object_as_address() はシステム情報を取得するSQL関数の一つです。

以前は未来のトランザクションの状態を取得し続けると、最終的に以下のようなエラーが発生していました。

=# SELECT txid_status(txid_current() + 1);
ERROR:  could not access status of transaction 32768
DETAIL:  Could not read from file "pg_xact/0000" at offset 8192: No error: 0.

サーバが OpenSSL 1.0.2 以降を使用しているときに libpq がOpenSSL 1.0.1 以前を使用していると、どの SASL機構を使用するかのネゴシエーションが失敗し、「ERROR: channel binding not supported by this build」という分かりにくいエラーメッセージが発生していました。

一致する先頭文字をもつパスワード文字列が SCRAM-SHA-256 または MD5形式に正しくハッシュ化されたものと間違われる可能性がありました。

SCRAM-SHA-256形式では先頭が SCRAM-SHA-256$ であるかのみをチェックし、フィールドはチェックしておらず、MD5 形式では先頭が md5 であるかと長さのみをチェックし、16進数の文字であるかはチェックしていませんでした。パスワードは受け入れられますが、あとで使用できなくなります。

ASCII 以外の文字を含むローカライズされた月または日の名前は、以前は予期せぬエラーまたはそのロケールで誤った出力を発生させていました。

以前は log_file_mode で指定された権限を使用していましたが、バックアップユーティリティに問題を発生させる可能性がありました。

以前は以下のような警告が発生していました。

db=# SET operator_precedence_warning TO on;
db=# SELECT -random() IS NULL;
WARNING:  operator precedence change: IS is now lower precedence than -
row 1: SELECT -random() IS NULL;
                       ^
 ?column?
----------
 f
(1 row)

=# SET random_page_cost TO 'NaN';
ERROR:  parameter "random_page_cost" requires a numeric value

アサートを無効にしたビルドでは本障害によるユーザに見える影響はありません。

コアコードでは考慮する必要はありませんが、いくつかの拡張ではその必要があります。SnapBuildInitialSnapshot() は主としてロジカルレプリケーションのために使われる内部実装関数です。

これまで認識されていなかった不具合の原因は、プロセスのデフォルトスレッドプール用のスレッドスタックの作成です。そのようなスタックが異なるメモリ領域に割り当てられるようになりました。

ディレクトリの読み取り権限がない、といったエラーが検出されないか正しく報告されず、そのかわりにディレクトリが空であるかのように静かに振る舞っていました。

ecpg プログラムでセミコロンが欠けているとき（「SET variable TO DEFAULT」でなく）「SET variable = DEFAULT」の誤変換をひき起こし、サーバに拒否されるであろう誤った構文を出力しました。さらに、複数の型名を列挙した DROP TYPE または DROP DOMAIN コマンドは、実際には最初の型名だけが処理されていました。

以前は、このような状況が原因でサーバーがクラッシュしたり、UPDATE結果が不正確になったりしていました。

これによって Africa/Casablancaゾーンで 2440年の標準時とサマータイムの誤った遷移が出力されるという zic の小さな不具合が修正されます。また、zic に新しい -r オプションが追加されます。

Etc/UCT は Etc/UTC への後方互換性のあるリンクになりました。現在は一般的にタイプミスとされる略語の UCT を生成する別のゾーンではありません。PostgreSQL は依然としてゾーンの省略形として UCT の入力を受け入れますが、それを出力しません。

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以降で使われるものに一致されました。