From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Luis Rodrigo Gallardo Cruz <rodrigo(at)nul-unu(dot)com> |
Cc: | pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Re: DeadLock |
Date: | 2006-09-27 01:08:53 |
Message-ID: | 20060927010853.GF22101@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Luis Rodrigo Gallardo Cruz escribió:
> 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.
Todo esto es bastante cierto en lo general, pero lamentablemente le
falta incluir el efecto de un "bug" en Postgres antes de la version 8.1.
Resulta que para implementar las llaves foraneas, Postgres toma un lock
exclusivo (SELECT FOR UPDATE) en cada tupla de la tabla referenciada, de
manera que no vaya a borrarse esa tupla antes de que "esta" transaccion
(i.e. la transaccion que está haciendo el chequeo) termine.
Esto es un lock demasiado fuerte. Un lock compartido es suficiente.
Pero en Postgres no habia locks compartidos por tupla en versiones
anteriores a 8.1, por lo que habia que buscarse alguna manera de sacarse
el problema. Hay dos alternativas:
1) no usar llaves foraneas (eek!)
2) hacer las llaves foraneas DEFERRABLE INITIALLY DEFERRED, de manera
que la ventana de tiempo que cada transaccion tiene los locks que
necesita es pequeña, y por lo tanto hay menor probabilidad de deadlocks.
La 2 no soluciona el problema totalmente, solo hace que sea menos
probable. La 1 "soluciona" el problema, pero quedas sin llaves foraneas
...
Para la version 8.1, quien escribe implementó los locks compartidos por
tupla (SELECT FOR SHARE).
Por lo tanto, obviamente te sugiero actualizar a 8.1.4. Si te soluciona
el problema, aca tienes un link que te puede ser de utilidad:
http://www.amazon.com/gp/registry/5ZYLFMCVHXC
:-)
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-09-27 01:19:07 | Re: DeadLock |
Previous Message | Juan Martínez | 2006-09-27 01:06:44 | Re: Velocidad de una consulta |