Kernel escribió:

> Por lo que veo hay varios casos en los que podemos obtener un deadlock de
> estos :
> 
> 1.- que una transacción t1 necesite que termine la t2 y esta t2 a su vez
> necesita que termine t1 para poder terminar, entonces el gestor detecta esto
> y elimina la mas antigua (por ejemplo la t1) y devuelve el deadlock en la
> t1, y la t2 termina correctamente.

Esto es correcto, excepto que la transacción terminada no es
necesariamente la más antigua, sino la que primero detecta el deadlock.

Si en tu descripción de arriba reemplazas t1+t2 por un conjunto de
varias transacciones las cuales forman un ciclo de relaciones "ti
espera a tj", entonces lo de arriba es una descripción del algoritmo
general.

> 2.-   Empieza la transaccion t1(1) (varios insert en la tabla x), y despues
> otro usuario lanza la misma transaccion t1(2), si la t1(1) tarda mucho
> tiempo en terminar, el gestor devuelve el deadlock a la t1(1) y asi la t1(2)
> se puede comenzar y terminar correctamente

Esta parte no es muy precisa.  Una inserción no causa que otras
transacciones se queden esperando.  En versiones antiguas podía suceder
si es que había llaves foráneas en las tablas involucradas, pero esto es
algo que hemos ido solucionando paulatinamente, y a menos que involucres
UPDATEs, no deberían ocurrir bloqueos ni deadlocks.


> Tengo un proceso de cierre de inventario que puede tardar 10 minutos en
> terminar  y no quiero que nadie pueda tocar la tabla , ni insertar,  ni
> modificar.

No tengo clara esta parte.  Quizás quieras usar el modo SERIALIZABLE
(transaction isolation).

> Había pensado que si pongo  'LOCK TABLE movimientos IN   EXCLUSIVE MODE'
> y no recibía ningún error, la tabla ya era de uso exclusivo de mi proceso,
> que nadie podía molestar a mi proceso y que al resto de procesos debían de
> esperar para iniciarse o les daría un error al iniciar, pero mi sorpresa es
> que mi proceso recibe un deadlock y el resto termina bien.

Seguramente tu proceso necesita examinar otras tablas.

Yo creo que deberías hacer que tu proceso de clausura no requiera que no
se inserten movimientos nuevos, sino sólo que no se inserten movimientos
anteriores al timestamp del cierre.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, 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

Responder a