No tengo contacto con otros administradores Postgres por eso me intresa
saber como son las "best practices".
La pregunta es, no es recomendable (por no decir obligatorio) bajar la
aplicacion para que no hayan conexiones antes de ejecuar un vacuum
manual? Lo que le pasó a Guillermo es un ejemplo de lo que pasa si no
se baja.
No sé , pregunto.
gracias
jose
On 04/07/2013 03:57 p.m., Alvaro Herrera wrote:
Guillermo E. Villanueva escribió:
Muchas gracias Alvaro y Jaime, les cuento que leí sus mensajes y no sabía
como cancelar, entré a la misma consola ssh y presioné control + C y ...
yes! se canceló! muchas gracias. La verdad que tenía miedo de dañar los
datos de la tabla.
El VACUUM abre muchas conexiones a la vez?
No, sólo una.
Me imagino que lo que pasó es que otra conexión tratoó de hacer alguna
operación que requería un lock en la tabla que entra en conflicto con el
ShareUpdateExclusive de VACUUM, y por lo tanto se bloqueó; y todos los
accesos de ahí en adelante quedan bloqueados detrás de esa otra
conexión. Para depurar esto deberías mirar pg_locks buscando filas con
granted=false, y correlacionar eso con lo que están tratando de hacer
esas conexiones en pg_stat_activity.
Ahora, ¿por qué podría llegar a pasar esto? Es fácil: si las
operaciones que toman locks pesados en esa tabla son comunes, entonces
autovacuum nunca podría completar un ciclo sobre esa tabla, porque éste
se "suicida" cuando encuentra que está bloqueando otras conexiones. (Un
VACUUM ejecutado manualmente no tiene este comportamiento). La solución
es simple pero no necesariamente fácil: tienes que hacer que tus
aplicaciones no traten de obtener locks pesados muy seguido sobre las
tablas. Por lo menos debería poder ejecutarse un vacuum completo desde
que eso pasa una vez hasta la vez siguiente.
Éxito,
-
Enviado a la lista de correo pgsql-es-ayuda ([email protected])
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
