Se reiniciar o postgres for uma opção, isso provavelmente resolverá o problema e evitará que você gaste tempo lendo o restante desta resposta :-)
Verifique o
pg_stat_activity view, provavelmente há alguma outra transação bloqueando a alteração do esquema. select * from pg_stat_activity
where
wait_event_type is NULL and xact_start is not NULL order by xact_start;
(o pg_stat_activity é um pouco alterado em todas as versões principais do pg, tente isso para versões mais antigas):
select * from pg_stat_activity
where
not waiting and xact_start is not NULL order by xact_start;
A primeira linha a aparecer é provavelmente a que causa problemas. Muitas vezes, é uma "ociosidade na transação" - isso pode muito bem manter bloqueios e, se for uma transação antiga, também pode matar o desempenho. Provavelmente o programador esqueceu de garantir o término da transação com "commit" ou "rollback", ou talvez alguma sessão de banco de dados tenha travado devido a problemas de rede.
Para encerrar a transação com pid 1234, use
select pg_cancel_backend(1234); , se isso falhar, select pg_terminate_backend(1234) . Com acesso ao shell, os comandos equivalentes são kill -INT 1234 e kill 1234 . (lembre-se, kill -9 1234 é uma péssima ideia). Há também uma visão
pg_locks o que pode dar algumas dicas, embora provavelmente não seja tão fácil obter informações úteis a partir dele. Se granted for verdadeiro, o bloqueio é mantido, quando granted for false significa que a consulta está aguardando o bloqueio. Aqui estão mais algumas dicas sobre como extrair informações úteis do pg_locks:http://wiki.postgresql. org/wiki/Lock_Monitoring
Se tudo mais falhar, provavelmente é hora de ir para a solução simples, reinicie o servidor de banco de dados.
