Saludos, En cuanto al bloqueo que se plantea de la tabla, precisamente este proceso lo ejecutamos en horario nocturno en donde nos hemos encargado de denegar el acceso a la BD, por App y Motor. Por ello lo único que esta ejecutandose en la BD es el proceso de actualización de datos (El DROP TRIGGER se hace dentro de las primeras sentencias del proceso).
Vamos a ejecutar el VACUUM sobre el catalogo para avanzar en la busqueda del problema. Muchas gracias. 2013/5/9 Alvaro Herrera <alvhe...@2ndquadrant.com> > Jose David Verbel Tous escribió: > > Saludos, > > > > Como parte de un proceso de actualización de datos tenemos una sentencia > de > > eliminación de un trigger. Esto venia haciéndose bien (Eliminarlo solo se > > tomaba unos segundos) hasta hace un par de días, en donde se esta > tardando > > mas de 1 hora eliminando el trigger > > Eliminar el trigger requiere tomar un lock AccessExclusive sobre la > tabla. Es decir ningún otro proceso puede tener tomado ningún lock de > ningún tipo; de lo contrario el DROP TRIGGER tendrá que esperar hasta > que todos los otros procesos hayan terminado. Si esto es lo que está > pasando, entonces deberías ver en pg_locks una fila con granted=f del > proceso corriendo el DROP TRIGGER sobre la tabla en cuestión. Si > aparece este lock, entonces lo que debes hacer es conseguir que los > otros procesos no tengan locks sobre esa tabla durante tanto tiempo. > > Si esto no lo explica, entonces puede ser que tus catálogos (pg_class, > pg_trigger) estén llenos de tuplas muertas y necesiten VACUUM. > > -- > Álvaro Herrera http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > > - > Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org > ) > Para cambiar tu suscripción: > http://www.postgresql.org/mailpref/pgsql-es-ayuda > -- *Jose David Verbel Tous*
