[pgsql-jp: 35421] Re: pgpoolのデッドロック

[杉 東]

杉です。

早速のご回答、ありがとうございます。
いきなりで申し訳ないのですが・・・

> V2.5.2より問い合わせが"SELECT"で始まっていたら(大文字小文字無視)，たと
> えstrictモードであってマスタの完了を待たずにセカンダリに問い合わせが発
> 行されます．
> # この仕様自体バグっぽい
> 申し訳ないのですが，SELECTの前にSQLのコメントを入れて，
>
> /*STRICT*/SELECT * FROM T_ TEST_TBL WHERE DAT_ID=10001 FOR UPDATE
こちらのパターンでもテストを行いましたが、結果は同じでした。
もしかしてV2.5.2より前のバージョンでは起こらない問題なのでしょうか？

お手数では御座いますが、宜しくお願い致します。


> -----Original Message-----
> From: pgsql-jp-bounces ＠ ml.postgresql.jp
> [mailto:pgsql-jp-bounces ＠ ml.postgresql.jp] On Behalf Of Tatsuo Ishii
> Sent: Thursday, May 26, 2005 8:35 PM
> To: pgsql-jp ＠ ml.postgresql.jp
> Subject: [pgsql-jp: 35419] Re: pgpoolのデッドロック
>
> 石井です．
>
> > 杉と申します。
> >
> > 過去の話題にもありましたが、pgpoolのデッドロックで悩んでおります。
> > ※【[pgsql-jp: 33983] pgpool でデッドロック？】
> >
> > 以下のクエリを繰り返すJSPを、負荷ツールから何度も呼び出す方法でテストを
行いました。
> > 　　【JSP内で発行するクエリ】(AUTOCOMMITは'off'にしています。)
> > 　　　SELECT * FROM T_ TEST_TBL WHERE DAT_ID=10001 FOR UPDATE
> > 　　　commit
> >
> > pgpool側の設定も変更しながら試してみましたが、デッドロックは解消されませ
ん。
> > 例えば、
> > 　　replication_strict = true
> > 　　replication_mode = true
> > 　　load_balance_mode = true
> > 　　weight_master = 1
> > 　　weight_secondary = 0
> > 　　この場合、通常はweight_secondaryには問い合わせが行かないと解釈してい
ますが・・・
> > です。
>
> この場合，問題の問い合わせは明示的なトランザクションの内側にあるので，
> ロードバランスの対象になりません．したがって，weight_*は適用されず，マ
> スタとセカンダリの両方に必ず問い合わせが送られます．
>
> > master側及びslave側でのロック状況も確認しましたが、繰り返している内に先
にslave側が
> > 先にロックをかけているようです。(クエリの前に/*シリアル番号*/を入れて確
認しました。)
>
> V2.5.2より問い合わせが"SELECT"で始まっていたら(大文字小文字無視)，たと
> えstrictモードであってマスタの完了を待たずにセカンダリに問い合わせが発
> 行されます．
> # この仕様自体バグっぽい
> 申し訳ないのですが，SELECTの前にSQLのコメントを入れて，
>
> /*STRICT*/SELECT * FROM T_ TEST_TBL WHERE DAT_ID=10001 FOR UPDATE
>
> として試していただけないでしょうか？
> --
> Tatsuo Ishii
>
>