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

[Tatsuo Ishii]

石井です．

> こんばんは。加澤です。HA チャレンジの続報です。
> 
> // いい加減うっとうしいですね。すみません。

いえいえ，こういう報告は少くとも開発者にとってはとても嬉しいです．

pgpoolのような単純なレプリケーションソフトでも，いろんなことがからむと
結構複雑な振る舞いを示すことがあるので，そのあたりのことを確認していた
だいた情報はとても貴重なノウハウになると思います．

> とりあえず、
> ・参照時は明示的に ACCESS SHARE ロックをかける
> ・更新時も明示的に ACCESS EXCLUSIVE ロックをかける
> とすることでうまく動くようになったかに見えたのですが、さらにいろいろテス
> トしているうちにまた新たな (というか間抜けな) 問題に当たりました。
> 
> ご存じの通り ACCESS EXCLUSIVE ロックは全てのロックと競合するため、このま
> まの状態では pg_dump も concorrent vacuum もかけられないことに気が付きま
> した(^^;。正確にはどちらも実行可能ですが、実行中トランザクションがロック
> してしまいます。これはイタい。
> 
> 改めて考えてみると、そもそも、どうして ACCESS EXCLUSIVE ロックを使ってい
> たのかと言えば、SELECT で暗黙にかけられる ACCESS SHARE ロックと競合させ
> たかったがためで、現在のように参照時にも明示的にロックをかけることにした
> のであれば、ACCESS SHARE/ACCESS EXCLUSIVE などという一番強力なロックを使
> う必要はないのでした。
> 
> そこで、利用するロックを ROW SHARE/EXCLUSIVE に切り替えたところ、これま
> で通りそれなりにちゃんと動作しつつ、無事 pg_dump や vacuum も平行して動
> 作させられるようになりました (正確には更新と vacuum は同時に動けません
> が、このくらいならば許容範囲です)。
> 
> // 同じ話として、OID の生成をシリアライズするために行っている
> // pg_database へのロックも、ACCESS EXCLUSIVE のままではちと
> // 強力すぎたため EXCLUSIVE へ変更しました。

なるほど．

> 今回のアプリケーションでは、テーブル設計時にかなりきちんと外部キーなどの
> 定義を行ってみていました。中には ON DELETE CASCADE や ON DELETE SET NULL
> などをセットしたものもありました。つまりそれらの制約により、暗黙に対象
> テーブル以外のテーブルが操作され、その際に異なる順序でロックが確保される
> ことがあったのです。
> 
> 具体的には、参照元のテーブルを更新する際には、参照元に ROW EXCLUSIVE
> ロックがかかった後に参照先のテーブルに ROW SHARE ロックがかかります。
> ON DELETE SET NULL などがセットされている参照先のテーブルを DELETE した
> 場合には、参照元のテーブルに ROW EXCLUSIVE ロックがかかってから、参照先
> のテーブルに ROW EXCLUSIVE ロックがかかることが分かりました。
> 
> これら暗黙の更新に伴うロック順を確認して、順序が違うものはあらかじめ正し
> い順序で明示的にロックを行うようにしたところ、とりあえず deadlock は起こ
> らなくなりました。
> 
> // 「TRIGGER や REFERENCES はトラブルの元」という話はよく
> // 聞いてはいましたが、これほど実感したのは初めてかも(^^;。

そうですか．PostgreSQL単体でもこのトラブルはたまに見ますね．

なお，今開発中の8.1では，この手のロックをもっと軽いものにする計画があ
るようです．
--
Tatsuo Ishii