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

[Tatsuo Ishii]

石井です．

> 杉です。
> 
> 早速のご回答、ありがとうございます。
> いきなりで申し訳ないのですが・・・
> 
> > 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
> >
> >
>