= Transaction atomicity
<Transaction atomicity> gives a <database transaction> an all-or-nothing effect: either its committed updates take effect together or its partial updates do not remain as a completed result. This can be implemented with undo information, version visibility, recovery logging or combinations of these mechanisms. It does not require every physical write to happen at the same instant.
For example, transferring five units between accounts requires a debit and a credit. If an error occurs after the debit, aborting the transaction must not leave only that debit as the final <database> result. <SQL> transaction blocks use `BEGIN`, `COMMIT` and `ROLLBACK` to express the boundary.<Transactions in the PostgreSQL documentation>[§3.4, all-or-nothing updates and rollback]{ref} Atomicity alone does not say how transactions interact before completion; <transaction isolation> governs that. Nor does it make a committed result survive a crash; that is <transaction durability>. External effects such as a sent email require coordination beyond rolling back the <database> changes.
Back to article page
