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

[Jun Kitamura]

北村です。

> > master と secondary の値が違えてしまうケースとして、更新・追
> > 加時の current_timestamp や random() が 考えられますが、これ
> > の対策ってなされてるのでしょうか・・・？(current_timestamp 
> > は時計合わせとけって話なんですが)
> 
> 基本的に、この種の問い合わせベースレプリケーションでは「SQLを繰り返し実
> 行しても同じ結果が得られる」という前提の上に成り立つため、now()やrandom
> ()は使えません。これは、時計あわせしても無理です。
> 
> 逆に言うと、そういった部分をあきらめているからこそシンプルなpgpoolのよう
> なツールが成り立つわけです。

やはりそうですか。最初は、usogres はパケットレベルだったので
出来ないと諦めていたのですが、pgpool は SQL文を見ているよう
なので、random() をその場で置き換えれば良い、などと思ってい
ましたが、根本的に勘違いしてました(汗。
select random(); などのように、SQL文中に random() があるなら
まだしも、select f1(); (ユーザー関数 f1)のような場合、f1() 
中に random() が使われていたら、結局手も足も出ないんですよね。

> # じゃあPGClusterは？という話ですが、関数そのものに手を入れて実現して
> # います。これは、pgpoolの「backendに手を入れずに機能実現」では基本的に
> # 無理な話です。

ですね。PGCluster も検討対象ですが、バックエンドに手を加えて
いるので本家のリリースから後手に回ってしまいます。もちろん、
本家に採用されて導入されれば問題ないのですが。
(三谷さん、頑張ってくださいねｗ)。