# ROLLBACK

The `ROLLBACK` statement aborts the current transaction and all of its nested transactions, discarding all transactional updates made by statements included in the transaction.

There are two ways to use `ROLLBACK`:

- The `ROLLBACK` statement rolls back the entire transaction.

- New in v20.1: The `ROLLBACK TO SAVEPOINT` statement rolls back and restarts the nested transaction started at the corresponding `SAVEPOINT` statement, for working with standard savepoints. This is in addition to the existing support for working with client-side transaction retries. For examples of each usage, see:

  - Rollback a nested transaction
  - Retry a transaction

Warning:

Rollbacks to savepoints over DDL statements are only supported if you're rolling back to a savepoint created at the beginning of the transaction.

## Synopsis

## Required privileges

No privileges are required to rollback a transaction. However, privileges are required for each statement within a transaction.

## Parameters

Parameter | Description
--- | ---
`TO SAVEPOINT cockroach_restart` | If using advanced client-side transaction retries, retry the transaction. You should execute this statement when a transaction returns a `40001` / `retry transaction` error.
`TO SAVEPOINT <name>` | If using nested transactions, roll back and restart the nested transaction started at the corresponding `SAVEPOINT` statement.

## Savepoints and row locks

CockroachDB supports exclusive row locks.

- In PostgreSQL, row locks are released/cancelled upon `ROLLBACK TO SAVEPOINT`.
- In CockroachDB, row locks are preserved upon `ROLLBACK TO SAVEPOINT`.

This is an architectural difference in v20.1 that may or may not be lifted in a later CockroachDB version.

The code of client applications that rely on row locks must be reviewed and possibly modified to account for this difference. In particular, if an application is relying on `ROLLBACK TO SAVEPOINT` to release row locks and allow a concurrent transaction touching the same rows to proceed, this behavior will not work with CockroachDB.

## Savepoints and high priority transactions

`ROLLBACK TO SAVEPOINT` (for either regular savepoints or "restart savepoints" defined with `cockroach_restart`) causes a "feature not supported" error after a DDL statement in a `HIGH PRIORITY` transaction, in order to avoid a transaction deadlock. For more information, see GitHub issue #46414.

## Examples

### Rollback a transaction

Typically, an application conditionally executes rollbacks, but we can see their behavior by using `ROLLBACK` instead of `COMMIT` directly through SQL:

    > SELECT * FROM accounts;

    +----------+---------+
    |   name   | balance |
    +----------+---------+
    | Marciela |    1000 |
    +----------+---------+

    > BEGIN;

    > UPDATE accounts SET balance = 2500 WHERE name = 'Marciela';

    > ROLLBACK;

    > SELECT * FROM accounts;

    +----------+---------+
    |   name   | balance |
    +----------+---------+
    | Marciela |    1000 |
    +----------+---------+

### Rollback a nested transaction

The `ROLLBACK TO SAVEPOINT` statement rolls back and restarts the nested transaction started at the corresponding `SAVEPOINT` statement.

For examples showing how to use `ROLLBACK TO SAVEPOINT` to rollback a nested transaction, see the `SAVEPOINT` documentation on nested savepoints.

### Retry a transaction

When using advanced client-side transaction retries, use `ROLLBACK TO SAVEPOINT` to handle a transaction that needs to be retried (identified via the `40001` error code or `restart transaction` string in the error message), and then re-execute the statements you want the transaction to contain.

    > ROLLBACK TO SAVEPOINT cockroach_restart;

For examples of retrying transactions in an application, check out the transaction code samples in our Build an App with CockroachDB tutorials.

## See also

- `SAVEPOINT`
- Transactions
- `BEGIN`
- `COMMIT`
- `RELEASE SAVEPOINT`
- `SHOW SAVEPOINT STATUS`