Si le redémarrage de postgres est une option, cela résoudra probablement le problème et vous évitera de passer du temps à lire le reste de cette réponse :-)
Vérifiez le pg_stat_activity vue, il y a probablement une autre transaction bloquant le changement de schéma.
select * from pg_stat_activity
where
wait_event_type is NULL and xact_start is not NULL order by xact_start;
(le pg_stat_activity est légèrement modifié dans chaque version majeure de pg, essayez ceci pour les versions plus anciennes) :
select * from pg_stat_activity
where
not waiting and xact_start is not NULL order by xact_start;
La première ligne qui apparaît est probablement celle qui pose problème. Il s'agit souvent d'une "transaction inactive" - cela peut très bien contenir des verrous, et s'il s'agit d'une ancienne transaction, cela peut également nuire aux performances. Le programmeur a probablement oublié de s'assurer de terminer la transaction avec "commit" ou "rollback", ou peut-être qu'une session de base de données s'est bloquée en raison de problèmes de réseau.
Pour terminer la transaction avec le pid 1234, utilisez select pg_cancel_backend(1234); , si cela échoue, select pg_terminate_backend(1234) . Avec l'accès au shell, les commandes équivalentes sont kill -INT 1234 et kill 1234 . (gardez à l'esprit, kill -9 1234 est une très mauvaise idée).
Il y a aussi une vue pg_locks ce qui peut donner un aperçu, bien qu'il ne soit probablement pas si facile d'en tirer des informations utiles. Si granted est vrai, le verrou est maintenu, si granted est faux, cela signifie que la requête attend le verrou. Voici quelques conseils supplémentaires sur la façon d'extraire des informations utiles de pg_locks :http://wiki.postgresql. org/wiki/Lock_Monitoring
Si tout le reste échoue, il est probablement temps d'opter pour la solution simple, redémarrez ce serveur de base de données.
