Re: Transacciones concurrentes

El Mié 14 Abr 2004 18:16, Alvaro Herrera escribió:
> On Wed, Apr 14, 2004 at 05:07:21PM -0300, Martin Marques wrote:
> > > > Que tal lista: Alvaro me preguntó por las llaves foraneas, la verdad
> > > > que la tabla tiene varias de ellas, así que las saque y resultó,
> > > > buenaaa!.
> >
> > Cuando es que estos problemas aparecen? Vi tu otro mensaje, p[ero no
> > entiendo que es lo que frena la transaccion de la segunda sesion.
>
> Para hacer la verificación de integridad, internamente se hace un SELECT
> FOR UPDATE.
>
> Idealmente habría que tomar un candado (lock) compartido por cada tupla,
> pero por problemas de implementación lo mejor que se puede hacer es
> tomar un candado exclusivo. Eventualmente alguien tiene que desarrollar
> un mecanismo para poder tomar candados compartidos por tuplas ...

Pero eventualmente se destraba en algun momento:

<Ejemplo de Alvaro>
create table a (a serial primary key);
create table b (b int not null references a);
insert into a values (default);
insert into a values (default);
insert into a values (default);

sesion 1 sesion 2
BEGIN;
insert into b values (1);
insert into b values (2);
insert into b values (1);
-- (se queda pegado);
COMMIT
</Ejemplo de Alvaro>

Digo, cuando termine la transaccion de la sesion 1 la sesion 2 se destraba (me
quede confundido pensando que la transaccion de la sesion 2 se quedaba
colgada por siempre).

Por lo tanto la solución podría verse más bien como: Hay que evitar
transacciones que duren mucho, o mejor aun, ver donde esta perdiendo tanto
tiempo (capaz que haga falta algun indice, aunque las PK crean indices).

--
08:17:03 up 37 days, 12:44, 2 users, load average: 1.34, 1.17, 1.15
-----------------------------------------------------------------
Martín Marqués | select 'mmarques' || '@' || 'unl.edu.ar'
Centro de Telematica | DBA, Programador, Administrador
Universidad Nacional
del Litoral
-----------------------------------------------------------------