Questão de Banco de Dados — Geral — INSTITUTO AOCP 2026

PostgreSQL: diagnóstico e resolução de bloqueios e transações ociosas

Gabarito: letra B. A alternativa correta combina as três frentes de atuação: diagnosticar com pg_stat_activity e pg_locks, resolver o problema imediato encerrando sessões ociosas com pg_terminate_backend() e otimizando a consulta problemática com EXPLAIN ANALYZE, e prevenir recorrência configurando idle_in_transaction_session_timeout. Essa é a abordagem cirúrgica e definitiva para o cenário descrito, em que múltiplas sessões 'idle in transaction' e uma consulta com Seq Scan bloqueiam transações por locks.

O problema apresentado é um clássico de administração de bancos de dados PostgreSQL: transações ociosas (sessões que abriram uma transação, executaram comandos e ficaram paradas sem COMMIT ou ROLLBACK) e consultas lentas que seguram locks por muito tempo. Vamos entender cada peça do cenário antes de julgar as alternativas.

O que são sessões 'idle in transaction'? Quando uma aplicação inicia uma transação (BEGIN) e executa comandos, mas não a finaliza, a sessão fica no estado idle in transaction. Essas sessões seguram todos os locks adquiridos durante a transação, impedindo que outras transações acessem os mesmos dados. Com o parâmetro idle_in_transaction_session_timeout desabilitado (valor 0), o PostgreSQL não encerra automaticamente essas sessões, permitindo que elas se acumulem e causem degradação generalizada.

O que é uma varredura sequencial (Seq Scan)? É quando o PostgreSQL lê a tabela inteira para encontrar as linhas que atendem à consulta, em vez de usar um índice. Em tabelas de grande volume, isso é extremamente lento e pode segurar locks por muito tempo, bloqueando outras transações. O EXPLAIN ANALYZE mostra o plano de execução da consulta, revelando onde está o gargalo (por exemplo, a Seq Scan) e permitindo otimizações como a criação de índices ou a reescrita da query.

Como resolver o problema imediato? O pg_terminate_backend() encerra uma sessão específica, liberando os locks que ela segura. É uma ação cirúrgica, que deve ser usada com cuidado, mas é a forma correta de lidar com sessões ociosas que estão bloqueando o sistema. Reiniciar o serviço (alternativa A) é uma medida drástica que derruba todas as conexões, causando indisponibilidade e perda de trabalho em andamento, e não resolve a causa raiz.

Como prevenir recorrência? Configurar idle_in_transaction_session_timeout para um valor adequado (por exemplo, 30 segundos ou 1 minuto) faz com que o PostgreSQL encerre automaticamente transações ociosas após o tempo limite, evitando que elas se acumulem. Essa é a medida preventiva correta, pois ataca a causa raiz do problema.

A alternativa B é a única que aborda as três frentes de forma completa e correta: diagnóstico, resolução imediata e prevenção. As demais alternativas ou são medidas drásticas desnecessárias (A), ou não resolvem o problema real (C, D), ou configuram um parâmetro que não é o mais adequado (E).

Alternativa A — ❌ Incorreta

Reiniciar o serviço PostgreSQL é uma medida drástica que derruba todas as conexões, causando indisponibilidade e perda de trabalho em andamento. Além disso, não resolve a causa raiz: as sessões ociosas e a consulta lenta continuarão existindo após o reinício. O correto é encerrar seletivamente as sessões problemáticas com pg_terminate_backend(), não reiniciar o serviço.

Alternativa B — ✅ Correta ⟵ GABARITO

Esta alternativa descreve exatamente o procedimento correto: usar pg_stat_activity e pg_locks para identificar as transações bloqueantes, encerrar sessões ociosas com pg_terminate_backend(), otimizar a consulta problemática com EXPLAIN ANALYZE (criando índices ou reescrevendo a query) e configurar idle_in_transaction_session_timeout para encerrar automaticamente transações ociosas. Essa abordagem resolve o problema imediato e previne recorrência.

Alternativa C — ❌ Incorreta

Criar um banco de dados vazio, exportar com pg_dump e importar com pg_restore é um procedimento de migração ou recuperação de desastres, não uma solução para bloqueios e transações ociosas. A fragmentação não é a causa do problema descrito; a causa são sessões ociosas e consultas lentas. Essa alternativa é desnecessariamente complexa e não resolve o problema real.

Alternativa D — ❌ Incorreta

Aumentar max_connections não resolve o problema de transações ociosas e locks. Pelo contrário, pode piorar a situação, permitindo que mais sessões ociosas se acumulem. O problema não é falta de conexões, mas sim sessões que seguram locks por muito tempo. A solução é encerrar as sessões ociosas e otimizar as consultas, não aumentar o número de conexões.

Alternativa E — ❌ Incorreta

Configurar lock_timeout para 5000ms faria com que transações que aguardam um lock por mais de 5 segundos fossem encerradas, mas isso é uma medida paliativa que pode causar erros em transações legítimas que precisam esperar por locks. O parâmetro mais adequado para o problema descrito é idle_in_transaction_session_timeout, que encerra transações ociosas, não transações que estão aguardando locks. Além disso, a alternativa sugere reiniciar o serviço, o que é desnecessário.

Gabarito: letra B