E.43. リリース9.2.6

E.43.1. バージョン9.2.6への移行

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

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

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

E.43.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を実行することで確認できます。）、 そのインストレーションは、このバキュームを実行することで安全だと言うことができるでしょう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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