PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Controlando a duração das esperas de bloqueio do PostgreSQL


Não. PARA ATUALIZAÇÃO bloqueia apenas essas linhas , para que outra transação que tente bloqueá-los (com FOR SHARE , PARA ATUALIZAÇÃO , ATUALIZAR ou EXCLUIR ) bloqueia até que sua transação seja confirmada ou revertida.

Se você quiser um bloqueio de tabela inteiro que bloqueie inserções/atualizações/exclusões, você provavelmente deseja LOCK TABLE ... IN EXCLUSIVE MODE .

  1. Consulte o lock_timeout configuração . Isso foi adicionado em 9.3 e não está disponível em versões mais antigas.

    Aproximações brutas para versões mais antigas podem ser obtidas com statement_timeout , mas isso pode fazer com que as instruções sejam canceladas desnecessariamente. Se statement_timeout é 1s e uma instrução espera 950ms em um bloqueio, ele pode então obter o bloqueio e prosseguir, apenas para ser imediatamente cancelado por um tempo limite. Não o que você quer.

    Não há maneira de definir o nível de consulta lock_timeout , mas você pode e deve apenas:

    SET LOCAL lock_timeout ='1s';

    depois de COMEÇAR uma transação.

  2. Há uma declaração tempo limite, mas os bloqueios são mantidos na transação nível. Não há recurso de tempo limite de transação.

    Se você estiver executando transações de instrução única, basta definir um statement_timeout antes de executar a instrução para limitar por quanto tempo ela pode ser executada. No entanto, isso não é a mesma coisa que limitar por quanto tempo ele pode manter um bloqueio, porque pode esperar 900ms de 1s permitidos para o bloqueio, apenas manter o bloqueio por 100ms e ser cancelado pelo tempo limite.

  3. Não. Você deve:
    BEGIN;
SET LOCAL lock_timeout = '4s';
SELECT ....;
COMMIT;

  4. DEFINIR LOCAL é adequado e preferido para isso.

    Não há como fazer isso no texto da consulta, deve ser uma instrução separada.

    A postagem da lista de discussão à qual você vinculou é uma proposta para uma sintaxe imaginária que nunca foi implementada (pelo menos em uma versão pública do PostgreSQL) e não existe.

Em uma situação como essa, você pode considerar o "controle de simultaneidade otimista", geralmente chamado de "bloqueio otimista". Ele oferece maior controle sobre o comportamento de bloqueio ao custo de taxas aumentadas de repetição de consulta e a necessidade de mais lógica de aplicativo.