Skip site navigation (1) Skip section navigation (2)

Re: Bloqueo de Tabla

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Javier Fritz Aliste <jfritz(dot)aliste(at)gmail(dot)com>
Cc: pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Bloqueo de Tabla
Date: 2010-07-27 22:31:23
Message-ID: 1280269705-sup-2355@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
Excerpts from Javier Fritz Aliste's message of mar jul 27 14:20:17 -0400 2010:
> Hola a todos.
> 
> Tengo el siguiente problema con una tabla.
> 
> Esta tabla es utilizada para reserva el uso de un recurso, cada vez que un
> usuario requiere uno de estos recursos mi sistema agrega un registro a esta
> tabla para marcarlo como usado y eliminarlo cuando este es liberado.
> 
> Una vez creado este registro se debe actualizar el campo fol_numero, (con un
> numero que se calcula posteriormente).
> Tengo casos en los que este segundos query queda en espera (muuuuuucho
> tiempo hasta ~ 30min. ).
> 
> Esta tabla maneja muy pocos registros al mismo tiempo (100~200), pero si
> recibe muchos insert's/update's/delete's.

Sospecho que la tabla está mal mantenida y tiene mucho espacio muerto
que vacuum no puede recuperar.  Normalmente un vacuum de una tabla de
200 registros debería ser casi instantáneo, así que si se está demorando
30 minutos, entonces hay un problema serio.

Verifica el tamaño físico de la tabla.  Si es muy grande, debes corregir
el problema del espacio muerto (posiblemente usando CLUSTER).

Por otro lado, autovacuum NO BLOQUEA insert/update/delete.  Yo creo que
autovacuum está siendo bloqueado por alguna otra operación, quizás un
ALTER TABLE o algo así.  Verifica en pg_locks WHERE granted=f.

¿qué versión de Postgres estás usando?

In response to

Responses

pgsql-es-ayuda by date

Next:From: Carlos Agustín L. AvilaDate: 2010-07-27 22:31:49
Subject: BD Semantica.
Previous:From: Mariano ReingartDate: 2010-07-27 20:01:52
Subject: Re: Insertar image en un campo bytea???

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group