Ao executar o PostgreSQL 13.12 (ocorre em várias versões do PG11/PG13) usando o SQLAlchemy 1.3, ocasionalmente encontramos problemas em que o aumento da simultaneidade deixa certas transações (e suas transações aninhadas) no estado "Idle in Transaction" com a consulta RELEASE SAVEPOINT ....
Olhando para as consultas em execução atualmente, não está claro por que as transações pararam de avançar. Também observei esse comportamento sem travas suspensas:
| pid | nome de dados | duração | consulta | estado | Nome da Aplicação | wait_event_type |
|---|---|---|---|---|---|---|
| 27662 | aplicativo | 22:22:37,429569 | select pg_advisory_xact_lock(resource_id) from resource where uuid = '018afcac-a5ab-7a5c-9eb4-2d8b0be4b556' |
ativo | http.api.1 | Trancar |
| 25830 | aplicativo | 22:22:29.236398 | RELEASE SAVEPOINT sa_savepoint_5 |
ocioso na transação | http.api.0 | Cliente |
| 21490 | aplicativo | 22:22:29.015862 | select pg_advisory_xact_lock(resource_id) |
ativo | http.api.0 | Trancar |
| 27674 | aplicativo | 22:22:27,780581 | RELEASE SAVEPOINT sa_savepoint_3 |
ocioso na transação | http.api.2 | Cliente |
| 29120 | aplicativo | 22:22:26.053851 | select pg_advisory_xact_lock(resource_id) |
ativo | http.api.2 | Trancar |
Alguma maneira de depurar isso? Essa chamada de API geralmente funciona, com a sessão sendo limpa e não falha de forma consistente. Estamos usando o pool de conexões do SQL Alchemy para gerenciar as conexões - sessões fechadas retornarão a conexão ao pool e emitirão um rollback para limpar a conexão (quando o commit deveria ter confirmado todas as outras instruções).
As sessões estão no estado
idle in transactionporque você não executouCOMMITouROLLBACKeRELEASE SAVEPOINTnão fecha uma transação (apenas uma sub-transação). O bug está na sua aplicação, que aparentemente esqueceu de fechar a transação. O estadoidle in transactionnão significa que o PostgreSQL esteja ocupado: ele está aguardando a próxima instrução da sua aplicação.