リリース日: 2018-03-01
このリリースは9.3.21に対し、各種不具合を修正したものです。 9.3メジャーリリースにおける新機能については、E.77を参照してください。
9.3.Xからの移行ではダンプ/リストアは不要です。
しかしながら、全てのユーザが相互に信頼できるのでないインストレーションを運用しているのであれば、あるいは、任意の状況で使われる想定のアプリケーションや拡張を保守しているなら、下記の変更履歴の1番目で述べている文書の変更箇所を読み、あなたのインストレーションやコードの安全を確実にする適切な手順を行うことを強く推奨します。
また、下記変更履歴の2番目の項目で述べられている変更点は、インデックス式やマテリアライズドビューで使われている関数が、自動アナライズやダンプからの再ロードでの失敗をひき起こすかもしれません。 アップグレード後、これらの問題むけにサーバログを監視して、影響を受ける関数を修正してください。
また、9.3.18よりも前のバージョンからアップグレードする場合には、E.59を参照してください。
サーチパス依存のトロイの木馬攻撃に対して防御するためのインストレーションとアプリケーションの設定方法を文書記載しました。 (Noah Misch)
敵意のあるユーザから書き込み可能な何らかのスキーマを含むsearch_path設定を使うことは、そのユーザが問い合わせの制御を奪い、攻撃を受けたユーザの権限で任意のSQLコードを実行することを可能にします。
このようなハイジャックを防ぐような問い合わせを書くことは可能ですが、これは甚だ退屈で、とても見落としをしやすいです。
そこで、私たちは信用できないスキーマがユーザのサーチパスに現れない設定を推奨します。
関連する文書は、5.8.6（データベースの管理者・ユーザむけ）、33.1（アプリケーションの作者むけ）、37.15.1（拡張の作者むけ）、CREATE FUNCTION（SECURITY DEFINER関数の作者むけ）にあります。
(CVE-2018-1058)
pg_dumpと他のクライアントプログラムで安全でないsearch_path設定の使用を回避しました。
(Noah Misch, Tom Lane)
pg_dump、pg_upgrade、vacuumdb、および他のPostgreSQLで提供されるアプリケーションは、それら自身に一つ前の変更点項目に記載された種類のハイジャックの脆弱性がありました。
これらのアプリケーションは一般にスーパーユーザで実行されるので、特に魅力的なターゲットとなっています。
インストレーション全体が安全であったか否かによらず、これらを安全にするためsearch_path設定にpg_catalogスキーマのみを含むように変更しました。
自動バキュームワーカプロセスもこれからは同様に動作します。
ユーザ作成関数が間接的にこれらプログラムから実行される場合 — 例えばインデックス式のユーザ作成関数 — では、より制限されたsearch_pathはエラーを起こすかもしれません。
これらのユーザ作成関数は、実行されるサーチパスに関していかなる想定もしないように調整することによって修正する必要があります。
このことはいつでも良い習慣でしたが、これからは正しい動作のために不可欠となります。
(CVE-2018-1058)
サブプランに現れるCTE参照で同時更新の再チェックの誤動作を修正しました。 (Tom Lane)
InitPlanかSubPlanでCTE（WITH句参照）が使われていて、その問い合わせが同時更新された行の更新やロックを試みるために再チェックを要する場合、誤った結果が得られることがありえました。
外部結合での重複しているマージ結合句でのプランナのエラーを修正しました。 (Tom Lane)
これらの誤りは稀な場合に「left and right pathkeys do not match in mergejoin（マージ結合で左右のパスキーが不一致）」あるいは「outer pathkeys do not match mergeclauses（外側パスキーがマージ句と不一致）」というプランナエラーをひき起こします。
pg_upgradeでマテリアライズドビューのrelfrozenxidを維持するエラーを修復しました。
(Tom Lane, Andres Freund)
この間違いで「could not access status of transaction（トランザクション状態にアクセスできません）」あるいは「found xmin from before relfrozenxid（relfrozenxidより前のxminが見つかりました）」というエラーが出て、アップグレード後にマテリアライズドビューデータ破損をひき起こすおそれがありました。
この問題は、ほとんどリフレッシュされていなかったり、REFRESH MATERIALIZED VIEW CONCURRENTLYだけで保守されているマテリアライズドビューでより発生しやすいでしょう。
このような破損が見つかった場合、マテリアライズドビューを（CONCURRENTLY無しで）リフレッシュして修復できます。
エラーのCONTEXTスタックでのPL/Python関数名の誤った報告を修正しました。
(Tom Lane)
入れ子のPL/Python関数呼び出し（すなわち、他のPL/Python関数からのSPI問い合わせを通して到達するもの）の中で発生するエラーは、期待された結果ではなく、内側の関数名を2回表示するスタックトレースになりました。
また、入れ子のPL/PythonDOブロック内のエラーは一部のプラットフォームでNULLポインタ参照によるクラッシュをひき起こすおそれがありました。
contrib/auto_explainのlog_min_duration設定を約35分までであったものをINT_MAXあるいは約24日間までの範囲に指定できるようにしました。
(Tom Lane)