Seu tempo limite retornou. PostgreSQL continuou funcionando.
Um usuário fecha um chat de IA.
O cliente atinge o tempo limite.
Seu servidor MCP retorna um erro.
Todos assumem que a consulta ao banco de dados parou.
Essa suposição é cara.
Uma consulta PostgreSQL pode sobreviver ao pedido que a criou. Ela pode manter uma conexão em pool ocupada, segurar bloqueios, escanear linhas e consumir capacidade enquanto o usuário já seguiu em frente.
O problema é que o "tempo limite" existe em várias camadas:
- o agente de IA tem um prazo
- o transporte MCP tem um tempo limite
- o executor de ferramentas tem outro tempo limite
- o pool de conexões tem um tempo limite de aquisição
- PostgreSQL tem
statement_timeoutelock_timeout - um proxy pode fechar o socket primeiro
O relógio mais rápido geralmente termina apenas sua própria camada.
Um 504 prova que o proxy parou de esperar. Não prova que o PostgreSQL parou de funcionar.
Teste toda a cadeia de cancelamento
Um teste de produção útil começa com algo deliberadamente observável:
SELECT pg_backend_pid(), pg_sleep(30);
Execute-o através da verdadeira ferramenta MCP, driver, pool e caminho de rede. Dê ao cliente um prazo de dois segundos.
Então verifique quatro fatos separados:
- O cliente recebeu um erro de cancelamento ou prazo.
- A ferramenta MCP parou o trabalho ativo e em fila.
- O backend correspondente não executa mais a instrução em
pg_stat_activity. - A conexão em pool pode executar com segurança a próxima consulta.
Se você verificar apenas o primeiro item, você testou a interface do usuário—não o cancelamento.
Os casos estranhos importam mais
O tempo limite limpo é a fixação fácil. A produção precisa das corridas:
- desconectar enquanto as linhas estão sendo transmitidas
- cancelar enquanto espera por uma conexão em pool
- abortar enquanto bloqueado em um bloqueio
- terminar um trabalhador durante uma instrução ativa
- cancelar assim que o PostgreSQL completa
- reutilizar a conexão após o cancelamento
O trabalho em fila merece atenção especial. Se o chamador cancela enquanto espera pelo pool, a consulta não deve começar dez segundos depois, quando uma conexão se torna disponível.
Limites do lado do banco de dados são a rede de segurança
O cancelamento da aplicação pode falhar. Processos falham. Manipuladores de abortos têm bugs.
O papel do banco de dados ainda deve ter uma política de execução limitada:
ALTER ROLE ai_readonly SET statement_timeout = '15s';
ALTER ROLE ai_readonly SET lock_timeout = '2s';
ALTER ROLE ai_readonly SET idle_in_transaction_session_timeout = '10s';
Esses valores são exemplos, não padrões universais. Cargas de trabalho analíticas aprovadas podem precisar de um papel separado e um orçamento explícito maior.
A parte importante é que "suporta tempos limites" se torna um contrato testável:
Pedidos cancelados não podem deixar o trabalho do PostgreSQL em execução além do orçamento do lado do banco de dados. O trabalho em fila nunca começa, o trabalho ativo é cancelado, as conexões em pool retornam em um estado conhecido, e o resultado é auditável.
Uma demonstração prova que um agente de IA pode iniciar uma consulta.
A prontidão para produção requer prova de que o sistema pode parar uma.
Eu escrevi o plano de teste completo—incluindo evidências de pg_stat_activity, categorias de erro, esperas de bloqueio, streaming e limpeza de pool—aqui:
Servidor MCP para Postgres: teste de cancelamento de consulta até o backend
Empresas brasileiras que utilizam PostgreSQL devem estar cientes dos desafios relacionados a timeouts em consultas. A compreensão desses aspectos pode evitar custos desnecessários e melhorar a eficiência do sistema. Testes adequados garantem que as operações sejam gerenciadas corretamente em ambientes de produção.
