From: | Luis Rodrigo Gallardo Cruz <rodrigo(at)nul-unu(dot)com> |
---|---|
To: | pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Re: DeadLock |
Date: | 2006-09-26 23:49:49 |
Message-ID: | 20060926234949.GD3124@caribdis.nul-unu.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
On Tue, Sep 26, 2006 at 07:25:45PM -0400, Marcelo Retamal wrote:
> Hola a todos los usuarios de la lista. Tengo el sgte problema con
> un DeadLock que se produce pocas veces al día y muchas veces
> durantes los días de corte de los clientes de nuestra empresa. El
> mensaje que entrega el servidor PG (versión 7.4.6 + Redhat 9) con 1
> GB en Ram es: <<DETALLE: El proceso 17864 espera ShareLock en la
> transacción 141443513; bloqueado por proceso 17992. El proceso
> 17992 espera ShareLock en la transacción 141443518; bloqueado por
> proceso 17864>>
>
> Ya nos documentamos respecto a como y por que se producen los
> deadlock, lo que no nos queda claro es qué parametro del
> <<postgresql.conf>> hay que modificar para que no se produzca o que
> se produzca lo más a lo lejos posible. Intentamos con los sgtes
> parametros: ...
Creo que esa documentación les falló. Los Deadlocks no tienen nada que
ver con los parámetros.
Un deadlock ocurre cuando dos procesos (en este ejemplo el 17992 y el
17864) se quedan esperando una a la otra a que se libere algún
recurso, en este caso un ShareLock.
Lo que ocurre es que ambos procesos quieren modificar el mismo dato al
mismo tiempo, básicamente. Probablemente por eso se produce más a
menudo los días de corte. Un deadlock normalmente se debe a problemas
de diseño en los clientes, que están usando más locks de los
estríctamente necesarios, tomándolos en diferente orden o
manteniendolos más tiempo del debido[1].
Es decir, tu problema no se va a resolver modificando
parámetros[2]. Necesitas identificar *qué* están tratando de hacer las
transacciones que se quedan bloqueadas y modificar la lógica de tu
cliente en esas operaciones.
[1] Sé que es posible que existan deadlocks en un diseño bien
hecho. Pero en este caso, el de alguien que no sabía *qué* es un
deadlock, lo más probable es que el diseño sea malo.
[2] Creo que versiones 'suficientemente' recientes de postgres pueden
detectar el deadlock y matar la transacción. Afinar parámetros podría
ayudar con el tiempo que tarda en pasar eso, quizá. Pero no resolvería
el problema, sólo es un paliativo.
--
Rodrigo Gallardo
GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28
From | Date | Subject | |
---|---|---|---|
Next Message | Juan Martínez | 2006-09-27 01:06:44 | Re: Velocidad de una consulta |
Previous Message | Alvaro Herrera | 2006-09-26 23:30:11 | Re: problema de conexion |