E.21. リリース9.3.9

E.21.1. バージョン9.3.9への移行

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

しかしながら、以前に9.3.0から9.3.4のpg_upgradeを使ってアップグレードしている場合には、以下の変更点の最初の項目を確認してください。

また、9.3.7よりも前のリリースからアップグレードする場合は、項E.23を参照して下さい。

E.21.2. 変更点

• 一貫性のないデータベース状態からのリカバリに失敗する可能性があり、修正しました。 (Robert Haas)

  最近のPostgreSQLリリースでマルチトランザクション周回を防ぐ仕組みが導入されましたが、そのコードの一部はデータベースがまだ一貫した状態になっていないときのクラッシュリカバリ中に実行が必要となる可能性について責任を果たしていませんでした。 これはクラッシュ後の再起動失敗やスタンバイサーバの開始失敗を引き起こすおそれがあります。 バージョン9.3.0から9.3.4のpg_upgradeを使って構築されたデータベースでは、以前に修正されたpg_upgradeのバグの長引く影響が同様の障害を引き起こします。

  問題のpg_upgradeのバグは、本来はより大きい値であるべきときでもpg_controlのoldestMultiXidに1を設定します。 本リリースで導入された修正では、このような状態では直ちに緊急自動バキュームが生じ、適正なoldestMultiXid値を確定できるまで実行されます。 このことが困難を引き起こすのであれば、本リリースにアップグレードする前に手動バキュームを行うことで回避できます。 詳細手順は以下の通りです。

  1. pg_controldataが"Latest checkpoint's oldestMultiXid"を1と報告するかを確認します。そうでなければ、やるべきことはありません。

  2. PGDATA/pg_multixact/offsetsで0000ファイルが在るかを見ます。 ファイルが在るなら、やるべきことはありません。

  3. さもなくば、pg_class.relminmxidが1である各テーブルに対して、 vacuum_multixact_freeze_min_ageとvacuum_multixact_freeze_table_ageを0に設定したうえで、VACUUMを行います。 （同時実行セッションの性能影響を減らすため、項18.4.4に記載されているバキュームコスト遅延設定を使うことができます）

• 稀にリレーションキャッシュ初期化ファイル無効化に失敗するのを修正しました。 (Tom Lane)

  ちょうど悪いタイミングの同時動作で、システムカタログのVACUUM FULLが、新たなセッションのためにキャッシュ読み込み動作を避けるのに使われる"initファイル"の更新に失敗することがありました。 この結果、後のセッションがそのシステムカタログに全くアクセスできなくなってしまいます。 これはとても古くからのバグですが、起こすのが難しく、最近まで再現できるケースが見つかりませんでした。

• 新たなセッション開始とCREATE/DROP DATABASEとの間のデッドロックを回避しました。 (Tom Lane)

  DROP DATABASEコマンドの対象であるか、または、CREATE DATABASEコマンドでのテンプレートであるデータベースに対する新たなセッション開始が、5秒待った後、たとえ新たなセッションがその前に終了していたとしても、失敗する可能性がありました。

• 内部インデックススキャンでセミ結合とアンチ結合についてプランナのコスト見積りを改善しました。 (Tom Lane, Tomas Vondra)

  全ての結合節がインデックススキャン条件として使われている場合、たとえ内部スキャンが見かけ上は多数の行を読みだすとしても、エグゼキュータは一行を取得した後止まるので、この種の実行計画は全く低コストです。 プランナはこの効果をごく一部しか考慮しておらず、他の能率が大きく劣る他の計画タイプを選んでしまう可能性をもたらしていました。