[pgsql-jp: 31784] Re: PGCluster-1.0.6リリースしました

[Wataru Oguro]

oguroです。

三谷様、リリースお疲れ様でした。
早速パッチを当てて実験してみました。

-------
begin;
update test set a = 'test2' where a = 'test2';
commit;
-------
というSQLをPHPに組み込み、アパッチベンチで実行しました。

＊今まではクラスタサーバで2台同時にpsql -fで実行していましたが、アプリで
使用することを想定してCGIでの実行を行ないました。

$ab -c 4 -n 1 http://localhost/testcgi/test.cgi

＊上記は、4同時セッション、実行回数1という認識で行なっています。
　ここの認識が間違ってたら申し訳ないです。。。。

テーブルには1件しかデータは入っていません。
ですので、4つのセッションが同時に1件のレコードを更新することになるのです
が、あるタイミングで、レプリケーションサーバからのクエリがデッドロックを
おこすようです。。。

通常のデッドロックは、検出された後、ロックの元となるトランザクションのい
ずれかをアボートされますが（ログにもでますよね）、レプリケーションサーバ
からクラスターサーバへ送られたクエリーが元のデッドロックは検出できない＆
解除できないようです。（私なりの考察なので、間違ってたら指摘してください
ませ）

なぜそう見えるかというと、レプリケーションサーバが実行中のトランザクショ
ンがidel状態のままで、それ以降のクエリーが待ち状態となっているためです。
この状態は待っていても改善はされません。
レプリケーションサーバの再起動を行うか、クラスタサーバを強制的に停止しな
いとダメなようです。
後者を行なうと次回立ち上げ時はリカバリモードで立ち上げないとならないので
すが。。。

レコードロックがかかっているので対象のレコードには変更を加えられません
が、テーブルへは追加・削除が行なえます。

これが例えば
-------
begin;
lock table
update test set a = 'test2' where a = 'test2';
commit;
-------
というSQLだったとすると、テーブルロックがかかるため（EXCLUSIVEロック）
テーブルへのアクセスができなくなってしまいます。

クラスタサーバが自身に掛けるロックと、レプリケーションサーバが同期のため
に掛けるロックがバッティングしているような気がしてます。。。。

1.0.5からあった現象ですが、この問題を解決するのは難しそうですね。

以上　私なりの検証報告です。