13.5. Tratamento de falhas de serialização #

Tanto o nível de isolamento de leitura repetível quanto o serializável podem gerar erros projetados para evitar anomalias de serialização. Conforme mencionado anteriormente, as aplicações que utilizam estes níveis devem estar preparados para repetir as transações que falharem devido a erros de serialização. A mensagem de erro deste tipo varia de acordo com as circunstâncias específicas, mas sempre conterá o código SQLSTATE 40001 (serialization_failure).

Também pode ser aconselhável tentar novamente em caso de falha de impasse (deadlock). Estes possuem o código SQLSTATE 40P01 (deadlock_detected).

Em alguns casos, também é apropriado tentar novamente em casos de falha na chave de unicidade, que possuem código SQLSTATE 23505 (unique_violation), e falhas nas restrições de exclusão, que possuem código SQLSTATE 23P01 (exclusion_violation). Por exemplo, se a aplicação selecionar um novo valor para uma coluna de chave primária após inspecionar as chaves armazenadas no momento, poderá ocorrer uma falha de chave de unicidade, porque outra instância da aplicação selecionou a mesma nova chave ao mesmo tempo. Isto é efetivamente uma falha de serialização, mas o servidor não a detectará como tal porque não consegue enxergar a conexão entre o valor inserido e as leituras anteriores. Existem também alguns casos extremos em que o servidor irá emitir um erro de chave de unicidade ou de restrição de exclusão, mesmo que, em princípio, tenha informações suficientes para determinar que um problema de serialização é a causa subjacente. Embora seja recomendável simplesmente tentar novamente incondicionalmente erros de serialization_failure, é preciso ter mais cuidado ao tentar novamente estes outros códigos de erro, porque eles podem representar condições de erro persistentes em vez de falhas transitórias.

É importante tentar novamente a transação completa, incluindo toda a lógica que decide qual comando SQL executar e/ou quais valores usar. Portanto, o PostgreSQL não oferece um recurso de repetição automática, porque não pode fazê-lo com qualquer garantia de correção.

A repetição da transação não garante que a transação repetida será concluída; podem ser necessárias várias tentativas. Em casos de grande contenção, é possível que a conclusão de uma transação exija muitas tentativas. Em casos que envolvam uma transação preparada conflitante, pode não ser possível prosseguir até que a transação preparada seja efetivada ou desfeita.