害意あるユーザから書き込み可能なスキーマを含む 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 の別名にすぎません）。