このリリースは 9.4.3 からの修正リリース（2015年6月12日リリース）です。
9.4.x からのアップデートではダンプ、リストアは不要です。
また、9.4.2 より前のバージョンからアップデートを行う場合は 9.4.2 に関する技術情報 を参照してください。
PostgreSQL 9.4.3 から 9.4.4 への変更点
9.4.4、9.3.9、9.2.13、9.1.18、9.0.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。 各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。
- 一貫性のないデータベース状態からのリカバリに失敗する可能性があり、修正されました (Robert Haas) (9.4) (9.3)
- 稀におきるリレーションキャッシュ初期化ファイル(pg_internal.init)の無効化失敗が修正されました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)
- 新たなセッション開始と CREATE/DROP DATABASE のデッドロックを回避するようになりました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)
- 内側のインデックススキャンを伴う semi-join、anti-join についてプランナのコスト見積もりが改善されました。 (Tom Lane, Tomas Vondra) (9.4)(9.3)
最近のPostgreSQLリリースでマルチトランザクション周回を防ぐ仕組みが導入されましたが、実装の一部において発生する可能性をつぶせていませんでした。一貫性の無い状態データベースをクラッシュリカバリする際に漏れることがあります。この結果、クラッシュ後の再起動やスタンバイサーバの最初の起動に失敗する可能性がありました。バージョン 9.3.0 から 9.3.4 の pg_upgrade を使ったインストールでも、同様の障害をひき起こします。
pg_upgrade の誤りは、pg_control の oldestMultiXid をもっと大きい値にすべき場合でも 1 に設定していたことです。本リリースの修正後は、このような状況では緊急自動VACUUM となり、oldestMultiXid の正しい値が定まるまで実行されます。アップグレードを開始する前にあらかじめ VACUUM を実行しておくことで、このような動作を避けることができます。
同時実行のタイミングによっては、システムカタログの VACUUM FULL が、新たなセッションでキャッシュローディングを避けるのに使われる初期化ファイルの更新に、失敗することがありえました。結果として、後のセッションがそのシステムカタログにまったくアクセスできなくなってしまいます。
障害発生時には「cache lookup failed」や「could not open file」といったエラーが発生すると考えられ、解消には pg_internal.init ファイルを手動で削除するほかありません。
DROP DATABASE で削除するデータベースや、CREATE DATABASE でテンプレートに使うデータベースに新たなセッションを開始すると、これらコマンドは 5秒待って（競合するセッションがその前に終了していたとしても）エラーになっていました。
全ての結合節がインデックススキャン条件として使われている場合、たとえ内側スキャンが見かけ上多数の行を読み出すとしても、エグゼキュータは一行を取得した後に止まるので、低コストなプランとなります。
プランナはこの効果について部分的にしか考慮しておらず、結果としてコストを過大評価して、劣った別のプランが選択される原因となっていました。