[pgsql-jp: 36710] Re: pgpool使用時のSERIAL型の取り扱いについて

Motoki Ito m_itoux @ yahoo.co.jp
2006年 2月 10日 (金) 10:53:58 JST


伊藤です。

> 石井です.
> 同期が取れない原因は,load_balance_modeが有効になっていて,
ご回答ありがとございます。

> select nextval('hoge_seq')
> 
> がmasterかsecondaryのどちらか一方にしか発行されないからです.
> 
> load balance modeは,明示的なトランザクションブロックになっている(成功
> 例1)か,select文が正確に"SELECT"(大文字小文字の違いは無視)で始まってい
> ない(成功例2)では無効になるので,いまくいくわけです.
> 
> ちなみに,insert_lockは,INSERT文でないと効かないので,ここではうまく
> 働いていません(insert_lockは,sequenceではなく,SERIAL型と一緒に使うこ
> とを想定しています).
下記のようなテーブルに対しての下記のようなSQLの場合であればserial値がず
れてしまう事はないということですね。
insert into hoge (data1) values('test');

 Column |  Type   |
--------+---------+-------------------------------------------------
 seq    | integer | default nextval(('"hoge_seq"'::text)::regclass)
 data1  | text    |  

> ところで,「成功例」ということですが,select nextval('hoge_seq')を発行
> するセッションが同時に複数あるとうまくいかないと思います.複数同時セッ
> ションでもうまくいくようにするためには,たかだか一つのセッションしか同
> 時にはselect nextval('hoge_seq')を実行できないように制御しなければなり
> ません.一番いいのは,テーブルロックを使って,
> 
> BEGIN;
> LOCK TABLE t1; <-- どんなテーブルでもいい
> select nextval('hoge_seq')
> :
> :
> END;
> 
> とすることです.
なるほど、自分ひとりでしか使っていない環境下でのテストでしたので問題なかっ
たということですか。
同時複数セッションがありえますので、上述のように対応するしかなさそうです。
ご指摘ありがとうございます。

> そうではなくて,同時セッションがないのであれば,上記成功例で問題ありま
> せん.その場合,SQL文に手を入れずに目的を達成したいのであれば,
> load_balance_modeを無効にするしかないでしょう.
無効にするのが一番楽そうなのですが、今回pgpoolを導入した目的の一つに、検
索性能の向上があるため、ロックの方で対応していきたいと思います。

わかりやすい回答ありがとうございました。

--------------------------------------
GANBARE! NIPPON!
Yahoo! JAPAN JOC OFFICIAL INTERNET PORTAL SITE PARTNER
http://pr.mail.yahoo.co.jp/ganbare-nippon/



pgsql-jp メーリングリストの案内