ある種の攻撃方法で 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 法の変更、ポルトガルとその植民地、エンダーベリー島、ジャマイカ、タークス・カイコス諸島、ウルグアイの歴史的修正が加えられています。

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