[pgsql-jp: 33636] Re: pgpool 2.0.2 報告

[Tatsuo Ishii]

石井です．

> 以前、西尾さんが発見された「order by 問題([pgsql-jp: 33436])」
> の時は、1行全体のバイナリでチェックしていたって事ですかね(ソー
> ス見れば良いんで返答無用)。その後、ヘッダの長さのチェックだ
> けに変えた・・・と。ある意味、以前の方法ならば、primary と 
> secondary 間の厳密なチェックが可能なわけですね。捨てがたいか
> もｗ。

いや，以前の方法もそんなに厳密なわけではないです:-)

V2.0:
	行データのパケット長がマスタとセカンダリで違っていたらアウト

V2.0.1以降:
	行データのパケット長がマスタとセカンダリで違っていてもOK．単に
	セカンダリのデータを読み捨てる

> なるほど。デフォルトの STRICTモードであれば問題ないかと思い
> ましたが勘違いしていました。STRICTモードとは、あくまで 
> pgpool が primary と secondary の応答順序を守るというモード
> で、複数接続からのセッションの順番を守るものではないのですね。

はい．「複数接続からのセッションの順番を守る」というのは極めて難しい話
で，ある意味PostgreSQLが持っているトランザクション管理機構をすべて実装
しない限り無理です．もちろんがんばってpgpoolがトランザクションの順番を
管理することもできますが，その結果が単体のPostgreSQLで実行したものと同
じになる保証がなくなります．

> > 1) current_timestamp や random()を使用せず，アプリケーションの方で値を
> >    生成してSQL文に埋め込む．ただし，フロントエンドの間で時計がずれてい
> >    るとcurrent_timestampがずれる可能性はあります．
> > 
> > 2) （これは単なるアイデアレベルですが）pgpoolの中にそうした値を生成す
> >    る機能を入れる．そして値をSELECT文で取得できるようにしておき，それ
> >    をアプリケーションに使ってもらう．
> > 
> > 3) current_timestamp や random()そのものを入れ替える（同じような発想で，
> >    Slony-Iではシーケンス関数を入れ替えてます）．こうした方法が良いか悪
> >    いかは，議論のあるところだと思いますが．
> > 
> > まあ，今後どうするかはこれからじっくり考えたいと思います．
> 
> 3)が妥当な気がします。
> 当初、2)が良い(あるいは実装されている)かとも思いましたが、こ
> と random() で言えば、ユーザー定義関数内の random() などは 
> pgpool では拾えないのでどうしようもないです。となると、ユー
> ザー定義関数側で独自の擬似乱数関数を使うなどの方法になり、結
> 局 3) ですね。
> シーケンス(シリアル型)も、最大値+1 というユーザー定義関数を
> 作れば解決です(当然この場合、シーケンスの「番号先確保で高速
> 処理」の恩恵は受けられないですが)。

そうでしょうか？pgpoolではマスタの次にセカンダリが問い合わせを実行する
ことは(STRICTモードならば)保証されますが，複数のセッションが同時に走っ
た場合，セッション1のマスタの次にセッション2のマスタの問い合わせが実行
されたが，セッション1のセカンダリの問い合わせの前にセッション2のセカン
ダリの問い合わせが実行される，ということが起こり得ます．そうなると最大
値+1のユーザ定義関数を実行してもマスタとセカンダリで結果が異なってしま
うことになります．

置き換え用の関数を作るとしたら，マスタとセカンダリで同じ値を必ず返す保
証をする仕掛けを別に考える必要があると思います．たぶん，マスタの関数と
セカンダリの関数が，直接あるいは間接に通信しあうようなことが必要になる
でしょう．
--
Tatsuo Ishii