E.37. リリース9.3.14

E.37.1. バージョン9.3.14への移行

9.3.Xからの移行ではダンプ/リストアは不要です。

また、9.3.9よりも前のバージョンからアップグレードする場合には、項E.42を参照してください。

E.37.2. 変更点

• 入れ子になったCASE-WHEN式誤評価のおそれがあり、 修正されました。 (Heikki Linnakangas, Michael Paquier, Tom Lane)

  他のCASEのテスト値の副式内に現れるCASE式が、 自身のテスト値がnullであるかどうかを取り違える可能性がありました。 そのうえ、CASE式で使われている等価演算子を実装しているSQL関数のインライン化が、SQL関数本体でCASE式内で呼ばれる関数に誤ったテスト値を渡す原因となる可能性がありました。 テスト値が異なるデータ型の場合にはクラッシュに至るおそれがあり、さらにそのような状況をサーバメモリの一部を暴露できるように悪用されるおそれがありました。 (CVE-2016-5423)

• データベース名とロール名についてクライアントプログラムの特殊文字の扱いを修正しました。 (Noah Misch, Nathan Bossart, Michael Paquier)

  vacuumdb他、各種クライアントプログラムの多数の箇所が、ダブルクオートやバックスラッシュを含むデータベース名やロール名で混乱するおそれがありました。 これを安全にするためクオート規則を厳格にしました。 そのうえ、conninfo文字列がこれらプログラムむけにデータベース名パラメータとして使われている場合に、全て確実にそのように正しく扱われるようにしました。

  psqlの\connectコマンド、\passwordコマンドにて、二つ組ダブルクオートの扱いをドキュメントと一致するように修正しました。

  psqlの\connectコマンドに、前接続から接続パラメータを再利用するかを明示的に制御できる新たなオプション-reuse-previousを導入しました。 （これが無い場合は従来通りデータベース名がconninfo文字列とみられるかで判断されます。） これにより、pg_dumpallスクリプトで特殊文字が含まれるデータベース名の安全な取り扱いが可能になります。

  改行・復帰の文字をWindowsで安全にクオートするのは現実的と見られないため、これからはpg_dumpallはこれら文字を含むデータベース名、ロール名の処理を拒絶します。 将来このような名前をサーバ側で拒絶するかもしれませんが、その処置は未だ取られていません。

  特殊文字を含む作りこまれたオブジェクト名が、次回のpg_dumpallなどの定期メンテナンス操作にてスーパーユーザ権限でコマンドを実行させるために使われるかもしれないため、これらはセキュリティ修正とみなされます。 (CVE-2016-5424)

• 入れ子になった複合値に適用されるIS NULL/IS NOT NULLの、稀な場合の誤動作を修正しました。 (Andrew Gierth, Tom Lane)

  SQL標準は全てNULL値の行にはIS NULLはTRUEを返すべきと明記しています（従ってROW(NULL,NULL) IS NULLはTRUE）。 しかし、これは再帰的に適用されることを意味しません（従ってROW(NULL, ROW(NULL,NULL)) IS NULLはFALSE）。 中核となるエグゼキュータではこれを正しく実現していますが、ある種のプランナ最適化がこのテストを再帰的に扱っていました（そのため両ケースでTRUEになる）。 また、contrib/postgres_fdwがリモート問い合わせで同様の誤動作をする可能性がありました。

• 多すぎるコロン区切りフィールドを持つIPv6アドレスをinet、cidrデータ型が適切に拒絶するようにしました。 (Tom Lane)

• NaN入力座標に対してclose_ps()（point ## lseg演算子）でのクラッシュを防止しました。 (Tom Lane)

  クラッシュするのでなくNULLを返すようにしました。

• 一貫性に欠けた値が渡された場合に起こりうるpg_get_expr()でのクラッシュを回避しました。 (Michael Paquier, Thomas Munro)

• to_number()でのいくつかの1バイトのバッファ超過読み込みを修正しました。 (Peter Eisentraut)

  いくつかの場合にto_number()関数が入力文字列から本来よりも1文字多く読んでいました。 入力文字列がたまたまメモリ末尾に配置された場合には、クラッシュする小さな可能性があります。

• CREATE MATERIALIZED VIEWまたはCREATE TABLE ASに 含まれる問い合わせは、WITH NO DATAが指定されているとき、プランナを実行しないようにしました。 (Michael Paquier, Tom Lane)

  これは、例えばマテリアライズドビューから呼び出されるSTABLE関数が未だ存在していないテーブルに依存している場合など、不要な失敗条件を回避します。

• heap_update()を通る高価な処理パスの間の安全でない中間状態を回避しました。 (Masahiko Sawada, Andres Freund)

  これまで、これらの場合は対象タプルを（XMAXをセットすることで）ロックしていましたが、その動作をWAL記録していませんでした。 したがって、ページがディスクに溢れて、それからタプル更新が完了する前にデータベースクラッシュが起きたとき、データ一貫性問題の危険がありました。

• 行ロック操作のWAL再生中のヒントビット更新を修正しました。 (Andres Freund)

  知られている本問題の影響は、準備されているけれどコミットされていないトランザクションにより保持された行ロックが、クラッシュと再起動の後に適用に失敗するかもしれないことだけです。

• シリアライザブルモードでFOR KEY SHARE行ロックを取得するときの不要な"could not serialize access"（「直列化アクセスができませんでした」）エラーを回避しました。 (Álvaro Herrera)

• 指定された変数がNULL文字列値を持っているときに、postgres -Cでのクラッシュを回避しました。 (Michael Paquier)

• バックエンドが共有カタログの最新の統計を確実に見るようにしました。 (Tom Lane)

  統計情報コレクタは通常のバックエンドからの要求の後、共有カタログについて統計ファイルを更新するのに失敗していました。 自動バキュームランチャーが定常的に要求するため、この問題は部分的に隠されていましたが、自動VACUUMを無効にすると顕在化しました。

• 複数バックエンドがほぼ同時に更新を要求したときの統計ファイルの冗長な書き込みを回避しました。 (Tom Lane, Tomas Vondra)

• VACUUMの間のトランザクションIDの消費を回避しました。 (Alexander Korotkov)

  VACUUMは一部ケースで現在トランザクションへの不要なXID割り当てを引き起こしていました。 通常これは無視してよいものですが、XID周回限度に直面していたなら、周回対策のバキュームの間にさらにXIDを消費することは、甚だ悪い事態です。

• VACUUM FREEZE中にはホットスタンバイの問い合わせのキャンセルを防ぎます (Simon Riggs, Álvaro Herrera)

  そうでなければアイドル状態のマスタサーバ上でVACUUM FREEZEが動作すると、スタンバイサーバ上の問い合わせを不必要にキャンセルする可能性がありました。

• 9.3より前のバージョンからpg_upgradeを適用したクラスタにおいて、マルチトランザクションIDをバキュームするとき起こりうる失敗を防止しました。 (Andrew Gierth, Álvaro Herrera)

  この障害のよくある症状は"MultiXactId NNN has not been created yet -- apparent wraparound"（「マルチトランザクションID NNNは未だ作られていません、周回しているようです」）といったエラーです。

• 手動ANALYZEでカラムリストを指定するとき、テーブルのchanges_since_analyzeカウンタをリセットしないようにしました。 (Tom Lane)

  私たちが一部カラムだけをアナライズするとき、他のカラムむけに定常的な自動アナライズが行われるのを妨げるべきではありません。

• ユニークもしくはほぼユニークでNULL要素を多数持つカラムに対して、ANALYZEのn_distinctの過剰見積もりを修正しました。 (Tom Lane)

  NULLが互いに異なる値であるかのように数えられることがあり、いくつかの類型の問い合わせで深刻なプランナの見積もり誤りをもたらしていました。

• 自動VACUUMが複数のワーカを同じ共有カタログのために起動するのを防止しました。 (Álvaro Herrera)

  通常このバキュームは何にせよ長時間を要さないため、大した問題にはなりません。 しかし、ひどく肥大化したカタログの場合、一つを除く全てのワーカが他のテーブルに有益な仕事をする代わりに無駄に待つという結果になりかねません。

• NaNの要素値を含む幾何カラムに対するGiSTインデックス構築で、無限ループを防止しました。 (Tom Lane)

• contrib/btree_ginがありうる最小のbigint値を正しく扱えるように修正しました。 (Peter Eisentraut)

• libpqが将来のサーバから正しくサーババージョンを解釈するようにしました。 (Peter Eisentraut)

  9.6の次のリリースから3パートのバージョン番号に代えて、2パートのバージョン番号に切り替えることが計画されています。 このような場合にPQserverVersion()が正しい値を返すことを保証しました。

• ecpgのunsigned long long配列要素むけコードを修正しました。 (Michael Meskes)

• pg_dumpで-c、-Cの両オプションを伴う場合に、求められていないCREATE SCHEMA publicコマンドの出力を回避しました。 (David Johnston, Tom Lane)

• パラレルのpg_dumpおよびpg_restoreでSIGTERM/control-Cの扱いを改善しました。 (Tom Lane)

  これらがCREATE INDEXなどの何らか長い実行をしている場合に、ワーカプロセスが必ず速やかに終了し、接続されているバックエンドへの問い合わせキャンセル要求を送信するようにしました。

• パラレルのpg_dumpとpg_restoreにてエラー報告を修正しました。 (Tom Lane)

  これまでは、pg_dumpやpg_restoreのワーカプロセスからのエラーメッセージがユーザのコンソールに出力されないことがありました。 メッセージはマスタプロセスを通して伝達され、マスタプロセスのメッセージ伝搬を妨げるいくつかデッドロックするシナリオがあったためです。 代わりとして単純にstderrにすべてを出力します。 いくつかのケースでは重複するメッセージが出力されることになります（例えばすべてのワーカがサーバシャットダウンを報告します）。 しかし、メッセージが無いよりは良いと思われます。

• パラレルのpg_dumpまたはpg_restoreがWindows上でエラー後に速やかに終了することを保証しました。 (Kyotaro Horiguchi)

  これまではエラーを報告しますがユーザにより手動で停止されるまで単に止まっていました。

• zlibサポート無しでビルドしたときに、pg_dumpがよりよく振る舞うようにしました。 (Kyotaro Horiguchi)

  パラレルダンプを正しく処理できず、他の場合でもいくつかのやや見当はずれな警告を出していました。

• pg_basebackupが圧縮無しの指定として-Z 0を受け付けるようにしました。 (Fujii Masao)

• AIXの共有ライブラリをビルドするMakefileのルールをパラレルmakeで安全になるように修正しました。 (Noah Misch)

• ビルドディレクトリのパス名が空白文字を含むとき動作するように、TAPテストとMSVCスクリプトを修正しました。 (Michael Paquier, Kyotaro Horiguchi)

• "lock timeout"に対して"statement timeout"の報告について、より予測可能にしました。 (Tom Lane)

  負荷の重いマシンでは、ステートメントタイムアウトが先に発生したはずであるのに、"lock timeout"の報告のためにリグレッションテストがしばしば失敗していました。

• デンマーク語、ウェールズ語のロケールについてリグレッションテストを安全にしました。 (Jeff Janes, Tom Lane)

  これらのロケールの通常と違ったソート規則を働かせる一部データを変更しました。

• タイムゾーンコードのコピーをIANAのtzcode release 2016cに適合するように更新しました。 (Tom Lane)

  これはタイムゾーンデータファイルの予測される将来の変更に対応するために必要です。 また、通常と異なるタイムゾーンに対応して、いくつかの稀な場合のバグを修正しています。

• タイムゾーンデータファイルをtzdata release 2016fに更新しました。 ケメロヴォとノヴォシビルスクの夏時間の変更、アゼルバイジャン、ベラルーシ、およびモロッコの歴史的な修正が含まれます。