Aislamiento e integridad SQL: casos PostgreSQL para TAI

Respuesta rápida: una transacción reúne varios pasos en una operación de todo o nada. COMMIT confirma; ROLLBACK cancela lo pendiente. En PostgreSQL, los cambios de filas ordinarias de una transacción abierta no son visibles para otras hasta que se confirma. Las secuencias son una excepción: su avance puede observarse antes del COMMIT y no se deshace con ROLLBACK.

ACID no es una lista para memorizar sin casos

La documentación oficial de PostgreSQL explica que una transacción agrupa pasos como una operación de todo o nada. Esto resuelve errores parciales: en una transferencia no debe quedar un cargo sin el abono correspondiente. PostgreSQL usa BEGIN y COMMIT para delimitar el bloque, y ROLLBACK para cancelarlo.

Concepto	Pregunta útil
Atomicidad	¿Se aplican todos los pasos o ninguno?
Consistencia	¿Se cumple una regla declarada, como CHECK (saldo >= 0)?
Aislamiento	¿Puede otra transacción ver un estado intermedio?
Durabilidad	¿Qué pasa tras confirmar y producirse un fallo?

Una base de datos no inventa reglas de negocio: si no declaras una restricción, no puede garantizarla por ti.

Lo básico: COMMIT y ROLLBACK

BEGIN;
UPDATE cuentas SET saldo = saldo - 50 WHERE id = 1;
UPDATE cuentas SET saldo = saldo + 50 WHERE id = 2;
ROLLBACK;

¿Queda alguno de los dos cambios? No. ROLLBACK cancela el bloque pendiente. Para práctica básica adicional, consulta COMMIT y ROLLBACK.

Caso de dos sesiones: Read Committed

Partimos de una fila con saldo 100 confirmado. La sesión A ejecuta BEGIN; UPDATE cuentas SET saldo=120 WHERE id=1;. B hace SELECT saldo antes del COMMIT: ve 100, no 120. A confirma. Si B lanza otro SELECT con Read Committed después de esa confirmación, ve 120 en este ejemplo.

No hay lectura sucia: B nunca ve el cambio sin confirmar. Que dos SELECT de B difieran tras el COMMIT de A es una lectura no repetible.

Caso de dos sesiones: Repeatable Read

Partimos otra vez de una fila con saldo 100 confirmado. A cambia el saldo a 120 y mantiene su transacción abierta. B ejecuta BEGIN ISOLATION LEVEL REPEATABLE READ y hace su primer SELECT antes del COMMIT de A: obtiene 100. Ese primer SELECT fija la instantánea. Después de que A confirme, otro SELECT de B sigue viendo 100 mientras B conserve la transacción.

El matiz decisivo es que BEGIN por sí solo no fija la instantánea. Si B ejecuta BEGIN antes del COMMIT de A, pero hace su primer SELECT después, su instantánea ya incluye el 120 confirmado. No basta ordenar los BEGIN: hay que situar la primera consulta que fija la instantánea.

Caso PostgreSQL: secuencias

BEGIN; SELECT nextval('pedidos_id_seq'); ROLLBACK; no obliga a reutilizar el número. PostgreSQL advierte que los cambios en secuencias son visibles de inmediato y no se revierten: puede haber huecos. Si A obtiene un valor con nextval sin confirmar, B puede obtener el siguiente antes del COMMIT de A. Ese avance no es una lectura sucia de una fila ordinaria.

Comprueba la regla en la documentación oficial de aislamiento de PostgreSQL, que distingue expresamente este comportamiento de las secuencias.

Preguntas frecuentes

¿COMMIT deshace cambios?

No. COMMIT confirma la transacción; ROLLBACK cancela sus cambios no confirmados.

¿Read Committed permite lecturas sucias en PostgreSQL?

No. PostgreSQL no permite lecturas sucias y usa Read Committed como nivel predeterminado.

Para practicar SQL y el temario de informática, consulta el Pack Temario TAI 2027. Los casos son propios y no sustituyen la documentación oficial.