この見逃しは、ダンプのリストアや 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 以降は存在していましたが、古いバージョンにも追加して、固有のコーディングなしで拡張機能を利用したいという要望がありました。

ある種の攻撃方法で dblink や postgres_fdw の権限の無いユーザが、サーバを実行する OSユーザが所有する ~/.pgpass などのサーバ側の認証情報ファイルの使用を防止する検査を迂回できました。ローカル接続に peer認証を許可しているサーバは特に影響を受けます。postgres_fdw セッションへの SQLインジェクションなどの他の攻撃も可能です。

この方法で postgres_fdw を攻撃するには指定の接続パラメータで外部サーバオブジェクトが作成できる必要があります。一方、dblink に対しては、dblink にアクセスできる任意のユーザで攻撃可能です。一般に libpq を使ったアプリケーションに対して接続パラメータを選べると攻撃可能になると考えられます。(CVE-2018-10915)

ビューの SELECTリストが元のテーブルの列と1対1で対応していない場合に、更新可能ビューの誤った展開がクラッシュや「ERROR: attribute ... has the wrong type」エラーをもたらす可能性がありました。

さらにセキュリティ上の問題もありました。攻撃者が同テーブルの他の列にINSERTとUPDATE権限を持っている場合に、この障害を利用してUPDATE権限の無い列を更新できました。また、あらゆるユーザがこの障害を使ってサーバメモリの読み取りが可能でした。(CVE-2018-10925)

障害動作例:
（以下のようなテーブル、ビューで）
db1=# CREATE TABLE t2 (id int primary key, c1 int, c2 int);
db1=# CREATE VIEW v2 AS SELECT id, c2 FROM t2;
db1=# GRANT UPDATE (id, c2) ON t2 TO foo;
db1=# GRANT INSERT (id, c2) ON t2 TO foo;
db1=# GRANT ALL ON v2 TO foo;
db1=# INSERT INTO t2 VALUES (1,1,1), (2,2,2);

（一般ユーザ foo で INSERT ... ON CONFLICT ... を実行）
db1=> INSERT INTO v2 (id, c2) VALUES (1,100)
        ON CONFLICT (id) DO UPDATE SET c2 = EXCLUDED.c2;
INSERT 0 1

（奇妙な結果: c2 が更新されず、権限が無い c1 が NULL に更新）
db1=# SELECT * FROM t2;
 id | c1 | c2
----+----+----
  2 |  2 |  2
  1 |    |  1
(3 rows)

過剰に楽観的なキャッシュ処理方式は、これらの更新が他のセッションから見えなくなるおそれがあり、偽性エラー、あるいは/および、データ破損をもたらす可能性がありました。古いキャッシュデータが既存セッションのみならず新たなセッションにまで残り続ける可能性があるため、この問題は pg_authid などの共有カタログにおいて特に悪質です。

以下のエラーが報告されて問題が発見されました。

ERROR:  found xmin 2906288382 from before relfrozenxid 740087784

これは、テーブルに凍結したXID値（relfrozenxid）よりも手前のxmin値を持つレコードが見つかったという意味です。キャッシュ処理の誤りで実際の relfrozenxid値よりもずっと古い値が参照されていました。
同様に「ERROR: found multixact ... from before relminmxid ...」も起こる可能性があります。

本障害により、そのクラッシュ後のリカバリ起動でWALを適用する際に一貫性をもったデータベース状態に到達していないと判断され、起動に失敗しました。

クラッシュ後の起動失敗のときに「PANIC: WAL contains references to invalid pages」が出る動作が報告されています。

この誤りはアサート失敗として現れます。また、潜在的にホットスタンバイサーバで不必要な問い合わせキャンセルを起こすおそれがありました。

このような場合には破損したデータとして扱えるようになりました。これまでは、WALレコード内に書かれたレコード長の通りに大きいメモリ領域を確保しようと試みていました。その結果、以下のような強いエラーが生じてリカバリ不能になっていました。

FATAL:  invalid memory alloc request size ...

本修正でWALの再読み込みを促す弱いエラーを出すように変更されました。

これにより、リカバリクリーンアップ中のエラー（二相コミットの状態ファイルの問題など）でディスク上に一貫性の無いタイムライン状態が生じるのを回避します。

以下のようにリカバリ完了時にrecovery.confが無いというエラーが出て、失敗する動作が報告されていました。

LOG: selected new timeline ID: 2
FATAL: could not open file "recovery.conf": No such file or directory
LOG: startup process (PID 23456) exited with exit code 1

この変更はファイル削除を一括して行うことで、共有バッファがスキャンされる回数を減らして、特に shared_buffers 設定が大きい場合に処理を効率化します。

これまでは上流サーバに追いついているかどうかを誤判定していました。上流側（sender側）の起動時に、既に追いついているのに "streaming" でなく"catchup" 状態と報告することがありました。

この遺漏により、SQL言語の関数を使った制約を持つドメイン型などの一部の場合でクラッシュを起こしていました。

稀な場合において誤ったデコーディング結果を許容していました。ロジカルレプリケーション対象テーブルへのDDL操作や、サブトランザクション(SAVEPOINT)操作があるときに誤動作を起こすおそれがありました。

これまで、いくつかのサブトランザクションが同期テーブルを更新した後に中止(ABORT)された場合に、テーブル同期が誤った振る舞いをする可能性がありました。

これまでは、作成に失敗したインデックスの OID がリストに残り、同セッション内でその後に問題をひき起こしました。

インデックス作成失敗後に当該テーブルに対するSQL実行で「ERROR: could not open relation with OID 16567」エラーが出るケースが報告されました。

これは 9.4 より前の GINインデックスを pg_upgrade した後にアサート失敗をもたらします。9.4 以降のバージョンで GINインデックスを作った場合には問題ありません。

これは多CPUシステムでの競合を減らし、Linux と FreeBSD での旧リリースと比較しての性能退行を修正します。

これまで、パラレルワーカはインデックスページのロックを待機して止まったままとなる可能性がありました。

破損したBtreeインデックスがここでの無限ループをもたらす可能性があり、その場合、これまでは強制クラッシュさせる以外には割り込み不能となっていました。

本障害により、この最適化が適用できる場合に悪いプランが選択される可能性がありました。

inner_unique最適化とは、PostgreSQL 10 で導入されたユニーク保証を使った最適化の一つで、内部結合に適用されます。

本障害のために、複合列のインデックスがマージ結合に対してそれら列のソート順序を提供するかもしれないことが、見落とされていました。

以下のように複合列のインデックスが使われない動作が報告されました。

（このようなテーブルに対して）
db1=# CREATE TYPE typ20c AS (c1 int, c2 int);
db1=# CREATE TABLE tbl20a (c3 typ20c PRIMARY KEY);
db1=# CREATE TABLE tbl20b (c3 typ20c PRIMARY KEY);
db1=# INSERT INTO tbl20a SELECT ROW(g, g)::typ20c
        FROM generate_series(1, 100000) as g;
db1=# INSERT INTO tbl20b SELECT ROW(g, g)::typ20c
        FROM generate_series(1, 100000) as g;
db1=# ANALYZE;

（以下の問い合わせで Merge Join の場合にインデックスが使われない）
db1=# explain SELECT * FROM tbl20a a, tbl20b b WHERE a.c3 = b.c3;

配列型のパーティションキーを使った場合に、検索におけるパーティション除外（pruning）が働かない動作が報告されていました。

これまではプリペアドステートメントでパラメータとすることができませんでした。

（修正前の動作例、LIMIT/OFFSETでは可能だが FETCH FIRSTはエラーになる）
db1=# PREPARE p1 (int, int) AS
        SELECT * FROM t23 LIMIT $2 OFFSET $1;
PREPARE
db1=# PREPARE p2 (int, int) AS
        SELECT * FROM t23 OFFSET $1 ROWS FETCH FIRST $2 ROWS ONLY;
ERROR:  syntax error at or near "$2"

これまで「PARTITION BY RANGE (x, x)」のように同じ列を複数指定すると「ERROR: column "x" appears more than once in partition key」エラーが生じていました。

これまでは許されていましたが、そのような場合は信頼できる動作をしません。

クエリがパラレル動作をするときに EXPLAIN (ANALYZE,BUFFERS) で出力される「Buffers: ...」値が不正確になる動作が報告されました。

照合順序、符号化方式変換、テキスト検索のオブジェクト名が、スキーマ修飾されるべきケースで修飾されませんでした。

PostgreSQL 10.x 系列においては、パブリケーション、拡張統計のオブジェクトも該当します。また、内部実装関数 getObjectIdentity も修正されています。

これにより、COPYの入力が4G（約42.9億、2の32乗）行を超える場合の二つの問題を回避します。一つは COPY FROM WITH HEADER で先頭行のみならず4G行毎に行が捨てられてしまうことで、一つはエラー報告が誤った行番号を報告する可能性があることです。

シングルユーザモードで「SELECT pg_drop_replication_slot('p');」を実行したときに「ERROR: epoll_ctl() failed: Bad file descriptor」となる動作が報告されました。10.0 で埋め込まれてしまった障害です。

varianceは入力値に対する標本分散を返す集約関数です。

稀な状況で本障害により「LOG: could not generate random cancel key」が繰り返し発生して、新たな接続が受け付けられない状態になり、PostgreSQLをサービス再起動する以外では解消できませんでした。

PQhost() が一部の場合に誤解を招く結果または誤った結果を返していました。これからは一定の様式で応答します。ホスト名が指定されていたならホスト名を、ホストアドレスだけ指定されていた場合に限ってホストアドレスを、いずれも指定されていない場合にはデフォルトホスト名（典型的には /tmp かlocalhost）を返すようになりました。

また、SSL証明書を検証するときに誤った値が証明書のサーバ名と比較されるかもしれませんでした。同様に、誤った値が ~/.pgpass のホスト名欄と比較されるかもしれませんでした。これからは、ホスト名が指定されていたならホスト名、ホストアドレスだけ指定されていたならホストアドレス、いずれも指定されていないなら「localhost」が比較対象の値となります。

また、hostaddr値がパース不能であるとき以下のような不適切な（"(null)"部分）エラーメッセージが報告されていたものが修正されました。

$ psql "hostaddr=999.999.999.999"
psql: could not parse network address "(null)": Name or service not known

また、host、hostaddr、portパラメータにカンマ区切りのリストが含まれる場合、libpq はデフォルト動作指定を意味するリスト内の空要素を注意深く扱うようになりました。

Windows で同じ DLLにて malloc して確保したのではないメモリを free すると、クラッシュが発生することがあります。pgtypesライブラリはときどき呼び出し側が解放する想定の文字列を返しますが、そのように使用することは不可能となっていました。PGTYPESchar_free() 関数が追加され、アプリケーションによる呼び出し側でのメモリ解放が可能となりました。

Windows上の ecpg を使用した DBクライアント実行でクライアント側エラー「unsupported type "long long" on line ...」が出るケースが報告されました。

この障害はアサート失敗をひき起こします。また、稀な場合に INTO STRICTオプションが期待通りに動作しなくなります。

以前の pg_dump出力での search_path や他のリスト値変数のクォーティングに対する修正は、空文字列リスト要素に対して誤動作をしていて、長いファイルパスが切り捨てられる危険性がありました。

手動で作成したユニークインデックスは適切に属性が付与されますが、UNIQUE や PRIMARY KEY 制約を宣言して作られる場合にはそうなりませんでした。

これまでは immediateモードのシャットダウンを誤って正常シャットダウンと判断していました。

以下のように hstore型にならない値を渡すときにクラッシュしていました。

db1=# CREATE EXTENSION hstore;
db1=# CREATE EXTENSION plperl;
db1=# CREATE EXTENSION hstore_plperl;
db1=# CREATE FUNCTION test43() RETURNS hstore LANGUAGE plperl
        TRANSFORM FOR TYPE hstore AS $$ return 43; $$;
db1=# SELECT test43();
server closed the connection unexpectedly

ライブラリ関数で使われる errno変数の退避やリセットが不十分な箇所が修正されました。ユーザに対しては、エラーメッセージ中のエラー理由を示す部分に誤ったメッセージが出力されるという形で問題があらわれます。

これにより、古いPostgreSQLライブラリのあるプラットフォームでビルドするときの問題を回避します。

この更新には、過去のナミビアとチェコスロバキアと同様の、アイルランド夏時間の再定義が含まれます。これらの管区では、法律上標準時間が夏で、冬に変更された時間帯が適用されるため、それにあわせた変更が適用されました。実際のUTCオフセットや使われているタイムゾーン略記法に変更はありませんが、pg_timezone_namesビューのis_dst列の値が変わり、冬にtrue、夏にfalseとなります。

adminpack がインストールされている場合、全てのユーザがログファイルのローテーションをリクエストすることができ、セキュリティ的な問題がありました。

今回のアップデートを適用後、運用管理者は「ALTER EXTENSION adminpack UPDATE;」を実行して adminpack を更新する必要があります。これは adminpack がインストールされているすべてのデータベースが対象となります。(CVE-2018-1115)

以下の関数は VOLATILE とすべきでした。変動する操作を含むかもしれないユーザから与えられた問い合わせを実行するためです。そうなっていなかったためプラン作成での誤った最適化が行われる危険がありました。

query_to_xml
cursor_to_xml
cursor_to_xmlschema
query_to_xmlschema
query_to_xml_and_xmlschema

既存データベースクラスタの関数定義はバージョンアップしただけでは修正されません。使用している各データベースにおいて管理者ユーザにて以下の SQLを実行して、修正することができます。

ALTER FUNCTION pg_catalog.query_to_xml(text, boolean, boolean, text) VOLATILE;
ALTER FUNCTION pg_catalog.cursor_to_xml(refcursor, int, boolean, boolean, text) VOLATILE;
ALTER FUNCTION pg_catalog.cursor_to_xmlschema(refcursor, boolean, boolean, text) VOLATILE;
ALTER FUNCTION pg_catalog.query_to_xmlschema(text, boolean, boolean, text) VOLATILE;
ALTER FUNCTION pg_catalog.query_to_xml_and_xmlschema(text, boolean, boolean, text) VOLATILE;

以下の関数が該当します。

brin_summarize_new_values
brin_summarize_range (10.x のみ)
brin_desummarize_range (10.x のみ)
gin_clean_pending_list
cursor_to_xml
cursor_to_xmlschema
ts_rewrite
ts_stat
binary_upgrade_create_empty_extension
pg_import_system_collations

これらの関数は今まで parallel-restricted とされており予期せぬクエリエラーを発生させる可能性がありました。本修正は新規インストールの場合は問題ないですが、既にインストールされているものに関しては paralle-restricted のままになります。修正のためには、管理者ユーザで以下のように関数の pg_proc エントリを修正するか（全てのデータベースで実行する必要があります）、pg_upgrade を使用して本修正がされているバージョンに変更する必要があります。

（brin_summarize_new_values 関数に対する補正 SQL 例：）
ALTER FUNCTION pg_catalog.brin_summarize_new_values(regclass) PARALLEL UNSAFE;

一度 OID カウンタが周回していると、同じ TOAST テーブルで以前に削除されたエントリと OID が一致する TOAST 値を割り当てる可能性があります。そのエントリが未だ VACUUM されていない場合、以下のエラーがもたらされ、これが削除済みエントリが VACUUM で除去されるまで持続します。

ERROR: unexpected chunk number 0 (expected 1) for toast value nnnnn

新たな TOAST エントリを作るときにそのような OID を選ばないように修正されました。

これまではパーティション化されたテーブル全体にむけて宣言された制約のみが検査されていました。

この誤りにより、パーティションキーにユーザ定義演算子クラスを使うときにクラッシュをひき起こす恐れがありました。

これまでは ANALYZE により実際にはスキャンされないページは、元のタプル密度を維持していると見做されていました。ANALYZE が全体の一部のみサンプリングする大きなテーブルでは、これは全体のタプル密度見積りが大幅に変化しないことを意味し、そのためテーブルの実際の変動にかかわらず、reltuples はテーブルの物理サイズ（relpages）におよそ比例する形で変化しました。これにより、事実上自動 VACUUM が遮断されるほど reltuples が実際より大きくなりすぎる動作がみられました。

ANALYZE で抽出したサンプルが統計的に偏りの無いものと仮定して、観測されたサンプルのタプル密度をテーブル全体に外挿推定するように、修正されました。

また、この個別制御をする INCLUDING STATISTICS オプションが追加されました。

long が 32 ビットのプラットフォーム（大部分の 32 ビットマシンのみならず 64ビット Windows が含まれます）では、コピーされたシーケンスパラメータが 32 ビットに切り捨てされていました。

予期せぬエラー「ERROR: cannot extract system attribute from virtual tuple」が発生する例が報告されていました。

この間違いは、単純なフィルタ条件であるべきときに外部結合に対する結合フィルタ条件の誤まった分別が生じ、誤った結合結果をもたらしました。

以下の誤動作例が報告されました。

db=# CREATE TABLE t AS SELECT 1 AS x, '{10,20}'::int[] AS ys;
db=# SELECT * FROM t
LEFT JOIN (VALUES (1, 10), (2, 20)) AS q1 (x, y) ON q1.x = t.x
LEFT JOIN unnest(ys) q2 (y) ON q2.y = q1.y;
x | ys | x | y | y
---+---------+---+----+----
1 | {10,20} | 1 | 10 | 10
1 | {10,20} | 2 | 20 |
(2 rows)

以下のようなインデックスで該当します。

CREATE INDEX ON text_tbl USING gist (text_col gist_trgm_ops, text_col);
CREATE INDEX ON inet_tbl USING gist (inet_col gist_inet_ops, inet_col inet_ops);

例えば以下のように「制約による除外」の最適化で除外すべきでない子テーブルが除外されてしまうことがあり得ました。

db=# CREATE TABLE cnullp (f1 int);
db=# CREATE TABLE cnullc (check (f1 = 1 OR f1 = null)) INHERITS (cnullp);
db=# INSERT INTO cnullc VALUES (1), (2), (null);
db1=# EXPLAIN SELECT * FROM cnullp ;
QUERY PLAN
----------------------------------------------------------------
Append (cost=0.00..35.50 rows=2551 width=4)
-> Seq Scan on cnullp (cost=0.00..0.00 rows=1 width=4)
-> Seq Scan on cnullc (cost=0.00..35.50 rows=2550 width=4)
(3 rows)

db1=# EXPLAIN SELECT * FROM cnullp WHERE f1 = 2;
QUERY PLAN
------------------------------------------------------------
Append (cost=0.00..0.00 rows=1 width=4)
-> Seq Scan on cnullp (cost=0.00..0.00 rows=1 width=4)
Filter: (f1 = 2)
(3 rows)

(大小比較ができないのでソート不能な xid 型によるクラッシュをひき起こす SQL 例)
db=# CREATE TABLE t18 (id int, x1 xid, x2 xid);
db=# INSERT INTO t18 VALUES (1, '1', '1'), (2, '2', '2'), (3,'3','3');
db=# SELECT x1, x2, count(*) FROM t18 GROUP BY GROUPING SETS ((x1), (x2));

UNION で遷移テーブルへの SELECT を繋ぐ場合なども該当します。

これは一部タプルがロックされている（しかし削除されていない）場合に起きる可能性がありました。問い合わせが未だ正しく実行中の間、VACUUM は通常そのようなページを無視します。これはタプルがずっと凍結されないという長期の影響を伴います。

最近のリリースでは、これによりエラー「ERROR: found multixact nnnnn from before relminmxid nnnnn」を出しました。

これは pg_upgrade で 9.2 以前のバージョンからアップグレードされたデータベースにて、誤った「ERROR: cannot freeze committed xmax ...」エラーをひき起こしました。

これまでの振る舞いは多テーブルデータベースにおいて潜在的なワーカの同時実行性を大幅に削いでいました。

これまでは、ローカルとされるスナップショットが共有メモリへのポインタを含んでおり、いずれかの存在するセッションが切断された場合に client_hostname が予期せず変わることがあり得ました。

各種補助プロセス（autovacuum launcher や background writer など）に対する application_name、client_hostname、query 属性が正しくないデータを見せる可能性がありました。

未初期化メモリアクセスが生じていました。

C ロケール以外の場合に該当する検索では誤った行が選択されました。マルチバイト文字でも影響があります。

（報告された例）
db=# CREATE TABLE t32 (a text collate "cs_CZ");
db=# INSERT INTO t32 VALUES ('c'), ('ch'); -- チェコ語では ch で１文字
db=# SELECT * FROM t32 where a < 'd';
a
----
c
(1 row)

db=# CREATE INDEX ON t32 USING spgist (a);
db=# SET enable_seqscan TO off;
db=# SELECT * FROM t32 where a < 'd';
a
----
c
ch
(2 rows)

これまで、タプル数はインデックス対象のテーブルと同じと報告されていましたが、これは部分インデックスの場合には誤りでした。

これまではヒープタプルの見積数を返していました。それは単なる推測であり、間違っている場合もありましたし、インデックスが部分的なものである場合は必ず間違っていました。

今までは XLogPageRead() が既に読み込みを終えた部分であったとしても、WAL の最初からストリーミングレプリケーションを再開していました。これにより稀にストリーミングレプリケーションが止まってしまう現象が生じました。

walsender が $PGDATA/pg_replslot 内にデータを残した状態で終了してしまった場合、次の walsender がそこに残ったデータを捨てることなく開始して、データが重複する可能性がありました。

リモートのものをローカルのものとして使用しており、「ERROR: cache lookup failed for type XYZ」エラー、もしくはランダムに意図していないものが選択される可能性がありました。

ユーザ定義の数値データ型で予期せぬ「ERROR: unsupported type: nnnnn」が生じることが報告されました。

エラーメッセージをパース後にクエリ結果を捨てていましたが、事前に捨てるようになりました。その結果メモリ消費量を抑え out-of-memory になる危険性が軽減されました。

pg_dump の結果で local_preload_libraries、session_preload_libraries、shared_preload_libraries と temp_tablespaces 変数に対するクォーテーションの付け方が間違っていました。もしもこれらの設定が CREATE FUNCTION ... SET や ALTER DATABASE/ROLE ... SET にある場合に問題になる可能性がありました。

前回のリリースにて変更された search_path へのプロテクトが追加されていましたが、10 より前のバージョンではレプリケーション接続で SQL を受け付けないため有効でなく、構文エラーが発生する可能性がありました。

失敗していた場合、ターゲットサーバがデータ不整合に陥っていました。

以前のコードではいくつかの GCC 以外のコンパイラではオーバーフローが検知されず、無限ループに陥っていました。

インデックス内のタプル数を推測でなく確実にカウントすることで最後のタプルが取りこぼされる可能性がなくなりました。

b64_encode は pg_base64_encode に、b64_decode は pg_base64_decode に名前変更されました。

これは zic タイムゾーンデータコンパイラが負の夏時間オフセットで動作するように修正します。PostgreSQL はこのようなタイムゾーンデータに直ちには対応しませんが、zic を IANA から直接取得したタイムゾーンデータで使う可能性がありますので、確実を期してアップデートされました。

パレスチナと南極（ケーシー基地）の DST 法の変更、ポルトガルとその植民地、エンダーベリー島、ジャマイカ、タークス・カイコス諸島、ウルグアイの歴史的修正が加えられています。

以前のリリースでも修正が行われていましたが、修正もれがありました。

害意あるユーザから書き込み可能なスキーマを含む search_path 設定を使うことは、そのユーザが問い合わせの制御を取ること、そして、攻撃されたユーザの権限で任意の SQL コードを実行することをきわめて容易に可能にします。

そのため、search_path に信用できないスキーマを含めないようにすることが推奨されます。ドキュメントのスキーマ、libpq、拡張および CREATE FUNCTION の各ページについて記載を改定しました。

特に public スキーマはデフォルトで存在し、デフォルトで search_path に含まれており、全てのユーザでスキーマ上でオブジェクト作成が可能となっています。同じデータベースにアクセスする信用できない（本来制限されている）ユーザがいて、それでいて public スキーマと search_path 設定がデフォルト状態のままである場合には明らかに本脆弱性に該当します。(CVE-2018-1058)

pg_dump、pg_upgrade、vacuumdb、およびその他各種の PostgreSQLで提供されるクライアントプログラム自体に前項で記載した類のハイジャックに対する脆弱性がありました。これらプログラムはたいてい管理者ユーザで実行されるので狙われやすいターゲットです。これらを安全にするため、動作時の search_path 設定に pg_catalog スキーマだけ含まれるようになりました。また、autovacuum worker も同様に動作するようになりました。なお、pgbench と psql は本修正の対象外です。

これは非互換箇所のある修正です。これらのプログラムから間接的に実行されるユーザ定義関数（例えばインデックス式の関数）が search_path 設定に依存して記述されている（例えば public スキーマ下の関数をスキーマ修飾無しに参照している）場合、エラーが生じるようになります。(CVE-2018-1058)

FOR ALL TABLES と指定されたパブリケーションが誤ってマテリアライズドビューや information_schema テーブルの変更を伝播していました。これらは変更ストリームから無視されるべきものです。

CTE（WITH 句参照）が InitPlan や SubPlan で使われていて、問い合わせが同時更新された行に更新やロックをするために再チェックを必要とする場合に、誤った結果が返ることがありました。

コードの誤りにより稀なケースで「ERROR: left and right pathkeys do not match in mergejoin」や「ERROR: outer pathkeys do not match mergeclauses planner」といったエラーが生じていました。

（10.2 でのエラーが発生する SQL を実行）
test=# EXPLAIN (COSTS off)
SELECT * FROM j1 FULL OUTER JOIN
(SELECT * FROM j2 ORDER BY j2.id DESC, j2.num asc) j2
ON j1.id = j2.id AND j1.id = j2.num;
ERROR: left and right pathkeys do not match in mergejoin

（10.3 での応答）
QUERY PLAN
------------------------------------------------------
Merge Full Join
Merge Cond: ((j2.id = j1.id) AND (j2.num = j1.id))
-> Sort
Sort Key: j2.id DESC, j2.num
-> Seq Scan on j2
-> Sort
Sort Key: j1.id DESC
-> Seq Scan on j1
(8 rows)

アップグレード後にマテリアライズドビューのデータが破損する可能性がありました。「ERROR: could not access status of transaction ...」や「ERROR: found xmin ... from before relfrozenxid ...」というエラーが現れます。

この問題は、めったに更新されない、もしくは REFRESH MATERIALIZED VIEW CONCURRENTLY のみで更新をしていたマテリアライズドビューで発生しやすいものと見られます。

シーケンスの MAXVALUE や MINVALUE がデフォルト値であるなら、ダンプ出力で省略しますが、その判断が間違っていました。

大きな値を指定した場合に以下のような誤動作が報告されました。

（誤動作例）
db=# CREATE SEQUENCE foo INCREMENT BY -1
MINVALUE -9223372036854775808 MAXVALUE 9223372036854775807;
db=# q
$ pg_dump db
: 中略
CREATE SEQUENCE foo
START WITH 9223372036854775807
INCREMENT BY -1
NO MINVALUE
NO MAXVALUE
CACHE 1;
: 後略

拡張統計のオブジェクトが正しいスキーマにリストアされなかったり所有者が正しくない状態になる可能性がありました。

以下のように入れ子で PL/Python を呼び出している場合において該当します。

(障害がおきる例)
db=# CREATE FUNCTION notice_innerfunc() RETURNS int AS $$
plpy.execute("DO LANGUAGE plpythonu $x$ plpy.notice('inside DO') $x$")
return 1
$$ LANGUAGE plpythonu;

db=# CREATE FUNCTION notice_outerfunc() RETURNS int AS $$
plpy.execute("SELECT notice_innerfunc()")
return 1
$$ LANGUAGE plpythonu;

また、入れ子になった PL/Python の DO ブロックは一部のプラットフォームで NULL ポインタ参照によるクラッシュをひき起こす可能性がありました。

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

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

他の関連する 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 が有効なテーブルでのみ発生します。

これまでの実装では、外部サーバオブジェクト所有者やサーバの USAGE 権限を付与されたユーザが、そのサーバに関連する全ユーザマッピングのオプションを見ることができました。これには他ユーザのパスワードもしっかり含まれているかもしれません。

そこで、information_schema.user_mapping_options と振る舞いが一致するように pg_user_mappings ビューの定義が修正されました。すなわち、マップされているユーザであるか、PUBLIC へのマッピングで現在ユーザがサーバの所有者である、あるいは、現在ユーザがスーパーユーザのときに、ユーザマッピングオプションが見えるようになります。(CVE-2017-7486)

本パッチでは、新たに initdb で作成されたデータベースクラスタについてのみ振る舞いを変更します。既存データベースクラスタに対して変更を適用するには、以下の手順を実施する必要があります。

(1)

postgresql.conf に「allow_system_table_mods = true」を加えた後、PostgreSQL サービス (postmaster) を再起動します (ALTER SYSTEM をサポートするバージョンであれば、それを使うこともできますが、いずれにせよ再起動は必要です)。

データベースクラスタ内の各データベースで以下のコマンドをスーパーユーザで実行します。

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)
                    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);

(2)

template0 と template1 に対しても対処が必要です。さもなくば後に新たに作ったデータベースには脆弱性が依然として存在することになります。template0 を修正するには、一時的に template0 を接続可能にする必要があります。

PostgreSQL 9.5 以降では以下のコマンドが利用できます。

template0 を接続可能にする：
ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;

template0 を接続不能に戻す：
ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;

より古いバージョンでは代替に以下コマンドを使います。

template0 を接続可能にする：
UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';

template0 を接続不能に戻す：
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';

(3)

最後に allow_system_table_mods 設定を除去して、PostgreSQL サービス (postmaster) をもう一度再起動します。

いくつかのプランナの選択率見積り関数は、最頻値やヒストグラムの登録値など、pg_statistic から得られる値に対してユーザ定義演算子を適用します。この動作はテーブル権限が検査される前に生じるので、悪意のユーザが本来参照が許されていないテーブル列の値を取得するために、この振る舞いを悪用するおそれがありました。この対策として、演算子の実装関数が情報を漏らさないことが確実（LEAKPROOF属性が真）でなく、呼び出しているユーザが統計情報を必要とするテーブル列の読み取り権限を持っていない場合には、デフォルトの見積で代用するようになりました。実用上たいていのケースで、これら基準のうち少なくとも一つを満たします。(CVE-2017-7484)

この環境変数の処理が PostgreSQL 9.3 で意図せず欠落していましたが、ドキュメントには残っていました。ユーザが SSL 暗号化接続を強制させるために、機能しなくなっていた本環境変数を頼っているかもしれないため、セキュリティ上の危険が生じます。

PGREQUIRESSL 環境変数の処理が復旧されました。しかし、9.3 以降で正しく動作していた設定を壊さないようにするため、PGSSLMODE よりも低い優先順位で扱われます。(CVE-2017-7485)

ロジカルデコーディングのレプリケーションスロットむけに作られた初期スナップショットは不正なものである可能性がありました。これは、ロジカルデコーディングを使うサードパーティツールが不完全あるいは一貫性に欠ける初期データをコピーする原因となります。スロットを作るときにソースサーバが忙しい場合や、他のロジカルスロットが既に在った場合に発生しやすい動作です。

ロジカルデコーディングに依存したレプリケーションツールを使っていて、それがレプリケーション開始時に空でないデータセットをコピーするのであれば、本アップデート導入後にレプリカを再作成するか、ソースサーバと比較してデータ検証することを推奨します。

クラッシュと再起動の後に、無効な状態にセットされている UNLOGGED インデックスがもたらされる恐れがありました。この問題はインデックスを削除して再作成するまで持続します。

たいていの場合、これは目に見える悪影響を及ぼしませんが、稀な場合に pg_subtrans の循環参照をもたらし、2 相トランザクションにより変更された行を検査する問い合わせで無限ループをひき起こす可能性があります。

2 つ以上のワーカープロセスに向けた問い合わせの要求を満たす前に、あるいは複数問い合わせが同時にワーカーへ要求されたときに、著しい遅延(数十秒)が生じる可能性がありました。本現象は多くのプラットフォームでは不運なタイミングでのみ発生しますが、一部プラットフォームではよくあるケースです。

これまでは、プロセスが正常に起動されたかのようにワーカ状態の一部を更新していて、その後に混乱をひき起こしていました。

(障害が発生する SQL の例)
db1=# (SELECT 1,2,3 UNION SELECT 4,5,6 ORDER BY 1,2) INTERSECT SELECT 4,5,6;
ERROR:  no relation entry for relid 0

プラン選択が不適切になる場合がありえました。

この最適化はタプルの全ての列を取得するのが低コストでできることを想定しています。通常タプルにおいてはこれは真ですが、カスタムスキャンプロバイダーに対してはそうでないかもしれません。

一部ケースで USING 制約がより適切であるときに WITH CHECK 制約が適用されました。

修正前ではポリシーに反する値への更新、および更新後の値の返却が可能でした。以下例は修正後はエラーとなります。

(誤動作例)
db1=# CREATE POLICY alice_policy ON t TO alice
        USING (value > 0) WITH CHECK (true);
db1=# SET session authorization alice;
db1=# SELECT * FROM t;
 value
-------
    1
(1 rows)

db1=# UPDATE t SET value = value * -1 WHERE value = 1 RETURNING *;
 value
-------
   -1
(1 row)

UPDATE 1

拡張モジュールのスクリプトファイルのコマンド間では、キャッシュを更新する手順が欠けているので、ALTER TABLE ... RENAME ... などの DDLコマンドに続くDMLコマンドは直前の定義変更に気づかないかもしれませんでした。

(例：以下のスクリプトで最後の UPDATE が失敗する可能性がありました)

CREATE TABLE xxx_ext_table (col_old INT);
ALTER TABLE xxx_ext_table RENAME col_old TO col_new;
UPDATE xxx_ext_table SET col_new = 0;

本コマンドは、実行ユーザがその時点でインデックスが置かれているテーブルスペースに CREATE 権限を持っていないと失敗していました。この振る舞いは役に立たないと考えられ、検査を省略し、この場合にはインデックスを再構築できるようにしました。

この修正は、子テーブルに一致する制約が存在しないときに望まれない「ERROR: constraint does not exist」が生じるのを防ぎます。

通常は無害ですが、ときどき予期せぬエラーやクラッシュをひき起こしていました。

運が悪いとき、本障害は対象テーブルのインデックスの誤った永続性設定 (UNLOGGEDか、TEMPORARYか、等) での再構築をひき起こす可能性がありました。

この障害により、テーブルタプル数の過小見積が生じがちでした。競合の多い小さいテーブルという最悪ケースでは、VACUUM がテーブルは0行であると誤って報告する可能性があり、非常に悪いプラン選択をもたらしました。

ハッシュ結合でキャンセルがすぐには効かない挙動が報告されていました。

&<、&>、&<|、および、|&> 演算子を使う SP-GiST インデックススキャンは、誤った応答をもたらしていました。要素が接している場合の判定に影響があります。

およそ 296000 年以上の時間間隔の場合に interval 型の比較演算子が誤った応答を返すおそれがありました。このような大きい値が含むカラムのインデックスは、インデックス内容が不正であるかもしれないので、バージョンアップ後にインデックス再作成すべきです。

64bit 整数の日付時刻を使う方式(デフォルト)でビルドした場合に該当します。

これまでは、<table> 要素で括られず、<row> 要素の並びだけが出力されていました。

(誤った出力例)
db1=# DECLARE c CURSOR WITH HOLD FOR SELECT * FROM t1;
db1=# SELECT cursor_to_xml('c'::refcursor, 2, true, true, '');
                        cursor_to_xml
-------------------------------------------------------------
 <row xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">+
   <id>1</id>                                               +
   <v>c4ca4238a0b923820dcc509a6f75849b</v>                  +
 </row>                                                     +
                                                            +
 <row xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">+
   <id>2</id>                                               +
   <v>c81e728d9d4c2f636f067f89cc14862c</v>                  +
 </row>                                                     +
                                                            +

これら関数は、浮動小数点の値から整数のマイクロ秒に変換するときに、丸めでなく、切り捨てを行っていました。これにより予期せぬ境界条件エラーをひき起こすおそれがありました。

切捨てでなく C 言語関数 rint (最も近い整数値への丸め) を使うように実装が修正されました。

非排他バックアップが終了するのを待つ間に pg_stop_backup() 関数がキャンセルされた場合、関連する状態が不整合状態になり、新たな非排他バックアップを開始できない可能性がありました。また、その他の細かな問題もありました。

どちらも通常ではあまり失敗しないシステムコールですが、失敗した場合にはかなり混乱するおそれがありました。

本障害はアクセス不能であるときにイベントログに書き出しを試みて、全くログが書かれない結果をひき起こしました。

起こりうるのは ecpg コマンドのクラッシュです。

他のスキーマは権限が与えられない状態から始まりますが、public スキーマはそうではありません。--clean オプションのために削除とリストアを行うときには特別な対応が必要でした。

単純な使い方の場合には悪影響はありませんが、スキーマを指定したリストアで含まれるべきコメントが無視される可能性がありました。これはダンプ時にそれらが関連するオブジェクトのスキーマに属するという印付けがされなかったためです。

本障害により pg_dump は常に手続き言語は初期権限を持たないとみなしていました。ほとんどの手続き言語は実際のところそうであるため、本障害による悪影響はおそらく稀です。

これまでもラージオブジェクトは新データベースに正しく移行されていましたが、付加されたコメントとセキュリティラベルが失われていました。

特に fclose() で報告されたエラーを検知できていませんでした。

一部のケースで何にもマッチできない壊れたデータ構造が生み出され、トリグラムインデックスを使う GIN または GiST のインデックススキャンが正規表現へのマッチを何も見つけられない結果（誤った応答）になります。

(誤動作例：pg_trgm インデックスを使うと結果が 0 件になってしまう)
db1=# CREATE TABLE ttrig (id int primary key, txt text);
db1=# INSERT INTO ttrig SELECT g, md5(g::text) FROM generate_series(1, 10000) g;
db1=# SELECT count(*) FROM ttrig WHERE txt ~ '[ab]{2}-?[ab]{2}';
 count
-------
    55
(1 row)

db1=# CREATE INDEX trgm_idx ON ttrig USING gist (txt gist_trgm_ops);
db1=# SELECT count(*) FROM ttrig WHERE txt ~ '[ab]{2}-?[ab]{2}';
 count
-------
     0
(1 row)

2038 年 1 月の夏時間の遷移に影響を及ぼすバグが修正されています。

チリ、ハイチ、モンゴルの夏時間法の変更、エクアドル、カザフスタン、リベリア、スペインの歴史的修正が含まれます。南米、太平洋、インド洋、および、一部アジア・中東の国々における多数のタイムゾーンが、数字による省略形に切り替えられました。

IANA タイムゾーンデータベースはこれまで文字による省略形を全てのタイムゾーンに提供していて、ときに地元住民の間でほとんどあるいは全く使われない省略形を作成していました。IANA は英語の省略形が現実に使われている形跡がないゾーンにおいては UTC オフセット数値を使うことを選ぶという方針に転換しようとしてるところです。少なくともしばらくの間、PostgreSQL はタイムスタンプの入力に、このような削除された省略形を引き続き受け入れます。しかし、それらは pg_timezone_names ビューには現れず、出力にも使用されなくなります。

Microsoft の MSVC ビルドスクリプトは posixrules ファイルをタイムゾーンディレクトリツリーにインストールするのを怠っていました。この結果、POSIX 形式のタイムゾーン名に対し想定される夏時間の振る舞いについて、タイムゾーンコードがビルトインの規則に戻ってしまっていました。

歴史的な理由により、その組み込み規則は、米国が2007年より前に使っていた夏時間規則（すなわち、4月最初の日曜日と 10月最終の日曜日の変更）に引き続き対応しています。この修正にともない、POSIX 形式のゾーン名は US/Eastern ゾーンの現在および歴史的夏時間遷移日を使います。そのようにしたくない場合には、posixrules ファイルを削除するか、他のゾーンファイルのコピーで置き換えてください。変更を反映させるにはサーバ (サービス) の再起動が必要です。

たとえば xid 型がハッシュ可能でソート不能です。

これまではローカルでの問い合わせキャンセル要求が、既に送ったリモート問い合わせを早く終わらせることはありませんでした。これは 9.6 で修正された内容のバックポートです。

9.5 以降のバージョン系列で既に対応している内容のバックポートです。多数のプラットフォームが新たな OpenSSL バージョンを取り込みつつあるので、必要となりました。