[pgsql-jp: 36313] Re: pg_clog ディレクトリ内のログが参照できず PANIC

[Kiyoshi Mizuno]

水野です。

> -----Original Message-----
> From: pgsql-jp-bounces ＠ ml.postgresql.jp  On Behalf Of Saitou
> Subject: [pgsql-jp: 36310] Re: pg_clog ディレクトリ内のログが参照できず PANIC
> 
> 確かこのスレッドの中で、メモリ故障の可能性もあるという話
> 題もあったかと思います。
> メモリだったら、"既存のxmin,xmax等のxid型システムカラム"が
> 破壊されていると考えられたのでしょうか。

「メモリ用のベンチマークソフトでチェックしてみたら？」
という話でしたよね。壊れたのがメモリだったとしても最終的に
ディスクへ書き込まれたデータが正常であれば問題なしです。

例えば２GBのRAMを積んだマシンがあり、特定の物理アドレスが
壊れたとします。
（「物理アドレス」という単語に？がつく場合はマシンに搭載した
メモリのうち、チップのどれか１つが壊れたと思ってください。
Cマガジン１１月号にちょうどCPUの特集がありますので
勉強するならそれを読むといいです。）

しかしLinux等最近の仮想記憶を使うOSでは、OS上では
「論理アドレス」でデータを読書きします。それをCPUに
内蔵したメモリ管理ユニット（MMU)が物理アドレスに変換して
実際のメモリリード／ライトを行います（この際必要に応じて
SWAP領域とメモリ間でデータを交換したりもする）。
こうやって実際に搭載した以上のメモリを使用できる訳です。

前フリが長くなりましたが、この仮想記憶という仕組みのため
メモリチップが破損した場合でもその影響がどこに出るのかは
常に変化します（アドレスによっては変わらない事もある）。
アプリのプログラム領域に割り付いたらアプリが異常動作する
でしょうし、データ領域だったらデータが化けます（斎藤さんが
想像したのはこのケースですね）。
で、運悪くOSのカーネルにでも割り付けられたらWindowsで
言うところの「ブルースクリーンとご対面」になってしまいます。