Savepoints und der abgebrochene Transaktionszustand in PostgreSQL

Worum es geht

Ein Transaktionsblock (BEGIN ... COMMIT) ist atomar: Entweder werden alle seine Änderungen behalten oder keine. Das PostgreSQL-Tutorial hält fest, dass der Block nach einem Fehler in einen abgebrochenen Zustand versetzt wird und dass ROLLBACK TO zu einem Savepoint der einzige Weg ist, die Kontrolle zurückzugewinnen, ohne die ganze Transaktion zurückzurollen. In diesem Zustand ausgegebene Befehle scheitern mit SQLSTATE 25P02, im Anhang der Fehlercodes in_failed_sql_transaction, dessen Meldung lautet: "current transaction is aborted, commands ignored until end of transaction block". SAVEPOINT name markiert einen Punkt; ROLLBACK TO SAVEPOINT name verwirft die danach vorgenommenen Änderungen und hält die Transaktion offen; RELEASE SAVEPOINT name entfernt die Markierung und behält die Änderungen. Savepoints können verschachtelt werden.

Warum es wichtig ist

Anwendungscode, der eine Datenbankausnahme abfängt und auf derselben Verbindung weiterhin Anweisungen ausgibt, scheitert bei jeder Einzelnen davon, oft mit dem verwirrenden Fehler 25P02, weit entfernt von der ursprünglichen Ursache. Batch-Jobs, die "die fehlerhafte Zeile überspringen, den Rest behalten" wollen, brauchen Savepoints oder Transaktionen pro Zeile. Connection-Pools, die eine Verbindung im abgebrochenen Zustand zurückgeben, vergiften die nächste Nutzung dieser Verbindung.

So wird es angewendet

• Unmittelbar vor einer Anweisung, die legitim fehlschlagen kann (eine Constraint-Verletzung, die der Code behandeln will), einen Savepoint setzen, im Ausnahme-Handler zu ihm zurückrollen und dann fortfahren; ihn bei Erfolg freigeben.
• Bei zeilenweisen Importen entweder jede Zeile in einen Savepoint einbetten und nur die fehlschlagenden zurückrollen, oder stattdessen die Fehlerquelle beseitigen: zuerst in einer Staging-Tabelle validieren, oder INSERT ... ON CONFLICT DO NOTHING verwenden.
• In PL/pgSQL fängt ein BEGIN ... EXCEPTION ... END-Block Fehler ab, die sonst die Funktion und die umgebende Transaktion abbrechen würden; die Dokumentation weist darauf hin, dass das Betreten und Verlassen eines solchen Blocks deutlich teurer ist als ohne, deshalb nur die Anweisung umschliessen, die es braucht.
• Transaktionen kurz halten: eine lange Transaktion mit vielen Savepoints hält ihre Sperren und alte Zeilenversionen für ihre gesamte Dauer am Leben.
• Prüfen, was der Treiber tut: ob er Transaktionen implizit öffnet und ob er 25P02 gesondert meldet, sodass der Handler zurückrollt, statt die Anweisung erneut zu versuchen.

Stolpersteine

ROLLBACK TO beendet die Transaktion nicht; Änderungen vor dem Savepoint bleiben bis zum COMMIT unbestätigt und für andere Sitzungen unsichtbar. Manche Treiber und ORMs können jede Anweisung in einen Savepoint einbetten; jeder Savepoint öffnet eine Subtransaktion mit eigener Buchführung, deshalb diesen Modus aus Hot Paths heraushalten. Das Tutorial weist darauf hin, dass das Freigeben eines Savepoints oder das Zurückrollen zu ihm jeden danach definierten Savepoint freigibt, und dass ein Savepoint nach einem Rollback zu ihm weiterhin definiert bleibt, sodass er wiederverwendet werden kann.