10. ロックの問題

PostgreSQL よる多版型同時実行制御(MVCC)の使用による通例の長所の 1 つは、これにより、合理的な全てのホストからデータベースオブジェクトにロックを掛ける必要性を省略させることです。他のいくつ化のデータベースシステムでは、テーブルにデータを挿入するためにテーブルロックを獲得しなければならず、それは厳しいほど性能を妨げます。他のシステムでは、書き込みロックは書き込みを妨げます。MVCC によりPostgreSQL は、"古い読み込み"におけるロックの全てのクラスが"古いタプル"にアクセスできるように削除します。殆どの時点で、このことは PostgreSQL の育ちの良いユーザにロックに多大の心配をしなくてもよいようにします。

残念なことに、 Slony-I の構成の変更は、"ロックの苛立ち"のようなことをもたらす結果を伴う、PostgreSQL テーブル上に排他ロックを必ず必要とする数種類の Slony-I 事象があります。特に以下のことがあります。

これらのそれぞれの行為は、ある時点で、影響を受けたレプリケーションセット内のそれぞれのテーブルの変更を要求し、それはそのテーブル上の排他的ロック獲得を必要とします。アプリケーションを能動的にサービスしている Slony-I ノード上でこれらの操作の稼働を試みたユーザの何人かは、デッドロック、および、もしくは操作のハングアップといった支障を経験しています。

明白な質問:"そのようなデッドロックにどう対処しますか。"

自身が認めるいくつかの可能性

残念ながら、この件に関する完全な回答は存在しません。もしも MOVE SET 要求を提出する必要があれば、それは多分短時間のアプリケーション停止を受け入れる必要があります。Slony-I/ pgpool 連結が改善されるにつれ、この問題を扱うより良い方法になるかも知れません。