> For the complete documentation index, see [llms.txt](https://mariadb.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mariadb.com/docs/server/reference/error-codes/mariadb-error-codes-1100-to-1199/e1180.md).

# Error 1180: Got error during COMMIT

| Error Code | SQLSTATE | Error                     | Description                |
| ---------- | -------- | ------------------------- | -------------------------- |
| 1180       | HY000    | ER\_ERROR\_DURING\_COMMIT | Got error %d during COMMIT |

## Possible Causes and Solutions

The server prints more than the number shown above: it follows the error number with its text in double quotes, for example `130 "Incorrect file format"`. Numbers from 120 to 202 are MariaDB storage-engine errors and take their text from MariaDB; any other number is an operating-system error.

The server returns this error when the commit of a transaction fails, and rolls the transaction back. The number in the message comes from the part of the server that failed. To look up an operating-system error number, use [perror](/docs/server/clients-and-utilities/administrative-tools/perror.md).

The common causes are:

* **The commit had to wait for a backup lock.** A COMMIT that changes data waits while another session holds [FLUSH TABLES WITH READ LOCK](/docs/server/reference/sql-statements/administrative-sql-statements/flush-commands/flush.md#flush-tables-with-read-lock) or a [BACKUP STAGE](/docs/server/reference/sql-statements/administrative-sql-statements/backup-commands/backup-stage.md) lock, as backup tools take. If [lock\_wait\_timeout](/docs/server/server-management/variables-and-modes/server-system-variables.md#lock_wait_timeout) runs out first, the COMMIT fails with two errors: [error 1205](/docs/server/reference/error-codes/mariadb-error-codes-1200-to-1299/e1205.md) and then this one. The client usually reports the first, while [SHOW WARNINGS](/docs/server/reference/sql-statements/administrative-sql-statements/show/show-warnings.md) shows both:

  ```
  ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

  SHOW WARNINGS;
  +-------+------+--------------------------------------------------------+
  | Level | Code | Message                                                |
  +-------+------+--------------------------------------------------------+
  | Error | 1205 | Lock wait timeout exceeded; try restarting transaction |
  | Error | 1180 | Got error 1 "Operation not permitted" during COMMIT    |
  +-------+------+--------------------------------------------------------+
  ```

  Retry the transaction after the backup has released its lock. If this happens often, make the lock phase of the backup shorter, or schedule it when there are fewer writes.
* **Writing the transaction to the** [**binary log**](/docs/server/server-management/server-monitoring-logs/binary-log.md) **failed**, for example because the disk is full. The [error log](/docs/server/server-management/server-monitoring-logs/error-log.md) usually has more details. Free disk space, or fix the problem the error log names.
* **A storage engine couldn't commit.** The number is then the storage engine's error code. Check the error log.
* **In a Galera cluster, a transaction changed tables in more than one storage engine**, and one of them doesn't support the commit protocol that Galera needs. The message is then `Transactional commit not supported by involved engine(s)`. Use InnoDB for all tables that a transaction changes.

<sub>*This page is licensed: CC BY-SA / Gnu FDL*</sub>

{% @marketo/form formId="4316" %}