Om att starta om postgres är ett alternativ, kommer det troligen att lösa problemet och kommer att rädda dig från att spendera tid på att läsa resten av det här svaret :-)
Kontrollera pg_stat_activity visa, finns det förmodligen någon annan transaktion som blockerar schemaändringen.
select * from pg_stat_activity
where
wait_event_type is NULL and xact_start is not NULL order by xact_start;
(pg_stat_activity ändras lite i varje större sidversion, prova detta för äldre versioner):
select * from pg_stat_activity
where
not waiting and xact_start is not NULL order by xact_start;
Den första raden som dyker upp är förmodligen den som orsakar problem. Det är ofta en "tomgång i transaktionen" - detta kan mycket väl hålla lås, och om det är en gammal transaktion kan det lika gärna döda prestanda. Förmodligen glömde programmeraren att se till att transaktionen avslutades med "commit" eller "rollback", eller så kanske någon db-session fastnade på grund av nätverksproblem.
För att avsluta transaktionen med pid 1234, använd select pg_cancel_backend(1234); , om det misslyckas, select pg_terminate_backend(1234) . Med skalåtkomst är motsvarande kommandon kill -INT 1234 och kill 1234 . (kom ihåg, kill -9 1234 är en riktigt dålig idé).
Det finns också en vy pg_locks vilket kan ge lite insikt, även om det kanske inte är så lätt att få ut någon användbar information från det. Om granted är sant hålls låset när granted är falsk betyder det att frågan väntar på låset. Här är några fler tips här om hur man extraherar användbar information från pg_locks:http://wiki.postgresql. org/wiki/Lock_Monitoring
Om allt annat misslyckas är det förmodligen dags att välja den enkla lösningen, starta om den databasservern.