Este é o tempo de espera por um bloqueio antes de verificar se há uma condição de impasse (deadlock). A verificação de impasse é relativamente cara, portanto o servidor não a executa toda vez que espera por um bloqueio. É assumido com otimismo que os impasses não são comuns em aplicações de produção, e apenas se espera um pouco pelo bloqueio antes de verificar se há um impasse. Aumentar este valor reduz a quantidade de tempo desperdiçado em verificações desnecessárias de bloqueio, mas retarda o relato de erros reais de bloqueio. Se o valor for especificado sem unidades, será considerado milissegundos. O padrão é um segundo (1s), que é provavelmente o menor valor que se desejaria na prática. Em um servidor muito carregado, pode-se desejar aumentá-lo. Idealmente, a configuração deve exceder o tempo típico de uma transação, de modo a aumentar as chances do bloqueio ser liberado antes que se decida verificar o impasse. Apenas superusuários e usuários com o privilégio SET apropriado podem alterar esta configuração.

Quando log_lock_waits está definido, este parâmetro também determina a quantidade de tempo de espera antes que seja emitida uma mensagem de registro de evento sobre a espera do bloqueio. Caso se esteja tentando investigar atrasos por bloqueio, talvez seja bom definir um tempo menor que o normal para deadlock_timeout.

A tabela de bloqueios compartilhada tem espaço para max_locks_per_transaction objetos (por exemplo, tabelas) por processo servidor ou transação preparada, portanto não é possível bloquear mais do que esta quantidade de objetos distintos simultaneamente. Este parâmetro limita o número médio de bloqueios de objeto utilizados por cada transação; as transações podem bloquear mais objetos individualmente, desde que os bloqueios de todas as transações caibam na tabela de bloqueios. Este não é o número de linhas que podem ser bloqueadas; este valor é ilimitado. O padrão, 64, historicamente tem se mostrado suficiente, mas pode-se precisar aumentá-lo havendo consultas que acessem muitas tabelas diferentes em uma única transação como, por exemplo, uma consulta a uma tabela mãe com muitas filhas. Este parâmetro só pode ser definido na ativação do servidor.

Ao executar um servidor em-espera, deve-se configurar este parâmetro com um valor igual ou superior ao do servidor primário. Caso contrário, não serão permitidas consultas no servidor em-espera.

A tabela de bloqueio de predicados compartilhada tem espaço para max_pred_locks_per_transaction objetos (por exemplo, tabelas) por processo servidor ou transação preparada; portanto não é possível bloquear mais do que este número de objetos distintos simultaneamente. Este parâmetro limita o número médio de bloqueios de objetos usados ​​por cada transação; transações individuais podem bloquear mais objetos, desde que os bloqueios de todas as transações caibam na tabela de bloqueios. Este não é o número de linhas que podem ser bloqueadas; este valor é ilimitado. O padrão, 64, historicamente tem se mostrado suficiente, mas pode-se precisar aumentá-lo havendo clientes que acessem muitas tabelas diferentes em uma única transação serializável. Este parâmetro só pode ser definido na ativação do servidor.

Este parâmetro controla quantas páginas ou tuplas de uma única relação podem ser bloqueadas por predicado, antes que o bloqueio seja promovido para cobrir toda a relação. Valores maiores ou iguais a zero significam um limite absoluto, enquanto valores negativos significam max_pred_locks_per_transaction dividido pelo valor absoluto dessa configuração. O padrão é -2, que mantém o comportamento das versões anteriores do PostgreSQL. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Este parâmetro controla quantas linhas podem ser bloqueadas por predicado em uma única página, antes que o bloqueio seja promovido para cobrir a página inteira. O padrão é 2. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.