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

[杉 東]

杉です。

度々で申し訳ないです。
まずはV2.5.1で調査する事になりました。
出来れば再度、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 10:42 PM
> To: pgsql-jp ＠ ml.postgresql.jp
> Subject: [pgsql-jp: 35422] Re: pgpoolのデッドロック
>
> 石井です．
>
> > 杉です。
> >
> > 早速のご回答、ありがとうございます。
> > いきなりで申し訳ないのですが・・・
> >
> > > V2.5.2より問い合わせが"SELECT"で始まっていたら(大文字小文字無視)，たと
> > > えstrictモードであってマスタの完了を待たずにセカンダリに問い合わせが発
> > > 行されます．
> > > # この仕様自体バグっぽい
> > > 申し訳ないのですが，SELECTの前にSQLのコメントを入れて，
> > >
> > > /*STRICT*/SELECT * FROM T_ TEST_TBL WHERE DAT_ID=10001 FOR UPDATE
> > こちらのパターンでもテストを行いましたが、結果は同じでした。
>
> そうですか．それにしても変ですね...
>
> > もしかしてV2.5.2より前のバージョンでは起こらない問題なのでしょうか？
>
> はい，そうです．
> # でも，2.5.2でも/*STRICT*/を入れれば問題は起きないはずなのですが．
> --
> Tatsuo Ishii
>
> > お手数では御座いますが、宜しくお願い致します。
> >
> >
> > > -----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
> > >
> > >
> >
>
>