MovableTypeが5.02になったと言うので、アップグレードすることに。
いつものように元のディレクトリをリネームして、新しいMT-5_02-ja.zipをを展開してできたディレクトリをインストール先に置く。
テンプレートやpluginなどをコピーし、自分でいじっている箇所のソースのパッチをあてる。
で、mt.cgiにアクセスすると、いつものようにDBのアップグレードの画面になるのだが、そこで開始を押すとエラーで止まってしまった。

failed to execute statement
 INSERT INTO mt_entry (entry_author_id,entry_ping_count,entry_excerpt,entry_atom_id,entry_status,entry_tangent_cache,entry_keywords,entry_category_id,entry_convert_breaks,entry_comment_count,entry_current_revision,entry_text_more,entry_text,entry_created_on,entry_pinged_urls,entry_allow_pings,entry_authored_on,entry_modified_by,entry_id,entry_blog_id,entry_to_ping_urls,entry_template_id,entry_allow_comments,entry_basename,entry_modified_on,entry_title,entry_class,entry_week_number,entry_created_by) SELECT entry_author_id,entry_ping_count,entry_excerpt,entry_atom_id,entry_status,entry_tangent_cache,entry_keywords,entry_category_id,entry_convert_breaks,entry_comment_count,entry_current_revision,entry_text_more,entry_text,entry_created_on,entry_pinged_urls,entry_allow_pings,entry_authored_on,entry_modified_by,entry_id,entry_blog_id,entry_to_ping_urls,entry_template_id,entry_allow_comments,entry_basename,entry_modified_on,entry_title,entry_class,entry_week_number,entry_created_by FROM mt_entry_upgrade: 
ERROR: null value in column "entry_current_revision" violates not-null constraint at lib/MT/Upgrade.pm line 771. 

どうも、アップグレードの過程で既存のmt_entryテーブルをmt_entry_upgradeにした上で、新しいスキーマ用のmt_entryを作ってコピーしているようなのだが、そこで失敗しているらしい。
そのままリロードしたりしてみたが、アップグレードのプロセスは先に進んでしまい、その後もエラーが何度も出たまま終了してしまった。MTの管理画面を見ると、blogのエントリが0件になってしまっていた。
しょうがないので、periodicで毎日バックアップしているものから復元することにする。
バックアップ自体は、FreeBSDのportsでpostgresqlを入れると自動でやってくれるもので、戻し方がわからない。マニュアルを読みながら何度かやってみたところ、pgsqlユーザで以下を実行することで戻せた。

dropdb mt5
pg_restore -C -d postgres pgdump_mt5_2010-05-15T03:10:40

あ、カレントディレクトリはバックアップファイルがあるところ。~pgsql/backup。
で、MT自身を5.01に戻したら今朝の3時の状態までは戻せたようだ。

5.02はセキュリティfixらしいし、今後のことも考えてバージョンアップしたい。
エラーの内容から察するに、今回のアップグレードでentry_current_revisionにnull制約が追加されたのだろう。
Upgrade.pmを読んで見たが、テーブル毎の細かい処理などは書いていなくて、スキーマの違いを見て良きに計らってくれるようにできているようだ。
MysqlとPostgresqlの挙動の違いなのか、DBI::postgresあたりのせいなのか、はたまた5.0に上げたときに通常と違うプロセスを踏んだせいなのかわからないが、ソースから追うのは厳しそうだったので、DBをいじることで切り抜けることにする。
またマスターのDBを壊すと嫌なので、バックアップから新しいDBを作って試してみることにした。

createdb -T template0 mt502
pg_restore -d mt502 pgdump_mt5_2010-05-15T03:10:40

やっていることは、mt502と言う空のDBを作成して、mt5と言うマスターDBのバックアップからのリストア。

まずは、以下のSQLを実行してみた。

select count(*), entry_current_revision from mt_entry group by entry_current_revision;
 count | entry_current_revision
-------+---------------------------
  3874 |
   169 |                      0
(2 行)

ここから推測されることは、MT5.0だかMT5.01からこのカラムができて、そこからは0が入るようになっていて、それ以前のバージョンで作成されたエントリだとnullが入っていると思われる。しかも、0しか入っていないと言うことは、今のところあまり意味がない。
そこで、

update mt_entry set entry_current_revision=0 where entry_current_revision is null;

で、再度アップグレードを実行してみると、mt_templateで似たようなエラーが出る。
同じように中身を確認して(、バックアップからDBを再構築して)、nullのところを0にしてやる。

select count(*), template_current_revision from mt_template group by template_current_revision;
 count | template_current_revision
-------+---------------------------
   367 |
    10 |                         0
(2 行)

update mt_template set template_current_revision=0 where template_current_revision is null;

再度バックアップからDBを生成して二つのテーブルのcurrent_revisionを0にしてみたところ、今度はアップグレードが最後まで成功した。
と、言うわけでアップグレード後の最初のエントリなのだが、うまくpostできるだろうか？