Pokud je možné restartovat postgres, pak to s největší pravděpodobností problém vyřeší a ušetří vám čas strávený čtením zbytku této odpovědi :-)
Zkontrolujte pg_stat_activity Změnu schématu blokuje pravděpodobně nějaká jiná transakce.
select * from pg_stat_activity
where
wait_event_type is NULL and xact_start is not NULL order by xact_start;
(pg_stat_activity se v každém hlavním vydání pg trochu mění, zkuste to pro starší verze):
select * from pg_stat_activity
where
not waiting and xact_start is not NULL order by xact_start;
První řádek, který se objeví, je pravděpodobně ten, který způsobuje problémy. Často se jedná o „nečinnou transakci“ – to může velmi dobře držet zámky, a pokud se jedná o starou transakci, může to také snížit výkon. Pravděpodobně programátor zapomněl zajistit ukončení transakce příkazem "commit" nebo "rollback", nebo se možná nějaká relace databáze zasekla kvůli problémům se sítí.
Chcete-li ukončit transakci s pid 1234, použijte select pg_cancel_backend(1234); , pokud to selže, select pg_terminate_backend(1234) . S přístupem k shellu jsou ekvivalentní příkazy kill -INT 1234 a kill 1234 . (Mějte na paměti, kill -9 1234 je opravdu špatný nápad).
K dispozici je také pohled pg_locks což může poskytnout určitý náhled, i když pravděpodobně nebude tak snadné z toho získat nějaké užitečné informace. Pokud granted je pravda, zámek je podržen, když je granted je false, znamená to, že dotaz čeká na zámek. Zde je několik dalších tipů, jak extrahovat užitečné informace z pg_locks:http://wiki.postgresql. org/wiki/Lock_Monitoring
Pokud vše ostatní selže, pak je pravděpodobně čas přejít na jednoduché řešení, restartovat databázový server.