18.12. ロック管理

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

log_lock_waitsが設定された場合、このパラメータはロック待機に関するログメッセージを出力する前の待機時間を決定します。 ロック遅延の調査を行う場合は、通常のdeadlock_timeoutよりも短い値を設定することを勧めます。

共有ロックテーブルは、max_locks_per_transaction * （max_connections + max_prepared_transactions）オブジェクト（例えばテーブル）上のロック追跡します。 したがって、ある時点でこの数以上の個々のオブジェクトをロックすることはできません。 このパラメータは各トランザクションで割り当てられるオブジェクトロックの平均値を制御します。 個々のトランザクションでは、このロックテーブルにすべてのトランザクションのロックが収まる限りオブジェクトのロックを獲得できます。 これは、ロックできる行数ではありません。この値には制限がありません。 デフォルトの64は、経験的に十分であると証明されていますが、単一のトランザクションで数多くの異なるテーブルをいじるクライアントがいる場合、この値を大きくする必要があるかも知れません。 このパラメータはサーバ起動時のみ設定されます。

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

スタンバイサーバを稼動するとき、このパラメータをマスターサーバと同じか、より高い値に設定しなければなりません。 そうしないと、問い合わせはスタンバイサーバでは許可されません。

共有記述ロックテーブル（shared predicate lock table）は、max_pred_locks_per_transaction * (max_connections + max_prepared_transactions)オブジェクト（例えば諸テーブル）のロックを追跡します。 従って、この数以上の明確なオブジェクトは同時にロックされません。 このパラメータはそれぞれのトランザクションに対して割り当てられたオブジェクトのロックの平均数を管理します。 個別のトランザクションはロックテーブル内の全てのトランザクションのロックが適合する限り、より多くのオブジェクトをロックできます。 これはロック可能な行数ではありません。その値は無制限です。 デフォルトは64で、テストでは一般的に充分ですが、単一のシリアライザブルトランザクションで数多くの異なるテーブルに触れるクライアントが存在する場合、この値を大きくする必要があることがあります。 このパラメータはサーバ起動時のみ設定可能です。

このパラメータを大きくするとオペレーティングシステムのデフォルトの設定が許容している以上のSystem V共有メモリをPostgreSQLが要求することがあります。 これらパラメータをどのように調整するかについて、必要であれば項17.4.1を参照してください。