以毫秒计的时间，用于设置在检查是否存在死锁条件之前等待的时间。 检查是否存在死锁条件是一个昂贵的过程，因此服务器不会在每次等待锁的 时候都运行这个过程。我们(乐观地)假设在生产应用中的死锁是不常出现的， 因此我们在开始询问是否可以解锁之前只等待一个相对较短的时间。增加这 个值就减少了浪费在无用的死锁检查上的时间，但是减慢了报告真正死锁 错误的速度。缺省是 1000(1秒)，这可能是你能够耐心等待的最短时间 。在一个重负载的服务器上，你可能需要增大它。这个值的典型设置应该 超过你的事务持续时间，这样就可以减少在锁释放之前就开始死锁检查的问题。

当设置了log_lock_waits参数时， 这个参数同时还可以决定发出关于锁等待的日志等待时间。 如果想调查锁时延，可以将参数设置小于deadlock_timeout的正常值。

共享的锁表的大小是以假设任意时刻最多只有 max_locks_per_transaction* (max_connections+max_prepared_transactions) 个独立的对象需要被锁住 为基础进行计算的。所以，这个参数的名字可能有些让人糊涂： 这not是单个事务可以使用的锁数目的硬限制， 而是一个平均值。缺省值 64 ，已经经历史证明是足够的了， 不过如果你的客户可能在一个事务里面修改很多不同的表，那么你就 可能需要提高这个数值。这个值只能在服务器启动的时候设置。

增大这个参数可能导致PostgreSQL要求更多的 System V共享内存，可能超过操作系统 的缺省配置。必要时，参阅节Section 17.4.1获取如何 调节这些参数的信息。

当在一个备库运行时，这个参数的值必须大于等于主库上的值，否则，备库上不能执行查询操作。