Als het herstarten van postgres een optie is, zal dat het probleem hoogstwaarschijnlijk oplossen en bespaart u tijd om de rest van dit antwoord te lezen :-)
Controleer de pg_stat_activity bekijken, is er waarschijnlijk een andere transactie die de schemawijziging blokkeert.
select * from pg_stat_activity
where
wait_event_type is NULL and xact_start is not NULL order by xact_start;
(de pg_stat_activity is een beetje veranderd in elke grote pg-release, probeer dit voor oudere versies):
select * from pg_stat_activity
where
not waiting and xact_start is not NULL order by xact_start;
De eerste rij die verschijnt, is waarschijnlijk degene die problemen veroorzaakt. Het is vaak een "inactieve transactie" - dit kan heel goed vergrendelingen bevatten, en als het een oude transactie is, kan het net zo goed de prestaties doden. Waarschijnlijk is de programmeur vergeten ervoor te zorgen dat de transactie wordt beëindigd met "commit" of "rollback", of misschien is een db-sessie vastgelopen vanwege netwerkproblemen.
Om de transactie met pid 1234 te beëindigen, gebruikt u select pg_cancel_backend(1234); , als dat niet lukt, select pg_terminate_backend(1234) . Met shell-toegang zijn de equivalente commando's kill -INT 1234 en kill 1234 . (houd er rekening mee, kill -9 1234 is een heel slecht idee).
Er is ook een weergave pg_locks wat enig inzicht kan geven, hoewel het waarschijnlijk niet zo eenvoudig is om er bruikbare informatie uit te halen. Indien granted waar is, wordt de vergrendeling vastgehouden, wanneer granted onwaar is, betekent dit dat de query wacht op het slot. Hier zijn nog enkele hints over hoe u nuttige informatie uit pg_locks kunt halen:http://wiki.postgresql. org/wiki/Lock_Monitoring
Als al het andere faalt, is het waarschijnlijk tijd om voor de eenvoudige oplossing te gaan:herstart die databaseserver.