| From: | Jaime Casanova <jaime(at)2ndquadrant(dot)com> |
|---|---|
| To: | Diego Ayala <netdiego81(at)gmail(dot)com> |
| Cc: | Eduardo Morras <emorrasg(at)yahoo(dot)es>, Postgres Ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
| Subject: | Re: Funcionamiento Vacuum |
| Date: | 2013-09-17 19:18:05 |
| Message-ID: | CAJKUy5jzTv2WJ3uxPANi2Vy+FpE7LTzLuSXW=ZRG01gu8sbWxw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-es-ayuda |
2013/9/17 Diego Ayala <netdiego81(at)gmail(dot)com>:
> Gracias, Eduardo, podria ser, pero tengo entendido que un lock no evita que
> se realice el vacuum. la verdad que no llegue a encontrar ningun lock a esa
> tabla, aunque lo buscare mas a fondo.
>
Saludos,
El bloqueo apropiado si evita que VACUUM se ejecute
El VACUUM toma un bloqueo de tipo SHARE UPDATE EXCLUSIVE y como indica
la documentación
(http://www.postgresql.org/docs/8.4/static/explicit-locking.html#LOCKING-TABLES)
ese bloqueo tiene conflicto con otros SHARE UPDATE EXCLUSIVE (es
decir, de estos tres: VACUUM, ANALYZE, CREATE INDEX CONCURRENTLY; solo
uno puede estar corriendo en un momento dado).
Tambien tiene conflicto con SHARE (CREATE INDEX) y con ACCESS
EXCLUSIVE (ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX, CLUSTER, and
VACUUM FULL)
como te recomendaron mira en pg_stat_activity los procesos con waiting true
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Phone: +593 4 5107566 Cell: +593 987171157
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jaime Casanova | 2013-09-17 19:25:12 | Re: Funcionamiento Vacuum |
| Previous Message | Diego Ayala | 2013-09-17 16:50:26 | Re: Funcionamiento Vacuum |