LOCK

Description

Postgres siempre usa el modo de bloqueo menos restrictivo cuando le es posible. LOCK TABLE toma medidas para cuando se pueda necesitar un modo de bloqueo mas restrictivo.

Por ejemplo, una aplicación ejecuta una transacción en el nivel de aislamiento READ COMMITTED y necesita asegurar la existencia de datos en una tabla para la duracion de la transacción. Para ello tú podrías usar el modo de bloqueo SHARE sobre la tabla antes de la consulta. Esto protegerá los datos de cambios concurrentes y proporcionará cualquier otra operación de escritura sobre la tabla con datos en su verdadero estado actual, porque el modo de bloqueo SHARE es incompatible con cualquier ROW EXCLUSIVE accedido por los que esriben, y LOCK TABLE "tabla" en sentencia IN SHARE MODE esperará hasta que se produzca o se "baje" cualquier operación de escritura concurrente.

Para leer datos en su verdadero estado actual cuando ejecutas una transacción en el nivel de aislamiento SERIALIZABLE tienes que ejecutar una declaración LOCK TABLE antes de la ejecución de cualquier sentencia DML, cuando la transacción define qué cambios concurrentes serán visibles por ellos mismos.

Además de los requerimientos precedentes, si una transacción va a cambiar datos en una tabla entonces se debería acceder al modo SHARE ROW EXCLUSIVE para evitar condiciones de punto muerto cuando dos transacciones coincidentes intentan bloquear la tabla en modo SHARE y entonces intentan cambiar datos en esta tabla, ambas (implicitamente) accediendo al modo de bloqueo ROW EXCLUSIVE que es incompatible con el bloqueo SHARE .

Para continuar con los puntos muertos (cuando dos transacciones se esperan la una a la otra) tema tratado arriba, deberías seguir dos reglas generales para evitar condiciones de punto muerto :

• Las transacciones tienen que acceder a bloqueos de los mismos objetos en el mismo orden.

  Por ejemplo, si una aplicación actualiza la fila R1 y después actualiza la fila R2 (en la misma transacción) entonces la segunda aplicación no debería actualizar la fila R2 si ello va a actualizar la fila R1 más tarde (en una transacción simple). En cambio, debería actualizar la fila R1 y R2 en el mismo orden como en la primera aplicación.

• Las transacciones deberían procurarse dos modos de bloqueo conflictivos sólo si uno de ellos es auto-conflictivo (i.e. podría ser soportado por sólo una transacción cada vez). Si estan involucrados modos de bloqueo múltiples, entonces las transacciones deberían siempre acceder primero al modo más restrictivo.

  Un ejemplo para esta regla se dió antes cuando se discutió el uso del modo SHARE ROW EXCLUSIVE mejor que el modo SHARE.

Postgres no detecta puntos muertos "bajará" una transacción a la espera para resolver el punto muerto.

Uso

Illustrate a SHARE lock on a primary key table when going to perform inserts into a foreign key table:

BEGIN WORK;
LOCK TABLE películas IN SHARE MODE;
SELECT id FROM películas
    WHERE name = 'Star Wars: Episodio I - La amenaza fantasma';
-- Haz ROLLBACK si el registro no fue devuelto
INSERT INTO comentarios_usuario_películas VALUES
    (_id_, 'GUAY! Llevaba tanto tiempo esperándola!');
COMMIT WORK;
   

Toma un bloqueo SHARE ROW EXCLUSIVE clave de tabla primaria cuando vayas a hacer una operación de borrado:

BEGIN WORK;
LOCK TABLE películas IN SHARE ROW EXCLUSIVE MODE;
DELETE FROM comentarios_usuario_películas WHERE id IN
    (SELECT id FROM películas WHERE clasificación < 5);
DELETE FROM películas WHERE clasificación < 5;
COMMIT WORK;
   

Compatibilidad