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

[Yoshiyuki Asaba]

浅羽です。

From: "Y. Shimada" <yshim_pgsql ＠ storgate.co.jp>
Subject: [pgcluster: 893] Re: pgbench で固まってしまいます
Date: Fri, 14 Jul 2006 11:21:07 +0900

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

pgpool の場合は、上記方法を使ってデッドロックを防止しています。

  マスタに投げる -> セカンダリに投げる

という順番で待ちます(replication_strict = true の場合)。

あと、8.1.x に LockTuple() という関数が入ったようなので、これを調べて
みたのですが、行ロック取得の順序を保証するようなものではありませんでし
た。

ということで、三谷さんの分散共有メモリの実装を楽しみにしております。
--
Yoshiyuki Asaba
y-asaba ＠ sraoss.co.jp


> 　この時、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
>