[pgcluster: 893] Re: pgbench で固まってしまいます

[Y. Shimada]

三谷さん、お元気ですか？

　私も、いまだロックにハマっています。。
（グラスと氷と hogehoge なら良いのですが。。）

ところで、クエリベース・レプリケーションにおいて、
独立な複数のデータベースインスタンスが、複数の同時接続から
他のトランザクションと関連する行（競合するタプル）の更新を
行なう状況で、データベースの整合性を保ち続けること、または、
レプリケーションサーバでのデッドロックを未然に防止するには、
以下お考えのように、ロックを開放する順番でなく、全プロセスが
ロックを取得する順番を、全クラスタDBに渡って同一にするか、
どこかで、シリアライズする事は必要と思っています。
（開放されたロックを、順番待ちしている誰がとるか？）

　この時、PostgreSQL が採用している共有バッファベースの
複数プロセスモデルでは、各クラスタサーバでの、ロック取得順序を
互いに通知しあい、かつ、調停役が必要になるかと思います。
レプリケーションサーバが、その役を。。と思うのですが。。


On 2006/07/14, at 0:37, a.mitani ＠ sra-europe.com wrote:

> 浅羽さん，こんにちは．
>
> 1.3まではご指摘の通りです．
> 1.5ではネステッド・トランザクションのおかげで事情が更に複雑化 
> しております．
>
> これはもう，ロック管理の方法を根本的に見直すしかないと思ってお 
> り，方法を模索
> 中です．
> どのロックが先に解除されるか，ロックされた時点では判断できない 
> のでキューイン
> グするのは解決方法になりませんし，レプリケーションサーバ側から 
> コントロールで
> きない問題なのでClusterDB側に何らかの仕掛けが必要になり 
> ます．
> いっそのことセマフォをシェアしたらどうだろう，
> と思ったのがPGCluster-IIの発想の発端です．

>>
>> では、なぜ PGCluster でデッドロックが発生するかという 
>> と、PostgreSQL の
>> 行ロック獲得アルゴリズムが原因になります。PostgreSQL で 
>> は、行ロックを
>> すでに獲得しているトランザクションがあると、他のトランザク 
>> ションは待た
>> されます。これは普通の挙動ですね。で、行ロックを持っているト 
>> ランザクショ
>> ンが終了すると、一斉に複数のクライアントが行ロックを奪いにい 
>> きます。こ
>> こにレースコンディションが存在し、次にどのクライアントがロッ 
>> クを獲得す
>> るかわからない状況になります。
>>

---
Y.Shimada