[pgsql-jp: 33639] Re: pgpool 2.0.2 報告
Tatsuo Ishii
t-ishii @ sra.co.jp
2004年 7月 13日 (火) 12:08:29 JST
石井です.
> パケット長のチェックだけでしたか。バイナリチェックなんてして
> いたらレスポンスが悪すぎますかね。
パケットの中身がバイナリとして完全に一致しているかどうかを調べることも
できますが,そんなことするとトランザクションID(xmin, xmaxフィールド)が
違うだけでエラーになってしまいます.トランザクションIDはSELECTするだけ
でカウントアップしますし.
> ここで「新たな疑問」が出るのですが、1行の長さチェックだけな
> らば、西尾さんの報告された([pgsql-jp: 33436])ケースがエラー
> となる理由がわかりません。ORDER を付けるか付けないかにより、
> タプルの順序が異なるだけで、カラムの数、タプルの数、(あの場
> 合 int と 1文字text だけなので)1行の長さ、全て一致しているハ
> ズですよ・・ね??
西尾さんの場合,実際のデータはそんな単純なものではないようです.また,
「子プロセスが消える」とか,不可解な現象が起きているようで,Solarisの
せいかどうかわかりませんが,何か未知の問題が絡んでいるような気がします.
> V2.0.1, V2.0, バイナリチェック と、厳密さを選択できると良い
> かもしれませんね。
誰かパッチを...:-)
> !!!たしかに。
> まずい・・・と思ったのですが、テーブルロックをすれば、セッショ
> ン2 は セッション1 を待つので問題ないですね(?デッドロックし
> ちゃう??)。
そうですね.
> そもそも、最大値+1 をユーザー定義関数でテーブルロックせずに
> しようというのが間違っていた、って事ですね(前、本MLで自分が
> そう言ってたような(恥))。
ただ,ユーザ定義関数の中でロックしても大丈夫かどうかは検討の必要がある
ような気がします.
> (begin - commit で挟んで STRICTモードを強制しても)
> S1:Session1 S2:Session2 P:Primary S:Secondary
> ↓こうなることを期待しているが、
> S1 P begin max++ insert commit val:1
> S begin max++ insert commit val:1
> S2 P begin max++ insert commit val:2
> S begin max++ insert commit val:2
>
> ↓こうなる可能性がある
> S1 P begin max++ insert commit val:1
> S begin max++ insert commit val:2
> S2 P begin max++ insert commit val:2
> S begin max++ insert commit val:1
>
> ↓ロックすればOK(たぶん)
> S1 P b lock mx++ i c
> S b lock mx++ i c
> S2 P b (wait)........... lock mx++ i c
> S b (wait).............. lock mx++ i c
> b:begin mx++:max++ i:insert c:commit
> (wait)Lock解除待ち
> > 置き換え用の関数を作るとしたら,マスタとセカンダリで同じ値を必ず返す保
> > 証をする仕掛けを別に考える必要があると思います.たぶん,マスタの関数と
> > セカンダリの関数が,直接あるいは間接に通信しあうようなことが必要になる
> > でしょう.
>
> ですね。大掛かりになってきますね。
> 解決方法がどれになるにせよ、pgpool を使うにあたり「できなく
> なること」をまとめ、それを避ける方がよさそうですね。
> 結局、石井さんがおっしゃってた「頭の痛いところ」に戻ってしま
> いました。じっくり考えましょうw。
まず「できないこと」リストはきちっとまとめる必要がありますね.
# ただいまラージオブジェクトではどうなるかを検討中
--
Tatsuo Ishii
pgsql-jp メーリングリストの案内