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 ファイルが存在しない場合、数十年前のではなく、現在の米国の法律と一致していることです。

他の関連する information_schemaビューでは外部テーブルを含めていますが、このビューだけ外部テーブルを無視していました。

このビュー定義はinitdbで導入されるため、単にアップグレードするだけでは修正されません。既存のデータベースクラスタを修正するには、以下をスーパーユーザとして psqlで各データベースに対して実行してください。

BEGIN;
DROP SCHEMA information_schema CASCADE;
i SHAREDIR/information_schema.sql
COMMIT;

SHAREDIR の部分は pg_config --sharedir コマンドで出力されるディレクトリで置換してください。

この状況はアサート失敗に陥るかもしれませんでした。アサート無しのビルドでも、このような終了は起きますが、その場合「ERROR: cannot drop active portal ...」といった予期せぬメッセージがログ出力
されていました。

複合型またはドメイン型の定義を変えるいくつかのALTERコマンドは、それらデータ型の値が何らかデータベースに格納されている場合に、これらの値を更新または検査するのに必要な基盤が欠けているため、失敗すると考えられます。

これまでは、これらの検査は関連する内側の範囲型またはドメイン型でラップされた値を見逃すおそれがあり、データ不整合を許す可能性がありました。

ドメイン型のドメイン型、複合型のドメイン型、ドメイン型の範囲型、といった組み合わせが本障害に該当するデータ型となります。

これにより ecpgプログラムは、RETURNING句をクライアントに返される値を定義するためでなく、内部（例えば CTE内など）に使う SQL構文を含むことができます。

この修正により、time_t値の幅についての矛盾する仮定に基づく PL/Perl のクラッシュが回避されます。

拡張モジュール開発者には気になるかもしれない副作用は、PostgreSQLのWindowsビルドにおいて、これからは _USE_32BIT_TIME_T がグローバルに定義されなくなることです。time_t型は PostgreSQL API定義では用いられていないため、このことが問題を起こすとは考えられません。

フラグ更新を取りこぼしていたため、シャットダウンシグナルを受けても接続しているスタンバイサーバがいる限り walsenderが稼動を続けていて、immediateモード以外のプライマリサーバのシャットダウンを妨げました。