他の関連する 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モード以外のプライマリサーバのシャットダウンを妨げました。

これまで、ユーザは関連する外部サーバに USAGE権限を持たなくとも、自身のユーザマッピングのオプションを参照できました。このようなオプションにはユーザ自身ではなく管理者によって設定されたパスワードが含まれているかもしれません。

本バージョンアップは新たに initdb でデータベースクラスタを作るときの振る舞いを修正するだけです。既存のデータベースクラスタを修正するには、以下の手順を実行する必要があります。

postgresql.conf で以下設定を与えて PostgreSQLサービスを再起動します。ALTER SYSTEM コマンドが利用可能なら、それを使っても良いです。

allow_system_table_mods = true

データベースクラスタ内の各データベースでスーパーユーザにて以下を実行します。

SET search_path = pg_catalog;
CREATE OR REPLACE VIEW pg_user_mappings AS
    SELECT
        U.oid       AS umid,
        S.oid       AS srvid,
        S.srvname   AS srvname,
        U.umuser    AS umuser,
        CASE WHEN U.umuser = 0 THEN
            'public'
        ELSE
            A.rolname
        END AS usename,
        CASE WHEN (U.umuser <> 0 AND A.rolname = current_user
                     AND (pg_has_role(S.srvowner, 'USAGE')
                          OR has_server_privilege(S.oid, 'USAGE')))
                    OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
                    OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
                    THEN U.umoptions
                 ELSE NULL END AS umoptions
    FROM pg_user_mapping U
         LEFT JOIN pg_authid A ON (A.oid = U.umuser) JOIN
        pg_foreign_server S ON (U.umserver = S.oid);

このとき、template0 と template1 についても実行してください。さもなくば、新たにデータベースを作る度にその新たなデータベースに上記手順を実行してください。

template0データベースに書き込みするには、接続可能ないずれかのデータベース上で以下のSQLを実行します。

(9.5以降の場合)
書き込み可能にする:
 ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
書き込み不能に戻す:
 ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;

(9.4以前の場合)
書き込み可能にする:
 UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
書き込み不能に戻す:
 UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';

最後に allow_system_table_mods 設定を削除して、PostgreSQLサービスを再起動します。

libpq は md5 などのパスワードを使う認証方式について、空パスワード指定の場合には、これをサーバに送りません。そのため、ユーザのパスワードが空に設定されていた場合、psql や、その他の libpqベースのクライアントからパスワード認証で接続できません。これにより、管理者はユーザのパスワードを空にすることはパスワードを使った認証での接続を禁止するのに等しいと認識しているかもしれません。しかしながら、改造されているクライアントや libpqベースでないクライアントでは空パスワードでのログインは可能でした。

本修正では、全ての場合で空パスワードをサーバが拒絶するように変更されました。(CVE-2017-7546)

ラージオブジェクトに書き込みを行う SQL関数 lo_put() は、クライアントインタフェース向け関数 lowrite() と同様の権限が必要でしたが、検査が欠落していて、任意のユーザでラージオブジェクトのデータ変更が可能となっていました。(CVE-2017-7548)

これまでは、pg_upgrade を実行した後、スタンバイサーバをデータ同期する前に、wal_level設定を変更するためにプライマリサーバを起動停止するように記述していました。この手順は安全ではありません。

いくつかのセッションが同時にタプル更新チェーンを競合しないモードで古いスナップショットを使ってロックして成功した場合、結果として有効行が無い状態となるので、稀な状況においてエラーを起こすことがありました。

その結果、参照先テーブルの該当行が同時更新されている場合に、該当行は在るにもかかわらず、それを参照する外部キー制約違反のエラーが発生しました。

おそらくアンチウイルス製品により稀におきていた子プロセスの起動失敗が、これにより修正されると考えられます。

この修正により、チケットを認識するクライアント側の SSLコードによる再接続の失敗を防止します。

シャットダウン後 0.5秒以内に発行された統計情報の問い合わせは、事実上無視されていました。

これによりデフォルトの受信バッファサイズがこれよりも小さい古いプラットフォームで、統計情報データを取りこぼすリスクを軽減できます。

結果として一時ファイルでディスク領域が過度に消費されていました。

以前のアルゴリズムはオープンしているトランザクションが多いサーバ上では実行不能なほど高コストでした。

これは特に、頻繁にキャッシュ無効化を起こすロジカルデコーディングに有益です。

複数列の外部キー制約が存在していて、しかし、クエリの結合構造と完全に一致しない場合、プランナは全く役に立たないヒューリスティック推定を使用していました。このような場合に、9.6 より前の推定方法に戻されました。

エラー発生例：
db1=# CREATE DOMAIN d25 int[];
db1=# CREATE TABLE t25 (c1 d25);
db1=# INSERT INTO t25 (c1[1], c1[2]) VALUES (100, 200);
ERROR:  multiple assignments to same column "c1"

単なる配列型であれば実行できる：
db1=# CREATE TABLE t25_2 (c1 int[]);
db1=# INSERT INTO t25_2 (c1[1], c1[2]) VALUES (100, 200);
db1=# SELECT * FROM t25_2;
    c1
-----------
 {100,200}
(1 row)

以下のような形の SQL がエラーになっていましたが本来制限されるものではありませんでした。

db1=# SELECT sum((SELECT row_number() OVER () FROM t1 )) FROM t1;
ERROR:  aggregate function calls cannot contain window function calls

以前は、ビュー条件を確認する必要がある場合でも、確認せずに、更新を完全に外部サーバにプッシュしてしまう可能性がありました。

以前の修正では、CREATE実行時に競合する自動生成された配列型の名前を変更していました。本修正は以前の修正を名前変更操作に拡張したものです。

再作成した制約にコメントを再適用すると、奇妙なエラーメッセージ（現れ方は様々です）が表示されたり、クラッシュすることがありました。

CREATE TABLE は暗黙に CHECK制約に対する NOT VALID 指定を外します。作った時点ではテーブルは空なので制約は即座に検証済にできるからです。しかし、これは外部テーブルにはあてはまりません。

CREATE TYPE は以前から使われていないこのスタイルで宣言された I/O 関数を更新しますが、型に依存関係を記録することを忘れ、後続の DROP TYPE が関数定義を壊れたままにしていました。

本修正を適用した結果、money型の値の演算結果（多くは末尾桁部分）が変わる可能性があります。

広く使われているものを含め、ロケールによっては、これらの関数がマルチバイト文字の断片を空白として誤って解釈する可能性がありました。マルチバイトの識別子（テーブル名等）を使っている場合の問題となります。

これによって移植性の問題が回避されます。典型的には、最近の Perlバージョンで作業する場合、ライブラリの読み込み中にハンドシェイク不一致が表示されていました。

これを行わないと、SSL から non-SSL 接続へのフォールバック時に、SSL試行における GSS/SASLの失敗により常に非SSLの試行の失敗をひき起こしました。SSPIは失敗しませんでしたが、メモリがリークしました。

この誤動作は、BSD プラットフォーム (macOS を含む) で観測されましたが、他のほとんどのプラットフォームでは検出されませんでした。

権限を与える命令よりも後ろにすることで、マテリアライズドビューが他ユーザが所有するテーブルを参照しているときの、ダンプ/リストアでのエラーを防ぎます。

また、イベントトリガの所有者を適切に割り当てるようになりました。これまではリストアスクリプトを実行したスーパーユーザが所有者になっていました。

publicスキーマが無い場合に失敗しないようになりました。

ファイルディスクリプタをバイナリモードにしそこなっていたため、標準出力に書き出されたダンプに壊れたデータが含まれていました。圧縮されたプレーンテキスト（-Z -Fp オプション）を標準出力に書き出す（すなわち -f オプションではない）場合に該当します。

一部の限られたケースで pg_dump がビューをダンプするのにpg_get_ruledef() 関数に依存することがありました。その場合、誤ったダンプ出力が生じて、リストア時に失敗してしまいます。

共通列を持たない NATURAL LEFT JOIN で ON句を持たない定義になっていました。これは文法違反でエラーになります。

誤動作例：
db1=# CREATE TABLE t47_1 (id1 int, c1 int);
db1=# CREATE TABLE t47_2 (id2 int, c2 int);
db1=# CREATE VIEW v47 AS SELECT * FROM t47_1 NATURAL LEFT JOIN t47_2;
db1=# q

$ pg_dump -d db1 -t v47
  (出力中略)
CREATE VIEW v47 AS
 SELECT t47_1.id1,
    t47_1.c1,
    t47_2.id2,
    t47_2.c2
   FROM (t47_1
     LEFT JOIN t47_2);

関数呼び出しと似た形の式が正しく復元できませんでした。

(例: FROM句の4つの式はいずれも正しくダンプできませんでした)
CREATE VIEW v48 as
  SELECT * FROM
    COALESCE(1,2) AS c,
    COLLATION FOR ( 'x'::text ) col,
    CURRENT_DATE AS d,
    CAST( 1 + 2 as int ) AS i4;

ファイルディスクリプタをバイナリモードにしそこなっていたため、標準出力に書き出されたバックアップに壊れたデータが含まれていました。

通常は PostgreSQLのデータディレクトリにこのようなファイルは現れませんが、一部の場合に存在する可能性があります。

これはアップグレードされたスタンバイサーバが再接続するのを防ぎます。

報告されるレコード長が誤っていました。

これにより接続パラメータに影響するオプション変更が即座に反映されることを保証します。

従来よりもより多くのケースで、応答しないリモートサーバの待機から迅速に抜け出すことができるようになります。

本変更は大きい拡張ライブラリのビルドを助けます。一部のプラットフォームで -fpic では大きい共有ライブラリにおいて失敗していました。

本修正により、MSVCビルドで標準の libxml2 インストールの状態からファイルを移動する必要がなくなります。

これにより最近の Perlバージョンで警告やエラーが発生するのを回避します。

圧縮後、インラインデータで 64KB 以上のタプルにおいて、ロジカルデコーディングがクラッシュしていました。これは REPLICA IDENTITY FULL が有効なテーブルでのみ発生します。