SAVEPOINT statement defines the intent to retry transactions using the CockroachDB-provided function for client-side transaction retries. For more information, see Transaction Retries.
SAVEPOINT implementation does not support nested transactions (i.e., subtransactions). It is only used to handle transaction retries.
No privileges are required to create a savepoint. However, privileges are required for each statement within a transaction.
|name||The name of the savepoint. Defaults to
Customizing the savepoint name
New in v19.1: Set the
force_savepoint_restart session variable to
true to enable using a custom name for the restart savepoint (for example, because you are using an ORM that wants to use its own names for savepoints).
Once this variable is set, the
SAVEPOINT statement will accept any name for the savepoint, not just
cockroach_restart. This allows compatibility with existing code that uses a single savepoint per transaction as long as that savepoint occurs before any statements that access data stored in non-virtual tables.
force_savepoint_restart variable changes the semantics of CockroachDB savepoints so that
RELEASE SAVEPOINT <your-custom-name> functions as a real commit. Note that the existence of this variable and its behavior does not change the fact that CockroachDB savepoints can only be used as a part of the transaction retry protocol.
BEGIN the transaction, you must create the savepoint to identify that if the transaction contends with another transaction for resources and "loses", you intend to use client-side transaction retries.
SAVEPOINT must also include functions to execute retries with
ROLLBACK TO SAVEPOINT.
> SAVEPOINT cockroach_restart;
> UPDATE products SET inventory = 0 WHERE sku = '8675309';
> INSERT INTO orders (customer, sku, status) VALUES (1001, '8675309', 'new');
> RELEASE SAVEPOINT cockroach_restart;