Hvis genstart af postgres er en mulighed, så vil det højst sandsynligt løse problemet og spare dig for at bruge tid på at læse resten af dette svar :-)
Tjek pg_stat_activity visning, er der sandsynligvis en anden transaktion, der blokerer for skemaæ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 er ændret en smule i hver større sideudgivelse, prøv dette for ældre versioner):
select * from pg_stat_activity
where
not waiting and xact_start is not NULL order by xact_start;
Den første række, der vises, er sandsynligvis den, der forårsager problemer. Det er ofte en "tomgang i transaktion" - dette kan meget vel holde låse, og hvis det er en gammel transaktion kan det lige så godt dræbe ydeevnen. Sandsynligvis har programmøren glemt at sikre, at transaktionen blev afsluttet med "commit" eller "rollback", eller måske gik en eller anden db-session fast på grund af netværksproblemer.
For at afslutte transaktionen med pid 1234, brug select pg_cancel_backend(1234); , hvis det mislykkes, select pg_terminate_backend(1234) . Med shell-adgang er de tilsvarende kommandoer kill -INT 1234 og kill 1234 . (husk, kill -9 1234 er en rigtig dårlig idé).
Der er også en visning pg_locks hvilket kan give lidt indsigt, selvom det nok ikke er så nemt at få brugbar information ud af det. Hvis granted er sandt, holdes låsen, når granted er falsk betyder det, at forespørgslen venter på låsen. Her er nogle flere tip her til, hvordan man udtrækker nyttig information fra pg_locks:http://wiki.postgresql. org/wiki/Lock_Monitoring
Hvis alt andet fejler, så er det sandsynligvis tid til at gå efter den enkle løsning, genstart databaseserveren.