Descobrimos a causa deste problema. É explicado pela implementação com erros de setQueryTimeout() nos drivers JDBC mais recentes 9.2-100x. Pode não acontecer se você abrir / fechar a conexão manualmente, mas muitas vezes acontece com o pool de conexão no local e o autocommit definido como falso . Nesse caso, setQueryTimeout() deve ser chamado com valor diferente de zero (como exemplo, usando a anotação @Transactional( timeout =xxx ) do framework Spring).

Acontece que, sempre que a exceção SQL é levantada durante a execução da instrução, o temporizador de cancelamento não foi cancelado e permanece ativo (é assim que é implementado). Por causa do pooling, a conexão atrás não é fechada, mas é retornada ao pool. Mais tarde, quando o cronômetro de cancelamento é acionado, ele cancela aleatoriamente a consulta atualmente associada à conexão com a qual esse cronômetro foi criado. Neste momento, é uma consulta totalmente diferente que explica o efeito de aleatoriedade.

A solução sugerida é desistir de setQueryTimeout() e usar a configuração do PostgreSQL (statement_timeout). Não fornece o mesmo nível de flexibilidade, mas pelo menos sempre funciona.