Uma consulta de longa duração do Postgres é abortada se a conexão for perdida/interrompida?

"Depende".

Se o cliente desaparecer devido à perda de conexão de rede, a consulta geralmente será executada até que sejam recuperadas linhas suficientes para preencher seu buffer de envio de rede e, em seguida, pare e fique presa até que a conexão TCP caia, ponto em que será abortada. Se for concluído antes de preencher o buffer de envio TCP, ele será concluído com êxito; portanto, se for confirmado automaticamente, a consulta será confirmada.

Se o cliente for eliminado de forma que o sistema operacional do cliente possa relatar ao servidor por meio de um TCP RST (como um cliente segfault/crash, SIGTERM, SIGKILL, etc.), o servidor PostgreSQL definirá o sinalizador de interrupção. Da próxima vez que a consulta verificar se há interrupções durante a execução, ela verá o sinalizador e abortará. Às vezes, uma consulta pode estar fazendo um trabalho pesado de CPU dentro do código que não verifica interrupções - algumas extensões e alguns locais no núcleo do PostgreSQL - caso em que pode não perceber a interrupção por um longo tempo e continuar em execução. No entanto, ele sempre verá a interrupção e abortará antes de concluir e confirmar se for autocommit.

Se o cliente for morto por algo como uma reinicialização repentina do sistema operacional, de modo que o host do cliente de repente não saiba nada sobre a conexão TCP, mas ainda possa responder na rede, a consulta provavelmente será abortada na primeira vez que tentar gravar uma linha, como Jeff disse, porque o host do cliente enviará um TCP RST em resposta ao primeiro pacote enviado pelo servidor após a reinicialização. O PostgreSQL verifica as interrupções em cada linha que envia.

Este comportamento não é configurável. No que diz respeito ao PostgreSQL, se o cliente for embora, seu trabalho é encerrar todas as consultas que o cliente estava executando. Para alterar isso, você precisaria de algum tipo de token de conclusão de consulta que poderia obter no início da consulta e, em seguida, usar para perguntar ao servidor sobre a consulta por meio de outra conexão posteriormente. Essencialmente, você teria que implementar consultas assíncronas/em segundo plano. Possivelmente um bom recurso, mas não suportado atualmente.

Se a consulta for autocommit ou se a sua consulta estiver COMMITem andamento no momento em que você matou o cliente/perdeu a conexão, é possível que uma transação esteja em um estado indeterminado em que o cliente não sabe se ou não cometeu. Não há uma maneira real de descobrir, além de procurar os efeitos da transação nos dados.

Onde isso for inaceitável, você pode usar o commit de duas fases e um gerenciador de transações do lado do cliente.

Ele continuará em execução até tentar retornar linhas à conexão e detectar a quebra. Portanto, para uma consulta que faz todo o trabalho antes de retornar qualquer linha, ela será essencialmente executada até a conclusão.

Observe que, se você precisar que um processo do lado do servidor continue depois de interromper a conexão com o cliente, poderá usar nohup na linha de comando do lado do servidor e fechar com segurança a conexão com o servidor. Isso é especialmente útil em conjunto com a gravação do script SQL em um arquivo e a execução do arquivo na linha de comando, por exemplo

$ nohup psql -f my_long_query.sql &

(O exposto acima espera que o Postgres confie na autenticação do sistema operacional do usuário atual e que o usuário tenha as permissões apropriadas. Gravar a saída da consulta em uma tabela apropriada para um simples posterior SELECT *armazenará resultados que, de outra forma, poderiam ser perdidos.)