[pgsql-jp: 35287] Re: pgpoolのreplication_stop_on_mismatch について

[Tatsuo Ishii]

石井です．

> 石井さんのおっしゃるとおり、SELECT を明示的なトランザクションブロックに
> 含めるだけでトランザクション終了まで ACCESS SHARE ロックが確保されたまま
> となるようになり、目的通りの動作とすることが出来ました。どうもありがとう
> ございます。

それはよかったです．

> // 僕のロックに関する知識が足りませんでした。すみません。

いえ，このあたりは結構ややこしい話なのでしょうがないと思います．

> ちなみに今回も、最終的には目的の動作をさせることが出来るようになったので
> すが、当初「更新時の ACCESS EXCLUSICE ロック＆参照時の ACCESS SHARE ロッ
> ク」対応コードを入れたとたん、deadlock が多発してしまって難儀しました。
> 更新時のロック順序はそれなりに意識していたんですが、参照時はほとんど意識
> していなかったため典型的な deadlock のパターンにはまり込んでしまいまし
> た…。コード全体を見直し長いトランザクションでのロック順序を厳密に守るよ
> うにして何とか解決。
> 
> // そういえば複数のテーブルを join している場合のロック
> // 確保順序ってどうなっているのでしょうか？
> // 今回はよく分からなかったのでそういう SQL の前に明示的
> // に LOCK TABLE 〜 IN ACCESS SHARE MODE しちゃいました。

たぶん「不定」というのが答えだと思います．単に実行するときにたまたま開
く必要のあるテーブルからロックがかかっていきます．ですから，実行プラン
によってもロックの順序が変ってくるはずです．結局，JOINの場合は明示的に
ロックするのが正解ですね．
# VIEWやユーザ定義関数の中で，暗にテーブルをアクセスしているとちょっと
# やっかい．

> > この問題が結構解決が難しくて，仮に2PC(2 phase commit)が導入されても解
> > 決されません．たぶんshared nothing方式のクラスタの宿命ではないかと思い
> > ます．
> 
> そうなんですね。勉強になりました。
> 僕のように HA を目的として pgpool を使う人もそれなりにいるのではないかと
> 思いますが、そのような構成でちゃんと動かすためには結構アプリケーション側
> のケアが必要なのですね。

実はこのあたりはあまり深く考えていなかったと言うか「原理的にはアプリケー
ションで対応できる範囲なのでまあいいか」と思っていました．こういう実経
験に基づくノウハウはpgpoolを使いこなす上で非常に貴重ですね．そのうち
「pgpool FAQ」みたいなものを作りたいと思っているので，その節は是非採用
させてください．

> > pgpool同士でハードビートや情報交換ができるようにすれば解決できると思う
> > のですが...
> 
> おっしゃるとおりですね。
> でも、そうやってどんどん機能を入れていってしまうとせっかくの今の pgpool
> のシンプルさが失われてしまいそうだったりして、その辺のさじ加減はなかなか
> 難しいところでしょうか。ハートビート交換くらいならばそれほど難しくならな
> いのかな…。

「pgpool監視サーバ」のようなものを作れば実装的には簡単だと思うのですが，
それだとそのサーバがsingle point of failureになってしまうのでつまりま
せん．ここは是非pgpool同士の情報交換だけで済ませるという分散処理でいき
たいですね．これは「局所的な情報から全体的な情報を再構成する」という分
散処理の古典的な問題の一つなので，たぶん山ほど文献があると思います．
# ていうか，たしかにそういう論文を読んだことがある...
そのうち勉強して実装してみます．

> それではまた。いつもどうもありがとうございます。

どういたしまして．
--
Tatsuo Ishii