本障害はクラッシュをひき起こす他、攻撃を意図した作りこまれた入力によってサーバプロセス上の任意のメモリが露出してしまう可能性がありました。

PARTITION BY 構文を使ったテーブルパーティショニングで「PARTITION BY RANGE ((col1 / 1000), substr(col2, 1, 5))」など、複数の式でパーティションキーを指定した場合に問題が生じます。 (CVE-2018-1052)

（クラッシュ発生例 - CREATE TABLE でクラッシュします）
db1=# CREATE TABLE ptest (col1 int, col2 text, col3 text)
        PARTITION BY RANGE ((col1 / 1000), substr(col2, 1, 5));
db1=# CREATE TABLE ptest_1 PARTITION OF ptest
        FOR VALUES FROM (0,'00000') TO (1, '10000');
db1=# CREATE TABLE ptest_2 PARTITION OF ptest
        FOR VALUES FROM (0,'10000') TO (1, '20000');
server closed the connection unexpectedly

pg_upgrade は通常は一時ファイルを実行ユーザのみ読み書きできるように制限します。しかしながら、実行したユーザの umask 設定で許可されていると、「pg_dumpall -g」の出力を含む一時ファイルがグループ参照可能、または、全ユーザ参照可能、更には書き込み可能になることがありました。

複数ユーザで使用するマシンにおいて、umask 設定や実行するディレクトリのパーミッションによっては、データベースのパスワードが露出することになります。(CVE-2018-1053)

一部のケースで VACUUM はこのようなデッドタプルの除去に失敗していました。これによりデータ破損を起こすことがあります。

インデックス破損をもたらす可能性があります。

これには削除済みのインデックスエントリが確実に除去されることが必要です。従来コードでは他プロセスが同時にクリーンアップを実行しているとき VACUUM がクリーンアップをスキップするのを許していて、その結果、無効なエントリがインデックスに置き去りにされてしまう危険がありました。

この誤りにより同時データ読み込みにおいて誤動作のおそれがありました。どのような結果が生じるか完全には分かっていません。

必ず col = ANY(ARRAY[val1, val2, ...]) という式で制約が書かれていたものが、col = val1 OR col = val2 という形でも生成されるようになります。

以下のエラーが発生していました。

ERROR:  could not find inherited attribute "col1" of relation "tbl1"

テーブルのハッシュインデックスを再構築するとき、初期ハッシュサイズを定めるのに pg_class 統計情報が使われます。本修正で古い情報が使われるのを防ぐことができます。

例えば以下は同じ行内容（列なし行）なので結果は「1 row」であるべきです。

（修正前バージョンの動作例）
db1=# SELECT FROM generate_series(1,5) UNION SELECT FROM generate_series(1,3);
--
(8 rows)

使用したときクラッシュが生じていました。このような使い方は今のところサポートされない仕様とします。

（クラッシュ発生例）
db1=# CREATE TYPE type13 AS (f1 integer, f2 text, f3 bigint);
db1=# CREATE TABLE tbl13 OF type13 (f1 WITH OPTIONS GENERATED ALWAYS AS IDENTITY);
The connection to the server was lost. Attempting reset: Failed.

いくつかの場合、特に COPY、ALTER TABLE .. ADD COLUMN において、期待されたデフォルト値が適用されず、NULL 値が挿入されていました。

通常テーブルと外部テーブルが継承テーブルのツリーに混在していると、UPDATE、DELETE の問い合わせで不正なプランが作られました。一部のケース、特に行レベルトリガが外部子テーブルにある場合に、目に見えるエラーとしてあらわれます。

UPDATE 文で以下のエラーが出るケースが報告されました。

ERROR:  could not open file "base/12345/34567": No such file or directory

（サブクエリ無しで実行できる例とエラー例）
db2=# SELECT * FROM generate_series(1, 2) g,
        LATERAL (VALUES (g*3), (g*5)) AS v(x);
 g | x
---+----
 1 |  3
 1 |  5
 2 |  6
 2 | 10
(4 rows)

db2=# SELECT * FROM generate_series(1, 2) g,
        LATERAL (VALUES ((SELECT g*3)), ((SELECT g*5))) AS v(x);
ERROR:  SubPlan found with no parent plan

これまでは拡張統計の定義ができて情報収集も行われるにもかかわらず、プランナがこれらを適用しませんでした。

PostgreSQL 10.0、10.1 では「SELECT DISTINCT unnest(foo)」のようなケースで旧リリース系列よりもより少ない行数見積が得られており、最適でないプランが選択される可能性がありました。

ロジカルデコーディングは多数の WAL レコードを生成するトランザクションのために、溢れた WAL レコードをディスクに書き出すことがあります。通常これらのファイルはトランザクションのコミットまたはアボートのレコードに達した後にクリーンアップされます。しかし、そのようなレコードがずっと見つからない場合、削除を行うコードは不適切な動作をしていました。

削除処理が無期限に待たされる可能性がありました。

pg_read_all_stats ロールはあらかじめ用意されているロールの一つです。

これまで idle と表示されていました。

これまでは「scram-sha256」と表示されていて、ユーザに混乱をもたらす恐れがあるので綴りが修正されました。

XML 文字列は常にデータベースのエンコーディングで格納されます。そのため、libxml に他のエンコーディング宣言で動作できるようにすることは誤った結果をもたらしました。UTF8 以外のエンコーディングでは何にせよ非 ASCII の XML データのサポートは保証されませんので、バグ互換性のために以前の振る舞いを維持します。

この変更は xpath() と関連する関数のみに影響があります。他の XML 処理コードは既にこのように振舞います。

本変更でクライアントがバージョン 3.x を要求できるようになりました。これにより将来のプロトコルのマイナーバージョンアップを迅速に適用できるようになるはずです。

これまで、プロトコルバージョン番号のメジャー部とマイナー部の間で機能的な違いがなく、PostgreSQL サーバは 3.0 より新しいバージョンの使用を単に拒絶していました。

バージョン 10 にはこの機能はありません。加えて、接続時のこれを使うかどうかのネゴシエーションが誤って行われていました。

繰り返し不運なタイミングが生じるとプロセスが無限ループに陥る恐れがありました。バージョン 10 では条件変数の使用が限定されているため、これはパラレルインデックススキャンと一部のレプリケーションスロット上の操作にだけ影響があります。

これまで並列問い合わせは、fork() の失敗や他の低確率な問題でワーカが開始できないときにハングアップしがちでした。

パラレルワーカからの postmaster ログ出力でゴミが吐き出されるのを防止します。

これまでに知られている症状は一部の並列集約問い合わせでクラッシュすることです。

これは同時に選択された行の更新が行われているときに、結合を伴う UPDATE または SELECT FOR UPDATE を行った場合にのみ発生します。

LDAP URL としてホスト名の無い「ldap://」やベース DN の無い「ldap://localhost」などがあると、pg_hba.conf を読み込む際にクラッシュが発生します。バインド DN が無い設定の場合は NULL ポインタをエラーメッセージで出力しようとして、一部のプラットフォームではクラッシュするかもしれません。

以下のような単純な SELECT 文で応答が無くなったり、メモリ不足エラーになる動作が報告されていました。

SELECT DISTINCT bigint_val FROM tbl46 ;

Oracle のものと同じ動作をする instr 関数と記載されていますが、第 3 引数が負の値であった場合、第 4 引数がゼロまたは負の値であった場合の動作が Oracle の instr 関数と異なっていて、修正されました。

アーカイブするエントリに付与するタグが修正されました。修正前の動作は、LARGE OBJECT で始まるタグを見てラージオブジェクト関連のエントリと認識しようとします。このため、スキーマ（オブジェクト定義）ではなくデータとして間違って分類されて、スキーマのみ、あるいは、データのみのダンプの際に望ましくない結果になる可能性があります。

この変更は pg_restore --list の出力で目に見える結果としてあらわれます。

第二引数（次元指定）の意味が、様々な次元数であっても、どの値が選ばれるか予想可能になるように変更されました。

これは非互換の変更です。これを使った式インデックスは再作成が必要ですし、マテリアライズドビューはリフレッシュが必要です。

GROUP BY の重複とは以下のようなケースです。選択リストの1番目も2番目もc1列で同一列ですが、どちらも GROUP BY 対象です。

SELECT c1, c1 FROM ft56 WHERE c1 > 5 GROUP BY 1, 2;

以下のエラーが報告されました。

ERROR:  targetlist item has multiple sortgroupref labels

contrib/start-scripts/osx は廃れた基盤を使っていて近年の macOS リリースでは動作しません。新たに contrib/start-scripts/macos にて新たな起動基盤を使ったスクリプトが提供されます。

これはいくつかの一般的な Windows むけ Perl 配布物で PL/Perl をビルド可能にします。

これにより起動時初期の従来ダンプが生成されなかった障害で、コアダンプ取得が可能になるでしょう。

ブラジル、サントメ・プリンシペの夏時間法の変更、ボリビア、日本、南スーダンの歴史的な修正が含まれます。US/Pacific-New ゾーンは削除されました（これは America/Los_Angeles の別名にすぎません）。

INSERT ... ON CONFLICT DO UPDATE の更新パスは、競合インデックスの列に対してSELECT のアクセス許可を必要としますが、制約名で指定された競合の場合はアクセス許可をチェックできませんでした。

（以下のようなテーブルに対して）
db1=# CREATE TABLE t1a (a int PRIMARY KEY);
db1=# GRANT UPDATE ON t1a TO foo ;
db1=# GRANT INSERT ON t1a TO foo ;

（これまでfooユーザで以下のSQLがエラーになりませんでした）
db1=> INSERT INTO t1a VALUES (1) ON CONFLICT
        ON CONSTRAINT t1a_pkey DO NOTHING;
ERROR:  permission denied for relation t1a

また、行単位セキュリティが有効なテーブルでは、(競合インデックスの指定方法に関係なく) テーブルの SELECT ポリシーに対して更新された行をチェックできませんでした。(CVE-2017-15099)

これらの関数は、FROM ... AS 句で指定された結果の行型を、指定されたタプル値の実際の行型と一致するかどうかをチェックせずに使用していました。チェックしなければクラッシュすることになりますが、サーバのメモリ内容が露出してしまう可能性もありました。(CVE-2017-15098)

（以下は第一引数の行型とASで指定する型が一致しません）
db1=# SELECT * FROM json_populate_recordset(ROW(NULL::int,NULL::int), '[{"b":"2"},{"a":"3"}]') AS q (a text, b text);
ERROR:  invalid memory alloc request size 18446744073709551613
（クラッシュまたは奇妙なエラーが発生します）

以前は、root として実行中に postmaster ログファイルが開かれました。したがって、データベースの所有者は、$PGLOG をほかのファイルへのシンボリックリンクにすることで、ログメッセージが追加されて壊れ、別のシステムユーザに対して攻撃をしかけることができます。

デフォルトでは、これらのスクリプトはどこにもインストールされません。それらのスクリプトを使用しているユーザは、手動で再コピーするか、変更されたバージョンに同じ変更を適用する必要があります。既存の $PGLOG
ファイルが root 所有の場合は、修正されたスクリプトでサーバを再起動する前に、そのファイルを削除するか名前を変更する必要があります。(CVE-2017-12172)

以前は競合状態により、インデックスから一部のテーブル行が漏れる可能性がありました。この問題が過去に発生した状態から回復するには、既存の BRINインデックスを再構築する必要があります。

これらの競合状態は「ERROR: invalid index offnum: NN」や「ERROR: corrupted BRIN index: inconsistent range map」のようなエラーにつながる可能性があります。

これまで発行元テーブルが購読先テーブルよりも少ない列しか持たない場合、UPDATEをレプリケーションすると不足している列をNULLにしていました。これからは元の値を残すようになります。

以前はテーブルにBEFORE ROW UPDATEトリガとBEFORE ROW DELETEトリガの両方がないと駆動されませんでした。

以下のようなロジカルデコーディングの関数を呼び出すだけの PL/pgSQL のユーザ定義関数を実行してクラッシュする例が報告されました。

CREATE FUNCTION logical_replication_slot_lsn_delta(slot text)
  RETURNS pg_lsn AS $$
    BEGIN
      RETURN location FROM pg_logical_slot_peek_changes(slot,null,1) ;
    END
$$ LANGUAGE plpgsql;

これにより、DMLコマンドに付加されたCTEに対するバージョン10より前の動作が、復元されます。

（10.0では以下がエラーになっていました）
db1=# CREATE TABLE t9 (i int);
CREATE TABLE
db1=# WITH test AS (SELECT 123) INSERT INTO t9 VALUES (1);
ERROR:  relation "t9" cannot be the target of a modifying statement

これにより、バージョン10より前 (およびSQL標準) の動作が復元されます。

（10.0では以下がエラーになっていました）
db1=# CREATE TABLE t10 AS SELECT generate_series(0, 10)::real AS r;
SELECT 11
db1=# SELECT sum(1/r) FILTER (WHERE r > 0) FROM t10;
ERROR:  division by zero

（このようなデータに対して）
db1=# CREATE TABLE t11 (i1 int, i2 int);
db1=# INSERT INTO t11 VALUES (1,100),(2,201),(2,202),(3,301),(3,302),(3,303);

（以下のように応答すべきところが）
db1=# SELECT i1, i1 AS a1, count(i2) FROM t11 GROUP BY i1, ROLLUP (a1);
 i1 | a1 | count
----+----+-------
  1 |  1 |     1
  3 |  3 |     3
  2 |  2 |     2
  2 |    |     2
  3 |    |     3
  1 |    |     1
(6 rows)

（修正前バージョンでは以下のようになっていました）
db1=# SELECT i1, i1 AS a1, count(i2) FROM t11 GROUP BY i1, ROLLUP (a1);
 i1 | a1 | count
----+----+-------
  1 |  1 |     1
  3 |  3 |     3
  2 |  2 |     2
  2 |  2 |     2
  3 |  3 |     3
  1 |  1 |     1
(6 rows)

（明示的な VARIADIC引数とは以下のような呼び出し方で、以下は誤った応答です）
db=# SELECT jsonb_build_array(VARIADIC '{a,b,c,d}'::text[]);
   jsonb_build_array
------------------------
 [["a", "b", "c", "d"]]
(1 row)

（以下の呼び出し方であれば該当しません）
SELECT jsonb_build_array('a','b','c','d');
  jsonb_build_array
----------------------
 ["a", "b", "c", "d"]
(1 row)

ここでのビューに列を追加するとは、既存のビューをCREATE OR REPLACE VIEWコマンドでより列が多い定義に上書きすることを指します。

これらの依存関係がないと、失敗させる必要があるときに列またはデータ型の DROP を通過させることができ、あとでビューまたはルールを使用してエラーが発生する可能性があります。このパッチは、既存のビュー/ルールを保護するためのものではなく、今後作成されるもののみを保護します。

FieldSelect と FieldStore は実装上の要素名です。本障害により、TYPE定義を含むデータベースオブジェクトのCASCADE付きDROPで「ERROR: could not open relation with OID 34567」などの奇妙なエラーが報告されました。

プランナは、誤って範囲型がハッシュ結合またはハッシュ集約で使用するためにハッシュできると仮定していましたが、実際には範囲の派生元型にハッシュサポートがあるかどうかをチェックする必要があります。いずれにしても、すべての組み込みの範囲型はハッシュ可能なので、それらには影響しません。

これにより、たとえば、varchar列の拡張統計を適切に使用することができます。

これにより、組み込みの順序集合集約でクラッシュし、おそらくユーザ記述の集約でもクラッシュします。バージョン 11 以降では、このようなケースを安全に処理するための規定が含まれる予定ですが、リリースされたブランチでは最適化を無効にするだけです。

セッションが問い合わせを実行せず、単に通知を聞いた場合、20億回を超えるトランザクションでは、同時にコミットするトランザクションからいくつかの通知が欠落していきました。

このケースは、以前のバグ修正（9.6.2、9.5.6、9.4.11で適用されたもの）によって意図せずに壊れていました。

これは集約関数のための内部実装関数です。

pg_dump がエラーで終わるケースが報告されました。

これにより、parray_gin 拡張がインストールされているときに、競合する演算子が定義されたときの、問題を回避できます。

これは Windows でとくに役立ちます。

バージョン10.0では、~/.pgpass を読み込もうとしてホームディレクトリが見つからなかった場合、誤って致命的なエラーとして扱っていました。

~/.pg_service.conf を読むとき、バージョン10.0 と以前のリリースのブランチは同様の誤りを犯していましたが、サービス名が指定されていなければ、そのファイルが探し出されないので気づきませんでした。

make check のように動作することを意図したデフォルト以外のテスト手順では、一時的なインストールが最新であることを確認できませんでした。

ツールチェーンが変更されたため、10.0 のユーザマニュアルにはイントラページアンカーに小文字の文字列が含まれていたため、Web サイトのドキュメントの外部リンクが壊れていました。前の大文字の文字列の使用法に戻ります。

以前は、この動作はプラットフォームに依存していました。

これにより、副問い合わせに varchar 型の結果列がある場合に、意図した最適化が行われます。

改行で終わらない pg_hba.conf ファイルの最後の行の誤った解析が修正されました。

これにより、さまざまな問題が修正されました。唯一、ユーザに見える可能性が高いのは、POSIX スタイルのゾーン名のデフォルトの DST ルールは、時間帯データディレクトリに posixrules ファイルが存在しない場合、数十年前のではなく、現在の米国の法律と一致していることです。