■問題の詳細

• Image::Magick をロードして何かしら処理を行うルーチンを SpeedyCGI で実行する時、２回目以降のキャッシュされた状態で不具合が起こる*1。
• 問題確認環境
  • Perl 5.8.8 + SpeedyCGI 2.22
  • ImageMagick 6.3.7 および 6.5.9

この問題は FastCGI や mod_perl2 では起きません。

*1 : スクリプトの処理が停止してしまう。もしくは処理中のまま返ってこなくなる

■問題の症状

スクリプト

#!/usr/bin/speedy

use Image::Magick();

print "Content-Type: text/plain\n\n";
print "Image::Magick Version $Image::Magick::VERSION \n";
my $image = Image::Magick->new;
$image->Read( 'x.png' );
}

実行結果。

~$ test.pl
Image::Magick Version 6.3.7
~$ test.pl
Segmentation fault

~$ test.pl
Image::Magick Version 6.5.9
~$ test.pl
Segmentation fault

■問題の原因

不明。

■問題の解決法？？

ENDブロックを呼ばれないようにして終了時のメモリ開放はOSやPerl自身に任せる。

#!/usr/bin/speedy

use Image::Magick();
sub Image::Magick::END {}

print "Content-Type: text/plain\n\n";
print "Image::Magick Version $Image::Magick::VERSION \n";
my $image = Image::Magick->new;
$image->Read( 'x.png' );
}

たしかにこれで問題は起こらなくなるのですが、

$image->Write( 'x.jpg' );

をするだけでダメになる。とにかくメモリリークっぽい挙動ですが、詳細が不明の挙動不明で、試行錯誤の末 Image::Magick をロードするダミーモジュールを作成しましたが、これで回避できるケースと回避できないケースがあり暗中模索。

• ImageMagick.pm

  use strict;
  package ImageMagick;
  sub new {
  	require Image::Magick;
  	return Image::Magick->new;
  }
  

• main.pl

  use ImageMagick();
  my $img = ImageMagick->new;
  #
  # $img は Image::Magick のオブジェクトであるので、
  # Image::Magick と同様に利用できる。
  #
  

■まとめ

とりあえず現在のところ挙動が意味不明です。ファイル入出力と関連してバグっている様ですが……。

gccの（ライブラリlibgomp ）バグのようです。gcc 4.3より前のVersion（4.2以下）で、amd64環境の時起こる模様。

■メモ

256色png（8bitカラーパレット）で保存する方法。

$image->Read( 'x.png' );
$image->Resize(width=>133, height=>100);
$image->Quantize(colorspace=>'RGB',colors=>256);
$image->Set(depth => 8); 
$image->Write( 'y.png' );

<div class="image"><span class="dummy"></span><img src="xxx.png" /></div>

div.image {
	border:		1px solid #8ff;

	min-width:	320px;
	width:		320px;
	height:		240px;
	_width:		322px;
	_height:	242px;

	text-align:	center;
	display:	block;
}
div.image span.dummy {
	height:		240px;
	width:		0px;
	vertical-align:	middle;
	display:	inline-block;
}
div.image img {
	max-width:	320px;
	max-height:	240px;
	vertical-align:	middle;

	/* IE6 hack */
	_margin-top:	-1px;
	/* IE6 でアスペクト比保存縮小のためのhack */
	_width:		expression(this.height>240 && this.width*3<this.height*4 ? Math.floor(this.width*240/this.height) : (this.width > 320 ? 320: true ));
	_height:	expression(this.height>240 ? 240: true );
}
*:first-child+html div.image img { /* IE7 hack */
	margin-top:	-1px;
}

■IE6で縦横比保存なmax-width, max-height

img {
	max-width:	320px;
	max-height:	240px;
	_width:		expression(this.height>240 && this.width*3<this.height*4 ? Math.floor(this.width*240/this.height) : (this.width > 320 ? 320: true ));
	_height:	expression(this.height>240 ? 240: true );
}

240と320を好みのサイズに変更してください。

■雑多なおさらい

• JavaScriptのクラスの概念はないらしい。
• プリミティブな数字や文字列など意外は、すべてオブジェクトであり参照。
• 参照なので代入した側でメンバ変数をいじると、代入元も書き換わる。
• 関数を変数に代入できる。

  var f = function (x){ alert(x); }
  f("msg");    // "msg"と表示される
  

Perl5のオブジェクトに似たところがありますが、クラス名前空間（パッケージ）を持たないため、Perl5よりも簡素な実装と言えそうです。

続きを読む

Yorkfield『> オブジェクト（っぽいもの）の生成 ・JavaScriptは大小文字を区別するのでそのままだとエラーになってしまいます。 ・メ...』(2010/02/06 28:49)
なべ『>・JavaScriptは大小文字を区別するので >・メンバ関数add/subはメンバ変数を変更してないので、 しまった。単純な...』(2010/02/09 25:19)

■共有メモリ設定

共有メモリの確認

# ipcs -m
# cat /proc/sys/kernel/shmmax

共有メモリの変更

1G
# echo 1099511627776 >/proc/sys/kernel/shmmax
1.5G
# echo 1649267441664 >/proc/sys/kernel/shmmax

■制約やカラムの操作

Ver8.3で確認。テーブル名、カラム名が変更されていても作成時のものとなるので注意。

制約の種類	制約名
PRIMARY KEY	[table]_pkey
UNIQUE	[table]_[col]_key
REFERENCES	[table]_[col]_fkey

ALTER TABLE table ADD CONSTRAINT table_[col]_fkey FOREIGN KEY ([col]) REFERENCES usr([ref_col]);
ALTER TABLE table DROP CONSTRAINT table_[col]_key;

目的	SQL
NOT NULLを付ける	ALTER TABLE table ALTER COLUMN [col] SET NOT NULL
NOT NULLを外す	ALTER TABLE table ALTER COLUMN [col] DROP NOT NULL
DEFAULTを付ける	ALTER TABLE table ALTER COLUMN [col] SET DEFAULT [value]
DEFAULTを外す	ALTER TABLE table ALTER COLUMN [col] DROP DEFAULT
カラム名を変える	ALTER TABLE table RENAME [old_col] TO [new_col]
テーブル名を変える	ALTER TABLE table RENAME TO table2

■条件

• Perl 5.8以降
• 利用可能文字列はutf-8のみ（そうでない場合はutf8に変換して渡してください）
• WTFPL（PDS扱いでも可）。

ソースは必ずutf-8で保存してください。

■日本語に混ざる全角英数等を半角にする

use utf8;
use Encode ();
sub utf8_zen2han {
	my $str = shift;
	my $flag = utf8::is_utf8($str);
	Encode::_utf8_on($str);

	$str =~ tr/　！”＃＄％＆’（）＊＋，－．／０-９：；＜＝＞？＠Ａ-Ｚ［￥］＾＿｀ａ-ｚ｛｜｝/ -}/;

	if (!$flag) { Encode::_utf8_off($str); }
	return $str;
}

実行例。

（変換前）ａｂｃｄｅｆｇさささ１１０－２２４４あいう＃＃＄”
（変換後）abcdefgさささ110-2244あいう##$"

■半角カタカナを全角カタカナにする

use utf8;
use Encode ();

my %hankana_map = (
'ｶﾞ'=>'ガ','ｷﾞ'=>'ギ','ｸﾞ'=>'グ','ｹﾞ'=>'ゲ','ｺﾞ'=>'ゴ',
'ｻﾞ'=>'ザ','ｼﾞ'=>'ジ','ｽﾞ'=>'ズ','ｾﾞ'=>'ゼ','ｿﾞ'=>'ゾ',
'ﾀﾞ'=>'ダ','ﾁﾞ'=>'ヂ','ﾂﾞ'=>'ヅ','ﾃﾞ'=>'デ','ﾄﾞ'=>'ド',
'ﾊﾞ'=>'バ','ﾋﾞ'=>'ビ','ﾌﾞ'=>'ブ','ﾍﾞ'=>'ベ','ﾎﾞ'=>'ボ',
'ﾊﾟ'=>'パ','ﾋﾟ'=>'ピ','ﾌﾟ'=>'プ','ﾍﾟ'=>'ペ','ﾎﾟ'=>'ポ',
'ｳﾞ'=>'ヴ');

sub utf8_hankana2zen {
	my $str = shift;

	my $flag = utf8::is_utf8($$str);
	Encode::_utf8_on($$str);

	$str =~ s/(ｶﾞ|ｷﾞ|ｸﾞ|ｹﾞ|ｺﾞ|ｻﾞ|ｼﾞ|ｽﾞ|ｾﾞ|ｿﾞ|ﾀﾞ|ﾁﾞ|ﾂﾞ|ﾃﾞ|ﾄﾞ|ﾊﾞ|ﾋﾞ|ﾌﾞ|ﾍﾞ|ﾎﾞ|ﾊﾟ|ﾋﾟ|ﾌﾟ|ﾍﾟ|ﾎﾟ|ｳﾞ)/$hankana_map{$1}/g;
	$str =~ tr/｡-ﾟ/。「」、・ヲァィゥェォャュョッーアイウエオカキクケコサシスセソタチツテトナニヌネノハヒフヘホマミムメモヤユヨラリルレロワン゛゜/;

	if (!$flag) { Encode::_utf8_off($str); }
	return $str;
}

Encode::JP::H2Z

EUC-JPの場合は標準モジュールで行くようです。（竹さん感謝）

use Encode ();
use Encode::JP::H2Z ();

sub eucjp_hankana2zen {
	my $str = shift;
	Encode::JP::H2Z::h2z(\$str);
	return $str;
}

逆変換は Encode::JP::H2Z::z2h()。

■その他

バグ等あったらコメントください。

竹『Encode::JP::H2Z の h2z, z2h でいいのでは？』(2010/01/09 19:44)
なべ『そんな便利なものが標準でついてましたか（汗） Jcode.pmに付いてるのは知ってたのですが(^^; 指摘感謝です。』(2010/01/09 19:49)
つーさ『私は、住所欄に番地を半角で打って 「住所を全角で入力してください！」と言われるのが逆にウザいです……(笑』(2010/01/15 28:13)
なべ『>「住所を全角で入力してください！」と言われるのが逆にウザいです……(笑 よくありますね、それ。 いちいち全角で入れなきゃいかな...』(2010/01/16 16:06)

■Ver2.11→Ver2.12の変更点

• テーマディレクトリを変更すると「印刷用の表示」がリンク切れになるバグを修正。
• クラス追加。div.hatena-body0, a.adiary, li.to-album (_frame.html/_sidebar.html)
• 浅野さんご指摘＆パッチ（感謝）。
  • アルバムのサムネイルビューでサムネイル上にマウスカーソルを置いたときにポップアップする情報が実際のファイルと一致しないバグを修正。
  • アルバムのスライドショーでファイルを選択したときに左上に表示されるファイル名とバイト数が実際のファイルと一致しないバグを修正。
  • アルバムで「すべて選択」「選択を解除」ボタンをクリックしても正常に動作しないバグを修正。
  • 携帯画面でのコメント表示がエラーになることがある不具合を修正。
  • スーパーpre記法中等に行頭にスペースが1つ入る仕様を変更したことによる、バグ混入の問題を修正。*1
  • aa記法が効かないバグを修正。
  • テーマ選択時に下フレームで表示される画面のHTML（スケルトン）が正しくなかった問題を修正。
  • テーマによって、「日記の削除/コメント・トラックバックの編集画面」でコメント・トラックバック件数部分の表示がおかしくなる不具合を修正。
• Ver2.06以降、アップローダーで中間拡張子チェックで"adiary-1.00.tgz"などが跳ねられてしまう問題を解決するため、数字など特定の文字を含む拡張子を許可する機能をつけました。*2
• アップローダーで0byteのファイルをアップロードできるようにしました。*3

*1 : 正規表現の/eスイッチ（実行構文属性）を付け忘れた（汗）

*2 : 詳しくは uploader.conf.cgi の <$v.allow_ex_match=""> を参照してください。

*3 : 今までは明示的エラーにならずアップロードもできなかったため、何が起きてるのかよく分からないという状態。

■Version2.00（β含む）以降からの乗り換え

• そのまま上書きしてください。
• Ver2.11以前の場合、uploader.conf.cgi をサンプルから再生成してください。

なおVer2.06よりアルバムシステム関連のJavaScriptの置き場が変更になっていますので、紛らわしい場合は theme/*.js を消してから上書きしてください。

アップデート方法の参考情報。

■Version1.44以前(C73/2.00α含む）以前からの乗り換え

Version2.00への移行処理を先に行ってください。

ひとぅ『遅くなりました。すみません。 なぜなのでしょうかねぇ？JavaScriptsがオフと言うことは無いですw。 「メール投稿はどの方...』(2010/02/20 5:48)
なべ『メール投稿はpopモードか、それともメール起動かという話です。popモードなのかなあ。この手の症状が出やすいのはメールによるプロ...』(2010/02/20 14:49)
ひとぅ『メール投稿はPOPモードです。 再現したのでソースを見てみると、うまく動作してるときはカレンダーの表示部分の前に以下のようなJa...』(2010/03/08 21:29)
なべ『popモードかあ。なんだろうなあ……。 たまに起こるというのが気になりますが^^;; あとで確認してみますねぇ。』(2010/03/10 23:41)
ひとぅ『すみません、お手数をおかけしますがよろしくお願いしますm(_ _)m。 何か追加で情報が必要でしたら言っていただけたら準備します...』(2010/03/10 24:59)

■メールの仕組みについて

問題について述べる前にメールサーバについて簡単におさらいしておきます。そんなの分かってるという人は飛ばしてください。

いわゆるメールサーバというのは、SMTPというプロトコルによってメールをサーバからサーバへ転送するサービスをしています。このSMTPというのは元々サーバも受信者も送信者もなにも区別がないプロトコルで、「SMTPサーバからSMTPサーバへどんどんタライまわしをしているといずれ受信サーバにたどりつく」というSPAMなんて存在しない、インターネットが限られた利用者が使用する紳士的な世界だった頃に作られました。その名残から、今もって

• メール送信時にメールクライアントソフト（メーラー）が自分のメール送信用サーバに対してメールのデータを送るSMTPと
• メールサーバ間でメールのデータをやりとりするときに使われるSMTP

には何の差も存在しません。こんな仕様だから、メール設定のいわゆるSMTPサーバ（送信サーバ）として使用するサーバには何かしら制限を加えておかないと、世界中からそのサーバを中継（経由）してSPAMを送り放題になってしまいます。このように「本来想定している人以外からのメールを送ること」を第三者中継といいます*1。第三者中継をしないために通常は次のような制限を加えておきます（いずれかもしくは複数）。

• 特定のIPからしか送信できないようにする。プロバイダのSMTPサーバが、そのプロバイダの利用者IPのみに中継を許可する。
• SMTP-AUTH等の認証をする。ID/パスワードを確認するので、正規のID/パスワードを持つ利用者のみに中継を許可できる。
• POP before SMTPという特殊な方法を利用する。メール送信前に１度メールを受信させることで、そのIP利用者に短時間だけ（１～５分程度）中継を許可する。

最初の方法だけで済めばよいのですが、どうしてもホテルやモバイルパソコンからメールを送信したいとなったときに必ずしも同じプロバイダを利用できるとは限らないので他の方法が必要になります。SMTP-AUTHがまだそんなに普及していなかった頃*2、過渡的な措置としてPOP before SMTPというのが考えられました。

以上はあくまで送る側の話で、SMTPサーバは送るためのサーバであると同時に受信サーバでもあることが多くあります*3。このままだと何処から送られてくるかわからない自分宛のメールを受け取れなくなってしまうので、自分宛のメールは無条件で受け取るという設定をします。例えば、xxx@foo.com ならば foo.com は自分宛ですよと登録しておきます。

*1 : 199x年頃はこの第三者中継が標準でonになっていたのだから恐ろしいものです。

*2 : いくらその仕組みを用意してもクライアントソフトが対応するまで利用できる人が限られていた

*3 : この２つは分けることもできるが、小規模なケースでは一緒にしてしまうことが多い

■CORESERVERのおさらい

• CORESERVERは送信メールサーバ＝受信メールサーバ
• CORESERVERはPOP before SMTPのみ対応（SMTP-AUTH未対応）

■CORESERVERの血迷っ…素敵過ぎる仕様

CORESERVERで普通にメールを設定して、メールを送ろうとしたらこんなエラーメールが帰ってきました。

<test@s1xx.coresv.jp>: host s1xx.coresv.jp[202.172.28.1xx] said: 552 sorry, your
    domain isn't in my list of allowed senderhosts (#5.7.1) (in reply to MAIL
    FROM command)

要するに「あなたのSMTPサーバは送信元ホスト許可リストに入っていません」と言っている。にも関わらず、他のぜんぜん関係ないメールサーバ（メールアカウント）からメールを送るとちゃんと受け取る。さっぱり意味不明。検索すると同じようにハマっている人多数。

色々調べてみたところ、原因がはっきりしました。

• POP before SMTPの設定時間（タイムアウト）が３時間以上！
• POP before SMTPでsenderhostsリストに登録されると、そのIPからのSMTP接続はすべて外部への中継（リレー）として受け取る

どちらの仕様もバカ素敵すぎて言葉もない。

つまり、

1. SMTPサーバでもあるIPで、CORESERVERからメールを受信する。
2. CORESERVER側でsenderhostsに登録される。
3. 手元のSMTPサーバからCORESERVER宛にメールを送信する。
4. CORESERVERはsenderhostsに登録さているという理由だけで、外部から自分宛のメール送信を強制的に内部(CORESERVER)から外部へのメール送信と見なす。
5. CORESERVERは外部へのメール送信のとき、予め登録された自ドメインとSMTPのFROM（SMTPにおけるFROMであるのでFROMヘッダとは異なる）が一致しないためメールを拒否する。
6. CORESERVERは自分宛のメールを552のエラーとして受取拒否する。

ということです。

そしておそらくsenderhostsのリストはサーバごとに全ユーザ共有だと思われるので（未確認）、たとえ自分でPOPしていなくても時々メールが送れないサーバが出てくる……と。

Gmailには

Gmailには、Gmailに統合してあるアカウント名義でメールを送信するため等の目的で外部SMTPサーバを使用してメールを送信する機能がありまして、それを使うとバッチリメールが送れなくなるわけです。

これをしないと、GmailではFromの代理送信表示がされてしまいます。

■総評

VALUE DOMAINのDNS設定も、何行か書くとすぐバグるし（行を入れ替えないとダメとか）、いまいちツメが甘い印象がぬぐえない。所詮、安かろうなんたらでしょうか。サーバスペックはいいんだけど、障害対応も遅いみたいだしねぇ。今回は安定性重視なのでCORESERVERは却下の方向。

どこか、もちょっとマトモなレンタルサーバ知りませんか？（苦笑）

■Ver2.09→Ver2.11の変更点

• 擬似データベース（pseudo DB）使用時、wikiコンテンツを開こうとするとDB速度が著しく低下する問題を修正しました。擬似データベース使用者は「管理」→「システム管理」→「管理者メニュー」→「Version 2.09以前 → Version 2.10以降へのアップグレード」を実行してください。擬似データベース以外は実行できません。
• アルバムにソートの機能が付きました。
• 一部テーマファイルのCSS修正。
• 静的出力時に埋め込みテキストを出力しないオプションを追加。
• MySQLにて記事テキスト本文に64KBまでしか保存できない問題を修正しました。（新規に作成した日記帳のみ有効）*1（Thanks to ひとぅ）
• rss10.html, rss10short.html, rss20short.html でRSSが生成できないバグを修正しました。（Thanks to 小沼）
• 次のような記述ができないコンパイラのバグを改善しました。

  <$ifexec(index(ENV.HTTP_USER_AGENT, 'iPhone')>=0, begin)>
  

• adiaryスーパーpre記法に行頭にスペースが1つ入ることがある仕様を改善しました。（Thanks to nblog）
• theme?xxx/xxx といったページ表示時にそのページを検索対象外にするmetaタグを出力するようにしました。
• 月別リストの古い年を折りたたむようにしました。（Thanks to G）*2
• C74で配布したbigblueを収録しました。
• C76で配布したyuuテーマを収録しました。
• 【携帯】コメントの表示件数を10件ごとにしました。

なお、メーリングリストにあるのようなiPhone専用テーマを作成したいときは次のような細工をしてください。（関連URL）*3

<$ifexec(Is_mobile, begin)>
	<$v.template_dir = "<@theme_dir>satsuki-mobile/">
	<$v.theme        = 'satsuki-mobile')>
<$end>

の後ろで

<$ifexec(0 <= index(ENV.HTTP_USER_AGENT, 'iPhone'), begin)>
      <$v.template_dir = "<@theme_dir>satsuki-mobile/">
      <$v.theme        = 'iphone'>
      <$Is_mobile=1>
<$end>

Ver2.11β1からの変更ファイル

• diary.skel/format/month_list.html
• lib/Satsuki/Diary.pm

*1 : 既存のテーブルに対してこの変更を行いたい場合は直接SQLを発行して修正してください。

*2 : この変更を直ちに適用するには、必要な場合は日記帳の設定を保存するか適当な記事を開いて保存してください。

*3 : Ver2系はこの辺を吸収するにはちょっと無理がありますね。

■Version2.00（β含む）以降からの乗り換え

• そのまま上書きしてください。
• Ver2.05以前の場合、uploader.conf.cgi をサンプルから再生成してください。

なおVer2.06よりアルバムシステム関連のJavaScriptの置き場が変更になっていますので、紛らわしい場合は theme/*.js を消してから上書きしてください。

アップデート方法の参考情報。

■Version1.44以前(C73/2.00α含む）以前からの乗り換え

Version2.00への移行処理を先に行ってください。

ひとぅ『2.11β版のリリース、ありがとうございます。 遅くなりましたがようやく導入してみました。 特に「月別リストの古い年を折りたたむ...』(2009/11/27 24:55)
なべ『ご要望感謝します。対応しました。 β2としてだそうかと思いましたが、このままリリースにもなりそうなのでちょい見送ります。』(2009/11/27 26:10)

■PostgreSQLの場合

PostgreSQLではそのままserial型というものがあり、

CREATE TABLE test(pkey SERIAL, x INT);
INSERT INTO test(x) VALUES(10);

とすることで、pkeyをプライマリキーとして自動的に生成することができます。

PostgreSQLではシーケンス操作関数というものがあり、SERIAL型を定義すると自動的に作成されます。

例えば、現在の値を取得したければ

SELECT currval(pg_catalog.pg_get_serial_sequence('test', 'pkey'))

とします。pkeyに値を設定して INSERT したとき、シーケンス関数は自動的に再定義されないため次の関数で再設定する必要があります。

SELECT setval(pg_catalog.pg_get_serial_sequence('test', 'pkey'), (SELECT max(pkey) FROM test))

現在の値（最後に生成された値）を取得するには次のようにします。

SELECT currval(pg_catalog.pg_get_serial_sequence('test', 'pkey'), (SELECT max(pkey) FROM test))

同じセッション内でテーブル問わず最後に生成された値を取得する場合は次で済みます。

SELECT lastval()

安全に（他のセッションともかぶらない唯一無二な）次のシリアル値を取得するには、次のようにします。

SELECT nextval(pg_catalog.pg_get_serial_sequence('test', 'pkey'))

■MySQLの場合

MySQLの場合auto_increment属性を使用します。

CREATE TABLE test(pkey INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, x INT);
INSERT INTO test(x) VALUES(10);

で、pkeyに自動的にシリアル値を設定することができます。

• AUTO_INCREMENTは１つのテーブルに１カラムしか指定できない。
• AUTO_INCREMENTを指定したカラムに、例えばpkeyを指定してINSERTしても、AUTO_INCREMENTがよきにはからってくれる（PostgreSQLのように値を再設定する必要なし）。

現在の値（最後に生成された値）を取得するには次のようにします。

SELECT * FROM test WHERE pkey IS NULL;
SELECT LAST_INSERT_ID();

ただしC API等では mysql_insert_id()というものがあるため、こちらを使用するほうが効率が良いようです。例えばPerl DBIならば $sth->mysql_insertid。

値を取得、値の変更

SHOW TABLE STATUS WHERE NAME = 'test';

で得られたテーブル情報の中からAuto_incrementカラムの値を参照します。得られるのは次に挿入される値です。

何かの都合で値を設定するときは次のようにします。

ALTER TABLE test AUTO_INCREMENT=1;

安全に次の値を取得

MySQLでもっとも厄介なのはこれです。auto_incrementには安全に次の値を得る方法が提供されていません。別にシーケンステーブルを作る方法などがありますが、面倒です。

INSERTでしか得られないならINSERTしてしまえばいいやという単純な方法です。

INSERT INTO test() VALUES();
DELETE FROM test WHERE pkey=LAST_INSERT_ID();
SELECT LAST_INSERT_ID();

NOT NULL制約等が付いているとINSERTが失敗するので、CREATE TABLE等であらかじめ制約を満たすDEFAULT値を設定しておく必要があります。MyISAMではトランザクションが使えないため、NOT NULLかつUNIQUE制約が付いていると、複数のプロセスが同時に"INSERT INTO test() VALUES();"を実行したとき一方が失敗します。

MySQLの場合はINSERTしてUPDATEした方がスマートなのはたしかなのですが、PostgreSQLではシーケンス型の次の値を安全に取得できるし、INSERTに成功してUPDATEに失敗した場合を考えるとややこしいので。

■頒布物の修正情報

http://adiary.jp/C76 を参照ください。

nasano『本日はお疲れ様でした。 しかし東方の人気は凄いですね…。 スペースに辿りつくまで何度も心が折れそうになりました（笑）。』(2009/08/15 22:20)
なべ『自分は経験したことのない混雑で、前に見える島には「正直、近寄りたくない」という感じでした（笑） あのひどい中、ご足労頂きありがと...』(2009/08/15 24:21)

■PostgreSQLのトランザクションの仕様

CREATE TABLE test(x INT UNIQUE);
INSERT INTO test (x) VALUES (1);
INSERT INTO test (x) VALUES (2);

としておきます。

ここで、

 => BEGIN;
 => INSERT INTO test (x) VALUES (3);
INSERT 0 1
 => INSERT INTO test (x) VALUES (1);
ERROR:  duplicate key value violates unique constraint "test_x_key"

とするとエラーになります。PostgreSQLはトランザクション中にエラーが起こると、以後何をしてもエラーになり受け付けなくなります。ためしに続けて色々発行してみても、

 => INSERT INTO test (x) VALUES (10);
ERROR:  current transaction is aborted, commands ignored until end of transaction block
 => INSERT INTO test (x) VALUES (20);
ERROR:  current transaction is aborted, commands ignored until end of transaction block

こんな感じです。COMMITすると

 => COMMIT;
ROLLBACK

このようにROLLBACKされます。これがPostgreSQLの仕様です。

■DBD::Pgの謎

• 確認環境
  • PostgreSQL 8.3.7
  • DBD::Pg　Ver1.49

DBD::Pgの場合

01: $dbh->begin_work;
02: $dbh->do('INSERT INTO test (x) VALUES (10)');
03: $dbh->do('INSERT INTO test (x) VALUES (1);');
04: $dbh->do('INSERT INTO test (x) VALUES (20);');
05: $dbh->commit;

とすると、3行目でエラーが起こり、4行目の実行でも"ERROR: current transaction is aborted, commands ignored until end of transaction block"といわれます。

これを、DBIのprepareを使用して

01: $dbh->begin_work;
02: $dbh->prepare('INSERT INTO test (x) VALUES (?)')->execute(10);
03: $dbh->prepare('INSERT INTO test (x) VALUES (?)')->execute(1);
04: $dbh->prepare('INSERT INTO test (x) VALUES (?)')->execute(20);
05: $dbh->commit;

とすると、3行目でエラーが起っても、4行目の実行が反映されてしまいます。謎の挙動です。

■謎の解析

このようにソースを改変してログを取ってみました。

open(my $fh, ">pg_log.txt");
$dbh->pg_server_trace($fh);
$dbh->begin_work;
$dbh->prepare('INSERT INTO test (x) VALUES (?)')->execute(10);
$dbh->prepare('INSERT INTO test (x) VALUES (?)')->execute(1);
$dbh->prepare('INSERT INTO test (x) VALUES (?)')->execute(20);
$dbh->pg_server_untrace();
close($fh);

このときサーバに対して次のようなコマンドが発行されていました。

 => BEGIN;
 => INSERT INTO test (x) VALUES (10);
 => INSERT INTO test (x) VALUES (1);
エラー : duplicate key value violates unique constraint "test_x_key"
 => ROLLBACK;
 => BEGIN;
 => INSERT INTO test (x) VALUES (20);
 => COMMIT;

どうりで最後のCOMMITが成功するはずです。取得した生ログも置いておきます。

これを、

01: $dbh->begin_work;
02: $dbh->prepare('INSERT INTO test (x) VALUES (10)')->execute();
03: $dbh->prepare('INSERT INTO test (x) VALUES ( 1)')->execute();
04: $dbh->prepare('INSERT INTO test (x) VALUES (20)')->execute();
05: $dbh->commit;

とすると再現しません。prepare中にUNIQUE制約をチェックして、勝手にrollbackしているようですが、原因がPostgreSQL側なのかDBD::Pg側なのかは絞り込めませんでした。

追記

DBD::Pgの実装仕様みたいです。トラックバックを参考にしてください（iakioさんに感謝）。

DBD::Pgを直すとすれば、プレースホルダが破棄されてもトランザクションが終了するまでDEALLOCATEするのを待つ、くらいでしょうが。

明示的なトランザクション内でのエラーとDEALLOCATE

ROLLBACKしていいから、DEALLOCATE後に空のトランザクションを begin して、失敗させてくれればそれで十分な予感。

■メモ

• どちらの場合も $dbh->commit(); の戻り値は "1" で成功している。

[Perl][PHP]明示的なトランザクション内でのエラーとDEALLOCATE （iakioの日記）

*1 : 仕様の汚い場所を思想を持って直してる。

*2 : と言ってもVer1.00よりずっと昔のβ時代

■結局

消しました。実装がとてもすっきりしました。