やられました。。。
本日お客様のシステムで発生したトラブルの対応で、緊急リリース作業中です。
本日、お客様からシステムトラブルの連絡がありました。
ある情報を検索して、結果をリスト表示する画面が今日になって機能しなくなったとのこと。
初めは、このシステムにありがちな、データの問題かなと思っていて、ちょろっとDBいじればひとまずしのげると踏んでいました。
しかし、、、実はこればっちりプログラムのバグ!
しかも、時限バグ弾。。。
システムが長期間稼働して、データが増えると発現するバグだったのです。
名付けて、「時限バグ弾」!
どんなバグだったかというと、、、
PostgreSQLのSQLを生成するプログラムに問題がありました。
あるテーブルを検索してIDのリストを取得します。
次に、別のテーブルを検索するときに、whereにこのIDのリストをin句に入れた条件を加えます。
in句の作成は、プログラム上で文字列をつなぎます。
こんな感じ。
select * from hoge where sub_id in (?, ?, .....)
当初は全く問題なかったのですが、データが増えるにつれin句がどんどん大きくなったわけですね。
怪しいのはその変かなととは思ったのですが、初めは何が悪いのか分からず、、、ごめんなさい不勉強でした。
PostgreSQL 8.3.6の制限事項
そう、おそらくこの制限に引っかかってしまい、SQL例外になってしまっていたのです(ToT)
再現試験として、問題のデータ量で発生を確認し、データ量を減らすと発生しない事を確認しました。
間違いない、これだ!ということで、修正&テストしてただいまリリース媒体作成中。
修正はできたのですが、次の難関はインドと日本の間はどうやらN/W帯域が狭いという事。
自社のマシンにリモートでつないで、リリース媒体をつくり、そこから本番環境に転送するというまどろっこしい作業をしています。
う〜ん、、、眠たいす。
でも、緊急リリースは恐ろしいので、気合いでがんばります!
日本のインスタントコーヒー持ってきて良かったぁ。。。
本日お客様のシステムで発生したトラブルの対応で、緊急リリース作業中です。
本日、お客様からシステムトラブルの連絡がありました。
ある情報を検索して、結果をリスト表示する画面が今日になって機能しなくなったとのこと。
初めは、このシステムにありがちな、データの問題かなと思っていて、ちょろっとDBいじればひとまずしのげると踏んでいました。
しかし、、、実はこればっちりプログラムのバグ!
しかも、時限バグ弾。。。
システムが長期間稼働して、データが増えると発現するバグだったのです。
名付けて、「時限バグ弾」!
どんなバグだったかというと、、、
PostgreSQLのSQLを生成するプログラムに問題がありました。
あるテーブルを検索してIDのリストを取得します。
次に、別のテーブルを検索するときに、whereにこのIDのリストをin句に入れた条件を加えます。
in句の作成は、プログラム上で文字列をつなぎます。
こんな感じ。
select * from hoge where sub_id in (?, ?, .....)
当初は全く問題なかったのですが、データが増えるにつれin句がどんどん大きくなったわけですね。
怪しいのはその変かなととは思ったのですが、初めは何が悪いのか分からず、、、ごめんなさい不勉強でした。
PostgreSQL 8.3.6の制限事項
各々の語彙素の長さは2Kバイト未満でなければなりません
そう、おそらくこの制限に引っかかってしまい、SQL例外になってしまっていたのです(ToT)
再現試験として、問題のデータ量で発生を確認し、データ量を減らすと発生しない事を確認しました。
間違いない、これだ!ということで、修正&テストしてただいまリリース媒体作成中。
修正はできたのですが、次の難関はインドと日本の間はどうやらN/W帯域が狭いという事。
自社のマシンにリモートでつないで、リリース媒体をつくり、そこから本番環境に転送するというまどろっこしい作業をしています。
う〜ん、、、眠たいす。
でも、緊急リリースは恐ろしいので、気合いでがんばります!
日本のインスタントコーヒー持ってきて良かったぁ。。。
Comment
ご指摘ありがとうございます!
キャッシュヒットの問題は、PostgreSQLも同様ですね。
そもそも、inで可変のデータ渡して絞り込むなんて、どうなんだろうかと私も思っていまして、、、直したい気持ちは満々なのですが。。。
select結果のデータ矛盾については、あまり意識してませんでした(w)
まあ、あまりそのことを気にする必要はない機能なのですが。。。
でも、ご指摘は大変勉強になります。
ぜひ、システムの改善に役立てたいと思います。
仮に制限事項の長さ制限が無かったとしても、
SQLが可変するとPreparedStatementの効果が出ず、
オプティマイザが効果的にならない可能性があるかもしれません。
(PostgreSQLはあまり明るくないのですが、Oracleで言うところの
ライブラリキャッシュヒット率が下がります)
また、業務ロジックにもよるとは思いますが、事前の検索パターンを
副問い合わせ句にしたほうが、アトミックな処理になるので
データの矛盾が起こりにくいかと思います。
(同時に他のトランザクションが無ければ問題ありませんが)
コメントする