Si reiniciar Postgres es una opción, lo más probable es que eso resuelva el problema y le evitará perder tiempo leyendo el resto de esta respuesta :-)
Compruebe la pg_stat_activity vista, probablemente haya alguna otra transacción que bloquee el cambio de esquema.
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 cambia un poco en cada versión principal de pg, intente esto para versiones anteriores):
select * from pg_stat_activity
where
not waiting and xact_start is not NULL order by xact_start;
La primera fila que aparece es probablemente la que causa problemas. A menudo es una "transacción inactiva":esto puede muy bien contener bloqueos, y si es una transacción anterior, también puede matar el rendimiento. Probablemente el programador olvidó asegurarse de finalizar la transacción con "commit" o "rollback", o tal vez alguna sesión de db se atascó debido a problemas de red.
Para terminar la transacción con pid 1234, use select pg_cancel_backend(1234); , si eso falla, select pg_terminate_backend(1234) . Con acceso de shell, los comandos equivalentes son kill -INT 1234 y kill 1234 . (recuerde, kill -9 1234 es una muy mala idea).
También hay una vista pg_locks lo que puede dar una idea, aunque probablemente no sea tan fácil obtener información útil. Si granted es verdadero, el bloqueo se mantiene cuando granted es falso, significa que la consulta está esperando el bloqueo. Aquí hay algunos consejos más sobre cómo extraer información útil de pg_locks:http://wiki.postgresql. org/wiki/Lock_Monitoring
Si todo lo demás falla, entonces probablemente sea el momento de buscar la solución simple, reiniciar ese servidor de base de datos.
