Jeśli możliwe jest ponowne uruchomienie postgresa, najprawdopodobniej rozwiąże to problem i oszczędzi Ci spędzania czasu na czytaniu reszty tej odpowiedzi :-)
Sprawdź pg_stat_activity widok, prawdopodobnie istnieje jakaś inna transakcja blokująca zmianę schematu.
select * from pg_stat_activity
where
wait_event_type is NULL and xact_start is not NULL order by xact_start;
(pg_stat_activity jest nieco zmieniana w każdym głównym wydaniu pg, wypróbuj to dla starszych wersji):
select * from pg_stat_activity
where
not waiting and xact_start is not NULL order by xact_start;
Pierwszy wiersz, który się pojawi, to prawdopodobnie ten, który powoduje problemy. Często jest to "bezczynna transakcja" - może to bardzo dobrze utrzymać blokady, a jeśli jest to stara transakcja, może to równie dobrze zabić wydajność. Prawdopodobnie programista zapomniał zapewnić zakończenie transakcji za pomocą „zatwierdź” lub „wycofania”, a może jakaś sesja db utknęła z powodu problemów z siecią.
Aby zakończyć transakcję z pid 1234, użyj select pg_cancel_backend(1234); , jeśli to się nie powiedzie, select pg_terminate_backend(1234) . Przy dostępie do powłoki równoważne polecenia to kill -INT 1234 i kill 1234 . (pamiętaj, kill -9 1234 to naprawdę zły pomysł).
Istnieje również widok pg_locks co może dać pewien wgląd, choć prawdopodobnie nie będzie łatwo uzyskać z niego przydatne informacje. Jeśli granted jest prawdziwe, blokada jest wstrzymywana, gdy granted jest fałszywe, oznacza to, że zapytanie czeka na blokadę. Oto kilka wskazówek, jak wyodrębnić przydatne informacje z pg_locks:http://wiki.postgresql. org/wiki/Lock_Monitoring
Jeśli wszystko inne zawiedzie, prawdopodobnie nadszedł czas na proste rozwiązanie, zrestartuj serwer bazy danych.
