Ако рестартирането на postgres е опция, това най-вероятно ще реши проблема и ще ви спести време да четете останалата част от този отговор :-)
Проверете pg_stat_activity изглед, вероятно има друга транзакция, блокираща промяната на схемата.
select * from pg_stat_activity
where
wait_event_type is NULL and xact_start is not NULL order by xact_start;
(pg_stat_activity се променя малко във всяка голяма версия на pg, опитайте това за по-стари версии):
select * from pg_stat_activity
where
not waiting and xact_start is not NULL order by xact_start;
Първият ред, който се показва, вероятно е този, който създава проблеми. Често това е "неактивна транзакция" - това може много добре да задържи ключалки и ако е стара транзакция, може също да убие производителността. Вероятно програмистът е забравил да осигури прекратяване на транзакцията с "commit" или "rollback", или може би някоя db сесия е блокирала поради мрежови проблеми.
За да прекратите транзакция с pid 1234, използвайте select pg_cancel_backend(1234); , ако това не успее, select pg_terminate_backend(1234) . При достъп до обвивката еквивалентните команди са kill -INT 1234 и kill 1234 . (имайте предвид, kill -9 1234 е наистина лоша идея).
Има и изглед pg_locks което може да даде известна представа, въпреки че вероятно може да не е толкова лесно да се извлече полезна информация от него. Ако granted е вярно, заключването се задържа, когато granted е невярно, това означава, че заявката чака заключването. Ето още няколко съвета как да извлечете полезна информация от pg_locks:http://wiki.postgresql. org/wiki/Lock_Monitoring
Ако всичко останало се провали, тогава вероятно е време да изберете простото решение, рестартирайте сървъра на базата данни.
