E.1. リリース9.3.2

E.1.1. バージョン9.3.2への移行

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

しかしながら、本リリースは多くのデータ破損が発生する可能性がある問題を修正しています。下記に示すはじめの3つの変更点を確認し、使用しているインストレーションが影響を受けるか、その場合どのような処置を施すべきか判断してください。

また9.3.1以前のバージョンから更新する場合は9.3.1のリリースノートを参照してください。

E.1.2. 変更点

• relfrozenxidの値を更新するかどうか判定するVACUUMの処理を修正しました。(Andres Freund)

  2^31のトランザクションが経過するたびに、VACUUM (手作業によるものでも、自動バキュームでも)が誤って、 テーブルのrelfrozenxid値を増加させ、タプルが凍結されず、それらの行が見えなくなってしまう可能性がありました。 実際にデータ損失が発生する前に、複数の誤った値の増加が発生することが前提であるため、データが損失する可能性は、きわめて低いですが、ゼロではありません。 9.2.0とそれ以降のバージョンでは、データ損失が起きる可能性はより高く、このバグの結果として、"could not access status of transaction"というエラーが発生する可能性があります。 9.0.4、8.4.8、もしくは、それ以前のバージョンからアップグレードする場合は、影響を受けません。しかし、それ以後のバージョンはすべて、このバグが存在しています。

  この問題は、アップグレード後、vacuum_freeze_table_ageを ゼロに設定し、全データベースの全テーブルをバキュームすることにより改善できます。 これにより、データ損失が発生する可能性が修正されますが、すでに存在しているすべてのデータエラーは修正できません。 しかしながら、その存続期間内2^31以下の更新トランザクションしか実行されていない場合（これは、SELECT txid_current() < 2^31を実行することで確認できます。）、 そのインストレーションは、このバキュームを実行することで安全だと言うことができるでしょう。

• MultiXactIdを凍結する際の複数のバグを修正しました。 (Andres Freund, Álvaro Herrera)

  これらのバグは、"could not access status of transaction"というエラー、もしくは重複行や行の消去が発生する可能性がありました。

  この問題は、アップグレード後、vacuum_freeze_table_ageをゼロに設定した上で、 全データベースの全テーブルをバキュームすることにより改善できます。 これにより、データ損失が発生する可能性が修正されますが、すでに存在しているすべてのデータエラーは修正できません。

  別の問題として、これらのバグにより、スタンバイサーバがプライマリサーバと同期できなくなる可能性があり、それにより、プライマリサーバでは発生していないデータエラーがスタンバイサーバで発生します。 それゆえ、アップグレード後、9.3.0と9.3.1のスタンバイサーバは、(たとえば、新しくベースバックアップをとるなどの方法で)プライマリサーバから複製し直すことを推奨します。

• ホットスタンバイ起動中のpg_clog と pg_subtransの初期化処理を修正しました。(Andres Freund, Heikki Linnakangas)

  このバグはコミットされたトランザクションがコミットされてないとマークされることにより、ホットスタンバイでの問い合わせを受け付け始めるときにスタンバイサーバのデータ損失が発生する原因となっていました。 スタンバイサーバが起動するときに、プライマリサーバは最後にチェックポイントが発生してからの多くの更新トランザクションを実行していない場合、データ損失が発生する可能性は小さいです。 行が損失してしまう現象や、削除されたはずの行が可視になる現象、更新前の行データが更新後の行データとともに残ってしまう現象が発生します。

  このバグは、9.3.0, 9.2.5, 9.1.10, 9.0.14のバージョンで起こります、 これ以前のバージョンで稼働しているスタンバイサーバでは発生するリスクはありません。 不具合のあるリリース上で稼働しているスタンバイサーバは、アップグレード後、(たとえば、新しくベースバックアップをとるなどの方法で)プライマリサーバから複製し直すことを推奨します。

• 更新巡回に関する複数のバグを修正しました。(Andres Freund, Álvaro Herrera)

  これらのバグにより、同時に更新があった際に、誤った行をロックもしくは更新するなどの正しくない振る舞いが発生する可能性がありました。 誤って、"unable to fetch updated version of tuple"というエラーが発生する可能性もありました。

• ファストパスロック時の不正な領域を指し示すポインタに関する問題を修正しました。(Tom Lane)

  これにより、共有メモリ内のロックデータ構造が破損し、"lock already held"やその他のおかしいエラーが発生する可能性がありました

• タイムアウト管理を行う際の様々な競合条件を修正しました。(Tom Lane)

  SIGALRMもしくは、SIGINTをブロックしていたため、これらのエラーにより、サーバプロセスが反応しなくなる可能性がありました。

• WAL再生中にpg_multixactのデータを切り詰めるようにしました。(Andres Freund)

  これにより、スタンバイサーバにおいて増え続けていたディスク容量消費を避けることが出来ます。

• 凍結が必要なタプルがないと確認された場合にのみ、周回防止用のVACUUMが、スキャンされたページをカウントすることを保証します。(Sergey Burladyan, Jeff Janes)

  このバグにより、relfrozenxidを進めることができない可能性がありました。それにより、テーブルがまだ周回防止用のバキュームが必要だと考えられていました。 最悪の場合、データベースは周回を防ぐためにシャットダウンする可能性もありました。

• テーブル全体のバキュームを要求するMultiXactIdの機能を修正しました。(Andres Freund)

  このバグにより、不要な自動バキュームが数多く行われていました。

• GINインデックスがツリーページを削除する際の競合条件を修正しました。(Heikki Linnakangas)

  これにより、一時的な誤った応答やクエリの失敗が発生する可能性がありました。

• SP-GiSTインデックスが作成される間の"unexpected spgdoinsert() failure"というエラーを修正しました。(Teodor Sigaev)

• マテリアライズドビューに関する様々なバグを修正しました。 (Kevin Grittner, Andres Freund)

• 別名を結合内で付けられた場合、重複したテーブル別名を付けられるようにしました。(Tom Lane)

  歴史的にPostgreSQLでは、以下のような問い合わせを受け入れていました。

  SELECT ... FROM tab1 x CROSS JOIN (tab2 x CROSS JOIN tab3 y) z

  しかし、SQL標準を厳密に読むと、テーブル別名xを重複して使うことは禁止されているようです。 9.3.0での誤った変更により、以前は受け入れられていたこのような場合が拒絶されるようになりました。 以前の動作に戻しました。

• 副問い合わせのSELECT内部にラップされた揮発性関数をもつSELECTの副問い合わせの平坦化を避けるようにしました。(Tom Lane)

  これにより、揮発性関数の余計な計算による予期しない結果を避けることができます。

• 単純な変数以外の副問い合わせ結果が外部結合内でネストしている場合に関するプランナの処理を修正しました。(Tom Lane)

  このエラーのせいで、JOINの中で、複数のレベルの副問い合わせを含む問い合わせに対して誤ったプランが選ばれる可能性がありました。

• 複数のWHERE句と外部結合のJOIN句の等式で、制限のない同じ式が現れた場合の誤ったプラン生成を修正しました。(Tom Lane)

• 副問い合わせへの行全体の参照時にプランナがクラッシュする問題を修正しました。(Tom Lane)

• 継承ツリーへのMIN()/MAX()関数に対する最適化プラン生成の誤りを修正しました。(Tom Lane)

  MIN()/MAX()の引数に単純な値ではなく、式を与えると、プランナが失敗する可能性がありました。

• 一時ファイルの早すぎる削除を修正しました。 (Andres Freund)

• 範囲型の値を出力する際のトランザクション内のメモリリークを防止するようにしました。(Tom Lane)

  この修正は、あらゆるデータ型の出力関数の瞬間的なメモリリークを防止しますが、特に範囲型においては重大な問題となっていました。

• 設定ファイルをリロードする際のメモリリークを修正しました。(Heikki Linnakangas, Hari Babu)

• NOT NULL制約やチェック制約の制約違反メッセージで、誤って削除済みの列が表示される問題を修正しました。(Michael Paquier and Tom Lane)

• ウィンドウ関数に対して、デフォルト引数と名前付き引数指定の記法に対応するようにしました。(Tom Lane)

  以前はこのようなケースでクラッシュが発生していました。

• ルールやビューを見やすく表示するとき、各行の終端に表示されていた空白を抑制します。(Tom Lane)

  9.3.0 は以前のバージョンと比べて、このような空白を出力するケースが多くありました。想定外の振る舞いの変化を減らすため、すべての場合について不要な空白だけを抑制しています。

• ルールの出力時にメモリの最後を超えて読もうとする可能性があることを修正ました。(Peter Eisentraut)

• int2vectorとoidvectorの部分配列を修正しました。(Tom Lane)

  これらの表現は現在、暗黙的に通常のint2もしくは、oidの配列に昇格させます。

• 空のhstoreの値をjsonに変換する際に、適切なJSONの値を返すようにしました。(Oskari Saarenmaa)

• SQL標準である単純なGMTオフセットタイムゾーンを使う際の誤った振る舞いを修正しました。(Tom Lane)

  単純なオフセットが選ばれる前に優勢になるべき通常のタイムゾーン設定を使うべきときにも、システムが単純なGMTオフセットの値を使う場合がありました。この変更は、timeofday関数が、単純なGMTオフセットを選ぶ原因にもなっていました。

• Windowsエラーコード変換のログ取得時に発生する可能性があった誤った振る舞いを防止しました。(Tom Lane)

• pg_ctlにおいて、生成されたコマンドラインを正しく引用するよう修正しました。(Naoya Anzai and Tom Lane)

  この修正は、Windows版のみに適用されます。

• バックアップ元のデータベースがALTER DATABASE SET経由で、default_transaction_read_onlyを設定するときのpg_dumpallの動きを修正しました。(Kevin Grittner)

  以前は、生成されたスクリプトがリストア中に失敗していました。

• pg_isreadyが-dオプションを適切に扱えるように修正しました。(Fabrízio de Royes Mello and Fujii Masao)

• pg_receivexlog内のWALファイル名解析処理を修正しました。(Heikki Linnakangas)

  このエラーにより、少なくとも4GBのWALが書き込まれると、pg_receivexlogが、停止後のストリームを再実行できませんでした。

• Report out-of-disk-space failures properly in pg_upgrade (Peter Eisentraut)

• ecpgにおいて、引用符付きのカーソル名の検索が大文字と小文字を区別するようにしました。(Zoltán Böszörményi)

• ecpgについて、varcharが宣言された変数のリストに関する処理を修正しました。(Zoltán Böszörményi)

• contrib/loを誤ったトリガ定義から保護します。(Marc Cousin)

• 時間帯データファイルをtzdataリリース2013hに更新しました。 アルゼンチン、ブラジル、ヨルダン、リビア、リヒテンシュタイン、モロッコ、およびパレスチナでの夏時間の変更が含まれます。 インドネシアで使用されている新しい時間帯の略号、WIB, WIT, WITAが追加されました。