Los savepoints y el estado de transacción abortada en PostgreSQL

Qué es

Un bloque de transacción (BEGIN ... COMMIT) es atómico: se conservan todos sus cambios o ninguno. El tutorial de PostgreSQL indica que, tras un error, el bloque pasa a un estado abortado, y que ROLLBACK TO un savepoint es la única forma de recuperar el control sin revertir la transacción completa. Los comandos emitidos en ese estado fallan con el SQLSTATE 25P02, in_failed_sql_transaction en el apéndice de códigos de error, cuyo mensaje dice «current transaction is aborted, commands ignored until end of transaction block». SAVEPOINT name marca un punto; ROLLBACK TO SAVEPOINT name descarta los cambios realizados después de él y mantiene la transacción abierta; RELEASE SAVEPOINT name elimina la marca y conserva los cambios. Los savepoints pueden anidarse.

Por qué importa

El código de aplicación que captura una excepción de la base de datos y sigue emitiendo sentencias en la misma conexión falla en cada una de ellas, a menudo con el confuso error 25P02 lejos de la causa original. Los trabajos por lotes que quieren «omitir la fila incorrecta, conservar el resto» necesitan savepoints o transacciones por fila. Los pools de conexiones que devuelven una conexión en estado abortado contaminan al siguiente usuario de esa conexión.

Cómo aplicarlo

• Definir un savepoint inmediatamente antes de una sentencia que pueda fallar de forma legítima (una violación de restricción que el código está preparado para manejar), revertir hasta él en el manejador de excepciones y luego continuar; liberarlo en caso de éxito.
• Para importaciones fila por fila, envolver cada fila en un savepoint y revertir solo las que fallan, o bien eliminar la fuente del error: validar primero en una tabla intermedia (staging), o usar INSERT ... ON CONFLICT DO NOTHING.
• En PL/pgSQL, un bloque BEGIN ... EXCEPTION ... END atrapa errores que de otro modo abortarían la función y la transacción que la rodea; la documentación señala que entrar y salir de un bloque así es considerablemente más costoso que sin él, por lo que conviene envolver solo la sentencia que lo necesita.
• Mantener las transacciones cortas: una transacción larga con muchos savepoints retiene sus bloqueos y mantiene vivas versiones antiguas de las filas durante toda su duración.
• Comprobar qué hace el driver: si abre transacciones de forma implícita, y si informa el 25P02 de manera distinguible para que el manejador revierta en lugar de reintentar la sentencia.

Trampas

ROLLBACK TO no finaliza la transacción; los cambios anteriores al savepoint siguen sin confirmarse y son invisibles para otras sesiones hasta el COMMIT. Algunos drivers y ORM pueden envolver cada sentencia en un savepoint; cada savepoint abre una subtransacción con su propia contabilidad, así que conviene mantener ese modo fuera de las rutas críticas. El tutorial señala que liberar un savepoint o revertir hasta él libera todos los savepoints definidos después de él, y que un savepoint sigue definido tras una reversión hasta él, por lo que puede reutilizarse.