他のバージョンの文書9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

17.11. ロック管理

deadlock_timeoutinteger

これは、デッドロック状態があるかどうかを調べる前にロックを待つ時間をミリ秒で計算したものです。デッドロックのチェックは比較的遅いので、サーバはロックを待つ度にこれを実行するわけではありません。(楽天的ですが)デッドロックは実用レベルのアプリケーションでは頻繁に発生しないと仮定し、デッドロックのチェックを開始する前にしばらくはロック待ちをします。この値を増やすことにより必要のないデッドロックのチェックで無駄にされる時間は減りますが、本当にデッドロックがあった場合の報告が遅れます。デフォルトは1000(つまり1秒)で、おそらく実用の際にはこれ以上は必要でしょう。負荷の大きいサーバではもっと必要かもしれません。理想としてはこの設定は通常のトランザクションにかかる時間を超えているべきです。 そうすればロック待ちトランザクションがデッドロックのチェックをする前にロックが解除される可能性が改善されます。

max_locks_per_transactioninteger

共有ロックテーブルは、max_locks_per_transaction * (max_connections + max_prepared_transactions)オブジェクトにロックを記述する余裕を持って作成されます。したがって、この数以上の明確なオブジェクトはいつでもロックされます。(ですから、このパラメータ名は紛らわしいですね。いかなる1つのトランザクションにより取られるロック数は厳しい制限ではありませんが、最大平均値がむしろ問題です。)デフォルトの64は、経験的に十分であると証明されていますが、単一のトランザクションで数多くの異なるテーブルをいじるクライアントがいる場合、この値を大きくする必要があるかも知れません。このオプションはサーバ起動時のみ設定されます。

このパラメータを増加すると、使用しているオペレーティングシステムのデフォルト構成が許容するSystem V共有メモリの限界を越えた要求を PostgreSQLが行う原因となることがあります。必要であれば、どの様にしてこのパラメータを調整するかについて項16.4.1を参照ください。