9.2でバージョンアップした訳でもないのにリストアに失敗するという不可解な現象に遭遇しました。今後も無いとは限らないので、備忘のためにメモ。(name);というエラーが。この種のエラーは過去にも数度経験していて、これまではdropdbとpg_restoreを再実行すると何事も無かったかのように成功していたのですが、なぜか今回は再現性があって、かなり焦りました。エラーの解読まずは上の{=呪文=}エラーを解読しなければなりません。理解できてから改めて読むと修正に必要な情報がすべて書かれているんですが、1行目の"TOC"の時点で意味不明で戦々恐々です。..."という内容であることが分かりました。ここまで理解できればなんとか手作業で修正できそうです。エラーが発生した処理の確認まずは上記エラーが発生した処理を念のため確認します。pgsqlという1行だけのテキストファイルを適当な名前(err_toc.txt)で作成します。pg_restoreで-L(大文字のエル)オプションを使って上記ファイルを指定すると、その処理の内容を確認できます。データベースの修復マニュアルを見る限りではpg_restoreは途中で処理に失敗しても残りのTOCを継続して処理するようなのですが、気分の問題としてひとまずエラーがない状況で最大限DBを復旧させます。pg_resotreでは-l(小文字のエル)オプションでTOCを取得できるので、これをテキストに書き出します。..."のTOCエントリの行をコメントアウトします。:行頭にセミコロンを付けて保存したら、今度は先ほどの-Lオプションを使ってDBに接続してリストアします。toc.txtこれで今回はエラーなくリストアできました。処理の内容によってはエラーより後の処理で不具合が出る可能性もあるので、toc.txtをエラー前とエラー後に分割して、エラー前の処理までのリストアエラーへの対策とエラーが発生した処理の実行エラー後の処理のリストアという順番で修復する必要があるかもしれません。KEY制約の付加だけなので、他の処理はすべて実行してしまっても大丈夫でしょう。エラーの修復DBに接続してエラーの状況を確認します。'menu_expanded'というデータのエラーだと分かるので、見てみます。その前にvariableテーブルはDrupalのオブジェクトを保存するためのテーブルなので、その内容をdrushコマンドをつかって確認しておきます。Array()どうやら空の配列のようです。次にDBに接続してテーブルの内容を確認します。行)なぜか全く同じ内容のエントリが2つあるので、削除してしまいます。2削除されている事を確認します。行)ここで直接INSERT文を発行して上記データを登録しても良いのですが、Drupalでは1文字でもtypoがあるとNULL扱いになってしまうので、こちらもdrushを使います。array());"データを確認します。行)これでデータは修正できたはずですので、最初の方で作ったerr_toc.txtを使ってエラーの出ていた処理を再実行します。-vオプションを付けると冗長な出力をしてくれます。-Cオプションを付けたり接続先のDBを間違えたりしないよう気をつけましょう。variable_pkey用の所有者と権限を設定しています念のため、確認します。KEYとしてインデックスに表示されているので、正しく修復できた事が分かります。基本的にはエラーが出なくなるまでこの作業の繰り返しです。2.5.7-p206。