Re: DeadLock

Alvaro Herrera escribió:

> 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.

BTW es facil demostrar este efecto en servidores 8.0 y anteriores:

CREATE TABLE primaria (a int primary key);
CREATE TABLE secundaria (a int REFERENCES primaria, b text);
INSERT INTO primaria VALUES (1);
INSERT INTO primaria VALUES (2);

en una sesion:

BEGIN;
INSERT INTO secundaria VALUES (1);

en otra sesion:
BEGIN;
INSERT INTO secundaria VALUES (2);
INSERT INTO secundaria VALUES (1);
-- observa que aqui, esta sesion se bloquea

En la primera sesion:
INSERT INTO secundaria VALUES (2);

Aca esta sesion se muere con este mensaje:

ERROR: se ha detectado un deadlock
DETAIL: El proceso 25507 espera ShareLock en la transacción 199896; bloqueado por proceso 25520.
El proceso 25520 espera ShareLock en la transacción 199895; bloqueado por proceso 25507.
CONTEXT: sentencia SQL: «SELECT 1 FROM ONLY "public"."primaria" x WHERE "a" = $1 FOR UPDATE OF x»

En 8.1 esto no pasa; de hecho la segunda sesion ni siquiera se bloquea.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.