| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 17. 서버의 설정 | Fast Forward | Next |
이것은, 데드 록 상태인 경우에, 검사하기 전에 락을 기다리는 시간을 밀리 세컨드로 계산한 것입니다. 데드 록의 검사는 비교적 느리기 때문에, 서버는 락을 기다릴 때에 이것을 실행하는 것은 아닙니다. 낙관적으로, 데드 록은 실용 레벨의 애플리케이션에서는 빈번하게 발생하지 않는 다는 것을 가정하고, 데드 록의 검사를 시작하기 전에 락 대기를 합니다. 이 값을 늘리는 것으로 필요 없는 데드 록의 검사로 쓸모없는 시간은 줄어듭니다만, 정말로 데드 록이 있었을 경우에는 보고가 늦습니다. 디폴트는 1초(1s)로, 아마 실제에서는 이 이상의 시간이 필요합니다. 부하가 큰 서버에서는 좀 더 필요할지도 모릅니다. 이상적으로, 이 설정은 통상의 트랜잭션(transaction)시간을 초과해야 합니다. 그러면 락 대기 트랜잭션(transaction)이 데드 록의 검사를 하기 전에 락이 해제될 가능성이 개선됩니다.
공유 락 테이블은,max_locks_per_transaction * (max_connections + max_prepared_transactions) 오브젝트(예를 들면 테이블) 상의 락을 추적할 수 있도록 작성됩니다. 따라서, 어떤 시점에서, 이 수 이상의 개개의 오브젝트에 락을 걸 수 없습니다. 이 매개변수는 각 트랜잭션(transaction)로 할당할 수 있는 오브젝트 락의 평균치를 제어합니다. 개개의 트랜잭션(transaction)에서는, 이 락 테이블에 모든 트랜잭션(transaction)의 락이 들어가는 한 오브젝트의 락을 획득할 수 있습니다. 이것은, 잠글 수 있는 행수가 없습니다 . 이 값에는 제한이 없습니다. 디폴트의 64는, 경험적으로 충분하다라고 증명되고 있습니다만, 단일의 트랜잭션(transaction)에서 수많은 다른 테이블을 다루는 클라이언트가 있는 경우, 이 값을 크게 할 필요가 있을 수도 있습니다. 이 매개변수는 서버 기동시만 설정됩니다.
이 매개변수를 증가하면 사용하고 있는 운영 시스템 디폴트 설정이 허용 하는System V공유 메모리의 한계를 넘은 요구를PostgreSQL가 실시하는 원인이 되는 경우가 있습니다. 필요하면, 이 매개변수를 조정하는 방법에 대해서Section 16.4.1를 참조해 주십시오.