RPMとtarball、混ぜるな危険

年明け早々、会社のシステムに関して不具合報告が来る。原因を調べると、全く同じ定義の二つのテーブルに対し全く同じSQLなのに、片方のテーブルでは結果取得時にphpが静かに落ちてしまう。psqlコンソールから入力すると問題なく結果が出る。なんだこりゃ?

いろいろ調べてたどり着いた結論(仮説)は、PostgreSQLのバージョン。OSはx86_64のCentOS 4.6でほとんどがRPMパッケージで固めてあるのですが、このバージョンのCentOSで提供されるPostgreSQLが7.4。システム構築時点での最新版PostgreSQL 8.1はパフォーマンスが大幅に改善されたということだったので、こいつだけtarballからコンパイルして使っていたのです。

で、PostgreSQL 7.4でデータベースアクセス用に提供されているライブラリがlibpq.so.3、一方8.1はlibpq.so.4の使用を要求します。phpはRPMパッケージなのでlibpq.so.3を使ってアクセスしようとするわけで、ここでバージョンの不整合が発生しているのです。・・・よく今までこんなのが動いていたな。

では、phpもtarballでコンパイルしましょうかと挑んだところ、やれこのライブラリのバージョンが古いだとか、エラー続出で早々に断念。ではSRPMで--with-pgsql=shared→/usr/local/pgsqlとphp.specを編集してrpmbuildするも、コンバイル後の動作テストでFail(*1)。

結局、CentOS PlusのPostgreSQL 8.1 SRPMLink を取ってきてコンパイル、その後それを使ってphp SRPMのコンパイル(エラー出すのでlibc-clientも)、ついでにPostgreSQLに依存するdovecotのSRPM、さらにこれらのSRPMが依存する-develパッケージのインストールと、大掛かりな作業をやって、やっと動作検証機で動作しました。

さぁ、明日は本番機に適用だ。

(*1) 32bit環境だともしかすると動くかも。コンパイルログを見るとOIDの型がunsigned int(4バイト/PostgreSQL)とlong(8バイト/php)となっており、数値比較で常にFalseとなる論理式があるとWarning出てたので。

[参考]Hatena::Question 【総額1000ポイント】PHPとPostgreSQLの連携がうまくいきません。Link

[2008/2/8 追記] 本番機に入れたら、不具合が改善しない・・・テーブルのアクセス制限が狂っていたのが原因でした orz

— posted by mu at 10:50 pm   commentComment [0]  pingTrackBack [0]

T: Y: ALL: Online:
ThemeSwitch
  • Basic
Created in 0.0091 sec.
prev
2008.2
next
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29